I would like to share and discuss with you my findings on
- exposure time setting
- analogue gain setting
I modified raspiraw so I can pass parameters for exposure time (Registers 0x3500-0x3502) and analogue gain (Registers 0x350A-0x350B) as command line options. And I extract 256 Pixel of each frame to make some statistics on them (calculation of Mean and deviation ) and write statistics to file.
Mysetting is a dark room, power LED and Camera-LED turned dark as well. The Camera captures only light of one LED (green, red, blue or white)
For a while I have worked with a diffusor between Camera an LED (to reduce differences of brightness).
More recently I skipped the diffusor, to achieve more brightness in the center and to employ minimal exposure times.
With this experimental setting I am able to study the effect of variations of exposure time and analogue gain very precisely.
I am still far away from my goal to identify shot noise in my data. I am happy about any help.
Details of my findings:
Effect of Exposure setting
is more complicated then expected. I expected a rather linear relation between mean of raw data and exposure time. I learned to keep an eye on „dark pixels“ which are not illuminated and which are not effected by this variation (as the signal they carry seems to be a kind of „noise" which is not dependent of exposure time.) And of course one has to keep an eye on saturated pixels, which are not effected by this variation as well.
below numeric value of 8 variations don’t have any effect. The Step from 8 to 16 does more then the expected increase by 2 of pixel values. Without precise measurement on this, I would say: The Step from 8 to 16 equals to an increase by 3.
The Exposuretime which equals to numeric value of 16 has to be clarified yet. I am aware of the following statement of 6by9: "rawcam as checked in gives an exposure time of 36.403ms.“ see https://github.com/raspberrypi/userland ... -101806950
I translate this to "numeric value of 1120 equals 36.403ms“ or "numeric value of 1 equals 32,5us"
This would fit, if tROW
equaled to 32,5us, and if registers 0x3500-0x3502 defined exposure time as multiples of trow.
But it think registers 0x3500-0x3502 define exposure time as multiples of 1/16 tROW
This is the case for OV5642, a sensor which seems very similar to OV5647, and of which a - in some details - better data sheet is available at: http://www.dragonwake.com/download/came ... 642-DS.pdf
The following source code (6by9, thanks for hinting to it in this thread!) takes into account a factor of 1/16 as well:
should be something like 1/(15*1868)=34us in case of full resolution, 15 frame per second.
I assume for now, that numeric value of 8 sets exposure time to 1/2 tROW
= 17us, and I assume that some special register setting would be needed to choose even faster exposure times. This setting ist OK to me, so I am not searching for such a register setting.
But it would be nice to find confirmation of exact values somewhere.
Does anybody know more about this matter? (e.g. experimental results. If one takes a shot of a LED which is switched on/off with a known frequency of some 10 Khz, the resulting image should verify exposure time)
Effect of analogue gain setting
I am rather sure that my Specimen produces at "gain 128“ (This means a numeric value of 128 written into the registers) one code increment per photon. At gain 256 it produces two code increments per photon and at gain 512 four code increments per photon. "per photon“ means: for each photon which is absorbed in the pixel and which does „produce“ an electron-hole pair. Of course not every photon is detected (quantum efficiency is below 1, but this does not matter here).
I can derive this from Diagrams, were I printed for every possible pixel value (0..1023) the number of pixels, which took the value. These Diagrams show „missing“ codes for gain > 128, and clear comb structures at gain around 256 and 512. Example: At gain 150 I observe Missing codes at 16, 33, … 101,118, 135,152,169. This means no Pixel (or nearly no Pixel) took these values while there were plenty of Pixels which took the values in between. (In fact I can't be sure, that gain 64 produces 1 code per photon, an that there may be other reasons why I don't observe missing codes with gain below 128. I would be glad to find somebody who is expert of this matter)
To find powers of 2 here indicates, that gain was set very precisely and for purpose at this level. I see no reason, why the manufacturer should be very careful with linearity and precision of analogue gain. So these findings astonished me very much. Thats why I focused on this matter, and tried many variations of gain to see what happens. I can’t help, these were my results.
I observe a strange side effect: when I increase analogue gain, then the output of „dark pixels“ decreases. At gain 250 they are typically at values around 10-20 (which is horribly much!) but at higher gain „0“ becomes very frequent, and mean values go down. This makes sense when we assume that „analogue gain“ setting does control Pixel reset circuit as well (the voltage, each pixel capacitor is charged to before exposure has to be smaller with higher analogue gain, so fewer electron-hole pairs are needed to discharge it )
Effect of Noise
is much more complicated then I anticipated.
I tried to follow instructions from this paper http://journals.aps.org/prx/pdf/10.1103 ... X.4.031056
which basically tells go down with exposure time, then much of technical noise goes down as well, but that is not what I did experience.
My approach to get rid of fixed pattern noise: I take a series of up to 1024 frames, and calculate for each of my 256 chosen "test pixel“ the mean of 1024 measurements, and the deviation of its mean. And I calculate one covariance values between neighboring pixels of same color (covariance = what is meant in general when „correlation“ is said)
My biggest Trouble is: in the well illuminated areas, I observe very high covariance values. Shot noise would not show this.
In my general setting, the LED is powered by a GPIO Pin, so there could be some Mains hum. This could have an effect. But when I powered LED by a battery, I still found very high covariance values.
Problems with reproducibility
I have serious doubts wether the camera’s state is fully controlled by the register writing at start of raspiraw, as I don’t always get same results with same setup. I am not sure about that. May be, my troubles comes from differences in LED positioning. Of course there may be Bugs in my code as well.