camera – Matthew Petroff

Another Method of Digitizing Large Documents

Matthew Petroff — Tue, 31 Jan 2017 23:25:15 +0000

A few years ago, I wrote about a method of using a modified scanner to scan large documents in segments. While this led to high quality results, it is a very slow and tedious process. More recently, I’ve had a decently large number of maps and documents to digitize but didn’t care so much about the quality and had neither the time nor the patience to scan them using my previous method. Instead, I turned a small conference room into a very large makeshift camera stand. After removing a tile from the drop ceiling, a small wooden beam was placed on the ceiling grid, straddling the hole where the tile was removed. A DSLR camera was then attached to this beam, pointing straight down, with the camera tethered to a computer via USB. A table was placed under the camera. The document to be digitized was placed on the table, and a sheet of glass was placed on top of the document to keep it flat.¹ The fluorescent tubes were removed from the closest ceiling light fixtures to remove glare from the glass; the same number of bulbs were removed from each side of the camera and table to keep the lighting consistent. Once everything was set up, documents were quickly photographed, with captures triggered using the computer. Once finished, lens distortion was removed from the images, and the images were cropped and level corrected. While the results weren’t nearly as nice as the scanner-based method, they were good enough for what I needed them for, and it was much, much faster. An example result is below.

Unfortunately, I neglected to photograph the camera set up.

The documents to be digitized had been stored either rolled or folded. ↩

MacBook Webcam Teardown

Matthew Petroff — Fri, 30 Oct 2015 00:02:43 +0000

With the release of the mid-2013 MacBook models, Apple stopped using the standard USB video device class interface for the laptops’ webcams. On these laptops, the webcam connects via the PCIe bus, enumerating as a Broadcom 1570 device. Unfortunately, this interface is completely undocumented, and there is no Linux driver, although an effort is being made to reverse engineer one. Since I thought understanding the device hardware might aid this driver development effort, I bought a replacement webcam to disassemble. The front of the camera, from left to right, contains a 12-pin connector; power management circuitry, consisting of some sort of crystal or resonator, a Texas Instruments TPS657091 power management IC, and assorted passives; an ambient light sensor (with decoupling capacitor); the image sensor and fixed-focus optics; and an LED. The back of the device contains identification markings, which include a DataMatrix barcode and text, both of which read CC2 3222 2UYE F9T9CF on my particular camera.

Prying the plastic piece holding the optics and ambient light sensor off of the PCB below it exposes the image sensor, LED, and a few more passives. What it doesn’t reveal is the Broadcom device that is on the PCIe bus (more on that later).

The OS X and Windows drivers for the camera make a reference to the OV5650 image sensor, but a quick visual comparison shows that this isn’t the sensor used. I was unfortunately unable to identify the sensor by looking at photos online and do not have access to a microscope capable of inspecting die markings. The driver also references the AD5816 focus controller, but this is unsurprisingly not present due to the fixed-focus optics.

Although the image sensor likely contains the readout circuitry needed to digitize the captured image, it doesn’t contain a PCIe bus interface (and Broadcom doesn’t make image sensors). Therefore, I turned to looking at MacBook teardowns to find the missing interface. The camera board connects directly to the main logic board, which just so happens to contain a Broadcom BCM15700A2 chip that no one seems to know the purpose of. As the part number contains the camera controller’s PCIe bus ID, it is very likely the chip in question, particularly since there are no other mysterious Broadcom chips on the logic board. In retrospect, it makes sense for this chip to be on the logic board and not by the camera, since PCIe signals are not normally carried over cables. A photo of the bottom of the chip on eBay shows that it is an 8 mm x 8 mm, 208-ball BGA, but I can’t find any other information about it. The chip is much too big to fit next to the camera, and its size suggests it probably doesn’t just serve as a PCIe interface and likely does some image processing as well. Although none of the information I discovered will likely be very helpful for writing a driver, locating and associating a part number with the PCIe interface chip was at least illuminating.

Automatic Camera Clock Synchronization under Linux

