Image Sensor / Optics
The DSLR solution doesn’t work because of the mechanical shutter that lies on top of the sensor. It’s not the mirror, or even the shutter at the film plane - it’s the shutter that clears the sensor. Also, these sensors are rolling shutters, which require us to run the film at slow speeds to avoid the “jello effect.” Here’s a quick description of the difference between a rolling shutter and global shutter.
The imaging sensor is by far the most expensive part of the system. On the cheap end, you have small board cameras like the Raspberry Pi camera, which is very similar to the camera in a phone. On the high end, you have 4K sensor capable of running at 30fps. In-between are DSLR prosumer options like the Canon cameras, a micro 4/3, or even the RED camera. Ideally, we build a system that can take a variety of sensor options to fit a variety of budgets.
How do we do that? As long as we provide a clear digital signal when its time to take a picture, we should be good. The positioning of the camera will change depending on its dimensions, so ideally the camera platform has adjustments to move it up/down, side/side. Take a look at how Retroscan has done this (even though you aren’t supposed to remove their camera). In my previous design, I used a macro-photography tripod plate and a microscope stand. These are still possibilities and they’re cheap.
Industrial Camera Options are categorized by two main factors: sensor type and the data interface. First is the type of sensor. There are frame sensors and line-scan sensors. Frame sensors are like every other camera. They sense light on a rectangular plane and turn that into an image. The line-scan cameras are like flatbed document scanners. They sense light in a single line of pixels and either it moves or the image being scanned moves to the next row of pixels until scanning is complete.
Line scan cameras offer more speed and do not require us to stop the film. The only thing we need to do is signal when a frame has started and ended so that we create a separate file for each frame.
Frame sensors would force us to either build intermittent motion into the system or to run it at a speed slower than the shutter speed of the camera.
In both of these categories, the speed of capture is determined by the data interface, which means the cable type and data processing necessary to move data from the sensor to a processor and then to storage. To run anything at high speeds, you need to buy additional hardware, called Frame Grabbers. These act like a buffer so that you can keep capturing information without waiting for the previous data to be safely saved first.
In all cases, these cameras do not come with lenses. The do, however, almost always come with their own software SDKs with a license that allows us to use that code in our application (I will verify the details on this as we get closer to a final solution).
So far, these are the industrial cameras I’ve been looking at:
Frame Cameras
Point Grey Chameleon (2K, USB3) $595 (used by Retroscan). Sensor only.
Point Grey Grasshopper (4K USB3) $3700. Sensor only.
Line Scan Cameras
Teledyne Piranha 4 - (4K, CameraLink, requires Frame Grabber hardware). Estimated price = $4000 USD for sensor only. Frame Grabber = $1200. + lens (price unknown). Total estimated at ~$8000 USD.
Here are some board camera options
Rasperry Pi Camera (HD-ish, USB) $25 requires macro lens adapter.
13MP board cam (HD, USB3) $139 (used by Gugusse) requires lens.
There is also news of being able to run a Linux distro on Canon DSLRs using Magic Lantern. I wonder if we can figure out a way to use this to (or just Magic Lantern) to use the Live View RAW image feed for DSLRs to capture our frames for us? This would be the cheapest option by far since most people would have access to a Canon DSLR and therefore our most costly part just disappears!