last post?
Not really, but the dns changeover seems to have gone smoothly, and I'm sure the people at Stanford will want their page to be top-level on the new site. What I'd like to see happen is the blog go to a subdirectory somewhere, and maybe start a wiki with information that we have so far. Then again, because of work right now, my time is very limited. I understand sort of abstractly what has to happen to get an image first on the sensor (latent image) and then off the sensor.
So, the process begins with a little jolt across the base of the sensor, which zeros everything out. Shutter opens, photoelectric effect moves around some electrons, shutter closes. The pixels are all charged with a tiny voltage which is relative to the intensity of the light that hit the active area of the pixel. The voltage is unstable, and has to be read out quickly.
So the readout process begins. There's a register clock that determines how fast this happens, sends a voltage to the right pin on the sensor and causes it to dump a line of pixels down one of the output lines (of which there can be 1, 2, 4, or more) which hook up to the ADC, usually straight through. This is for a couple of reasons: Short circuit traces make for lower noise, ADC's are available with built in amplifiers, and most importantly, simplicity. If there is more than one output in use in a camera, usually that output will get a dedicated ADC.
Then from there it gets foggy for me. The ADC spits out a bit stream that goes to some custom logic that reassembles it into something resembling a RAW file (putting the bits all into the right order, because the way they're read out can be flopped or sectioned in any number of ways). "Custom logic" can be a prefabbed chip (Texas instruments makes a bunch that are almost cameras on chip) or an FPGA. This section also has the job of writing the image to ram and possibly on to flash.
The other possibility is that the whole assembly I've just described works as a peripheral to an embedded system that does the job of getting the images written to flash, playback, networking, etc. There are some single board computers that might work, but none fit the bill absolutely in terms of size or performance or features.
Have I got this remotely right? Is this thing on? Buller?
So, the process begins with a little jolt across the base of the sensor, which zeros everything out. Shutter opens, photoelectric effect moves around some electrons, shutter closes. The pixels are all charged with a tiny voltage which is relative to the intensity of the light that hit the active area of the pixel. The voltage is unstable, and has to be read out quickly.
So the readout process begins. There's a register clock that determines how fast this happens, sends a voltage to the right pin on the sensor and causes it to dump a line of pixels down one of the output lines (of which there can be 1, 2, 4, or more) which hook up to the ADC, usually straight through. This is for a couple of reasons: Short circuit traces make for lower noise, ADC's are available with built in amplifiers, and most importantly, simplicity. If there is more than one output in use in a camera, usually that output will get a dedicated ADC.
Then from there it gets foggy for me. The ADC spits out a bit stream that goes to some custom logic that reassembles it into something resembling a RAW file (putting the bits all into the right order, because the way they're read out can be flopped or sectioned in any number of ways). "Custom logic" can be a prefabbed chip (Texas instruments makes a bunch that are almost cameras on chip) or an FPGA. This section also has the job of writing the image to ram and possibly on to flash.
The other possibility is that the whole assembly I've just described works as a peripheral to an embedded system that does the job of getting the images written to flash, playback, networking, etc. There are some single board computers that might work, but none fit the bill absolutely in terms of size or performance or features.
Have I got this remotely right? Is this thing on? Buller?
posted by matt at
6:11 PM
1 Comments:
I've actually been thinking about something like this. I would actually find it beneficial to have access to the data-stream that makes up the exposure.
For example, if you just counted an exposure as a time-slice from the bit-stream coming off the sensor, you could have native support for HDR RAW images and you could possibly extrapolate video by the same means. you would, however, need a huge amount of local storage, but your 20Gb internal storage should suffice.
Post a Comment
<< Home