Matthew Petroff — Sun, 23 Aug 2015 23:35:07 +0000

The one feature I really wish my DSLR had was geotagging. Since my camera lacks this feature, I need to record a GPS track with an external device from which positions can be extracted based on timestamps for geotagging. This requires the camera’s clock to be set accurately, which I want anyway, but doing so manually in the camera’s menu is a bit of a pain. In the past I’ve only recorded GPS tracks for geotagging sporadically, as it required carrying around a dedicated GPS receiver. However, I finally bought a smartphone a few months ago, so I now always carry a device that’s capable of recording GPS tracks.¹ This caused me to revisit the clock synchronization problem.

Under Linux, gPhoto2 supports synchronizing the camera’s internal clock with the computer’s clock for many cameras, including mine, a Canon EOS Rebel T2i. As long as one’s computer is configured to use NTP, this results in quite accurate timestamps on photos. In my case, under Linux Mint 17, running this synchronization manually involves plugging in the camera, unmounting the camera after it gets automounted so gPhoto2 can access it, and then running the appropriate gPhoto2 command to synchronize the camera’s clock. To automate this process, one just needs to add a udev rule to run the clock synchronization command automatically, before the camera is mounted. I wrote such a rule. Since the rule responsible for mounting the camera is in 40-libgphoto2-6.rules, the new rule that synchronizes the camera’s clock should be saved as /etc/udev/rules.d/39-sync-camera-times.rules so that it runs right before the camera is automounted. The contents of this file are as follows:

ACTION!="add", GOTO="sync_camera_time_rules_end"
SUBSYSTEM!="usb", GOTO="sync_camera_time_rules_end"
ENV{ID_USB_INTERFACES}=="", IMPORT{builtin}="usb_id"
ENV{ID_USB_INTERFACES}=="*:060101:*", RUN+="/usr/bin/gphoto2 --set-config syncdatetime=1"

LABEL="sync_camera_time_rules_end"

Now the camera’s internal clock will be synchronized with the computer’s clock any time the camera is plugged in. Note that this sets the camera’s clock to UTC, which makes the most sense anyway as the EXIF time data doesn’t include a time zone.² I’ve tested the rule with a Canon EOS Rebel T2i under Linux Mint 17, but it should also work for any other camera for which gPhoto2 supports clock synchronization and under Ubuntu 14.04 and similar Linux distros. Obviously, gPhoto2 needs to be installed.

Edit (2017-03-11): The above no longer works on Linux Mint 18 / Ubuntu 16.04. The following contents of /etc/udev/rules.d/39-sync-camera-times.rules should be used instead:

ACTION!="add", GOTO="sync_camera_time_rules_end"
SUBSYSTEM!="usb", GOTO="sync_camera_time_rules_end"
ENV{ID_USB_INTERFACES}=="", IMPORT{builtin}="usb_id"
ENV{ID_USB_INTERFACES}=="*:060101:*", ENV{TZ}="Etc/UTC", RUN+="/usr/bin/gphoto2 --set-config datetime=now"

LABEL="sync_camera_time_rules_end"

For some reason, gPhoto now insists on doing a time zone conversion, which is why the time zone has to be explicitly set to UTC.

Transferring the recorded tracks to a computer is easier too. ↩
In my opinion, this is a significant improvement over the automatic clock synchronization in Canon’s EOS Utility for Windows, which insists on syncing the camera’s clock to local time. ↩

CHDK on the Canon PowerShot ELPH 330 HS

Matthew Petroff — Mon, 28 Apr 2014 04:03:09 +0000

I recently purchased a Canon PowerShot ELPH 330 HS point and shoot camera to replace my aging Canon PowerShot SD770 IS. The new camera has better sensitivity, a considerably wider field of view that will help with aerial photography, and more zoom. However, it did not have CHDK available for it, which I was aware of at the time of purchase. The first thing I did on receipt of the camera was begin porting CHDK to it. A few weeks later, the port was mostly done, and it was recently merged into the trunk.