CMOS/ADTG/Digic register investigation on ISO

[SpcCb]

OK, works fine now -.^

Here is results for ISO 100-1600 with -1/3 steps (could be useful):
-> http://www.bgimage.fr/publis_ext/ml/2014-06-05_snr2_5d2.zip (bad samples)

Note: For me there's 'something somewhere'; in regular conditions 5D2 has a FWC of ~65700e- (around 5ke- more with some tweaks) and here I get ~55600e-.
Maybe an OB' stuff who false the analyse.

[a1ex]

OB stdev is only used as an initial guess (but should have no effect on the final result).

However, in your ISO 100 sample, you don't have any data points above 8 EV. This is very important for a good fit.

Here's how it should look like (notice the red dots covering the entire range) : http://www.magiclantern.fm/forum/index.php?topic=10111.msg117999#msg117999

My quick test on 5D2 at ISO 100:

[SpcCb]

(...)
However, in your ISO 100 sample, you don't have any data points above 8 EV. This is very important for a good fit.
(...)

Ah, it is the why.
Though a part of the surface was overexposed (burned in fact) and another well dark. As usual..
I will see later to remake a run if needs, because you look to already have 5D2 data (?).

Beside, it will be interesting to run this kind of analyse with a special mini_iso conf (to see the FWC gain) and dual_iso feature (the FWC gain should be [...!] ). -.^

note: I don't know if it's a UI restriction, but the unit for FWC is e- (e is negative actually).

[a1ex]

I only ran a test shot to check that memory error. I'd prefer not to sit down and take a bunch test pictures that other people can do very easily.

FWC gain with dual ISO... should be like ISO 100 for half of the rows, and like ISO 1600 for the other half (for example). The exact SNR curve will depend on the blending algorithm (so you will need to run this experiment offline) and also on the scene contents (where it tries to balance between noise and aliasing in shadows). Running it without --alias-map should give consistent results though (since the blending factors are chosen based on input signal and OB noise levels).

What would be interesting is to run it in LiveView and figure out how many pixels are averaged when downsampling. Can you help me figure out the math for this? (that is, how the noise should behave if N sensels are averaged on the CMOS sensor, before amplification - or wherever you think Canon might do this step)

[SpcCb]

I only ran a test shot to check that memory error. I'd prefer not to sit down and take a bunch test pictures that other people can do very easily.

OK -.^

(...)
What would be interesting is to run it in LiveView and figure out how many pixels are averaged when downsampling. Can you help me figure out the math for this? (that is, how the noise should behave if N sensels are averaged on the CMOS sensor, before amplification - or wherever you think Canon might do this step)

Of course, if I can help.

I thought resizing was done by pixel groups exclusion (?). Witch is causing, with VAF (working as a median filter), aliasing/moiré problems (because of Nyquist limit) except in x5 video mode (where CMOS surface is recorded at full resolution). So in this case, pixel informations (levels, etc.) should be the same before/after downsampling resizing.

Or are you speaking about the video feed directly on the camera back screen?

Beside, I well know about noise, FWC, etc. in case of binning downsampling (hardware or not BTW) but obviously this is not the case here (?). And I'v never seen hardware CMOS average capability (looks technically improbable), even it is _maybe_ possible.

[121nilsson]

Hello!

thought i would try this on the Eos M. Got stuck with some message on the screen.
https://drive.google.com/file/d/0B04NFrlfFHNvUi15dy1Cb19ONUU/edit?usp=sharing

[a1ex]

I've translated the raw_diag code for SNR curves into octave, so you can run the same analysis offline (including on dual iso files).

snr_curve.m (for two test images of the same scene, taken with identical settings)
run_tests.m (for all my test images, see below)

The curve fitting results might differ a little from raw_diag (nothing to worry about).

ISO 100 and 1600:


Dual ISO 100/1600, developed with different options:



The graphs were scaled to show 15 EV below white level, and the SNR axis is from -2 to +10 EV. Therefore, you can overlap any two images and compare them directly (with alt+tab, for example).

edit: also added ISO 1600 darkened by 4 EV, to match the brightness of ISO 100. Ideally, the SNR of a dual ISO image should be roughly the maximum of the two single-iso SNRs (maybe better in overlapped areas) if you don't consider the resolution loss.

[Greg]

Trick :

[Audionut]

Some more results, this time with the Read noise and Poisson noise plots, and trying to fill the entire graph with data, like so.



Canon ISO
ML ISO

[a1ex]

Nice!

Can you use the same test scene (since it gives great coverage) for some movie mode tests? I'm interested in:
- 1080p (I expect identical results at all 3 FPS settings)
- 720p
- 5x zoom (tip: use raw video grayscale preview to frame the image)

The movie mode tests may run a little slower, but they don't waste any shutter actuations, so everybody should do them. All cameras, please!

[Audionut]

Well, I just completed a shit load of sample images, to find the screenshot function only captured the first image, and then went on strike.  Sure enough, the first image was setting up the testing procedure and doesn't contain useful information.  Anyway, I can share my thoughts.

Thoughts on the data:
At first it appeared like movie mode was entirely Read noise limited at lower ISOs.  I suspect that movie mode is somewhat rather Read noise limited (compared to photo mode), however, the curve was extending above the top of the graph, so I can't be certain.  It needs some automatic fitting of the curve, or at least, different scales on the graph for movie mode and photo mode.

The DR is greater in movie mode then photo mode.  Now, we know the ADTG registers don't change, so if we also consider that the the images are more Read noise dominated, then I believe that this shows pixel binning.

If memory serves me correctly, the stdev was similar to photo mode, but the FWC was less.  I didn't check the read noise measurement during the capture phase.  I know, this doesn't make sense.

Around ISO 800, the curve gets clipped at 0 EV on the vertical scale.  From here, it increases back towards -2 EV with increasing ISO.  Confirmed in both 1080p and 720p modes.  Speaking of which, I assume you meant Canon resolution modes, since cropping with ML resolution changes seems pointless?

In crop mode, somewhat expected, the figures were remarkably similar to photo mode.

ADTG tweaks work!  11.5 EV @ ISO 200 with some quick tweaking.  CMOS 5 is 0x501 and CMOS 6 is 0x370 in movie mode.  ADTG6[8000] is 0x6.

Swapping in and out of crop mode, adjusting ADTG registers, taking SNR curve measurements, eventually the camera had enough, and displayed really weird images like the ones I shared in the ISO research pull request.



Thoughts on functionality:
It says "sampling data" in the top right section, but at first I thought it wasn't doing anything, I'm pretty sure for whatever reason, the graph wasn't updating on the first try..  Maybe you could change that to, "Sit tight, I'm counting your photons"!  Or something else really obvious to us common folks.

Since the data is sampled in real time, the first image in the two shot sequence is rather redundant, right?

The framing of the image on the LCD screen changes, when the SNR curve is processing.  However, the curve still reflects the original framing.

Did I mention the screenshot function only works on the first image



And whatever else I forgot, since having a notepad and pen with me, makes to much sense 
Off to bed.  I look forward to raw_diag_movie_mode version 2 when I wake up 

[a1ex]

I think I know why the screenshot works only for one image. The PPM files are named after the last movie filename...

(so, it was the last screenshot that got saved, not the first one)

Solved.

"the curve was extending above the top of the graph" => there is a second view of the same thing, called "Noise curve". This one is a little harder to overflow. Still, the overflow is only on the display, and won't affect the fitting results.

[SpcCb]

(...)
Thoughts on the data:
At first it appeared like movie mode was entirely Read noise limited at lower ISOs.  I suspect that movie mode is somewhat rather Read noise limited (compared to photo mode), however, the curve was extending above the top of the graph, so I can't be certain.  It needs some automatic fitting of the curve, or at least, different scales on the graph for movie mode and photo mode.

The DR is greater in movie mode then photo mode.  Now, we know the ADTG registers don't change, so if we also consider that the the images are more Read noise dominated, then I believe that this shows pixel binning.
(...)

To confirm if pixel binning is done it's quite simple: RON should be the same before/after binning (only the signal value change), or with a normalized signal value the SNR should be up in function of the number of pixel binned.

PS. I re-run some test with raw_diag but I don't find a way to get good samples with artificial lights. Audionut > Is your scene is by day?

[a1ex]

If you know the RON and the FWC values, one set from 1:1 crop mode (5x zoom), and the other from 1080p (or 720p), can you find out how many pixels were binned? How?

(with my "pi=3" math skills, I get around 10 pixels binned in 5D3 1080p and around 15 in 720p, which doesn't look quite right)

[SpcCb]

Lets take SNR as reference, because overall values could be hard to compare, in a simple and not so realistic example:
If in crop mode (5x) you get 3 and in 1080p you get 12 it means that you should do a bin2: 4 pixels group, hence 4x3 and so 12.

SNR increasing by power of 2 of the pixel matrix size; bin2 -> 2x2 pixels -> 4 pixels -> 4x SNR, bin4 -> 4x4 pixels -> 16x SNR...

In the real world it could have some variances, but it should be close to that.

Note: Could you anticipate the binning value by comparing the full resolution to the 1080p? I was thinking about 5760px -> 1920px, so a bin3 BTW.

[Audionut]

Two 9 watt LED spot lights.  I believe that LED doesn't flicker, so this way I can use any shutter value.

One LED is around 7cm (3in) from a wall, pointed almost directly at it, the other LED is around 13cm (5in) from the wall, angled slightly away to give a nice gradient.  The angled light has a small hint of saturation, the point blank light is complete saturation (useful when ADTG tweaking).  Exposure time = 1/100s @ f/4.0.
The test setup is in a dimly lit room (I would say around 2 EV).  I use objects in the scene to control light spill, and in the dark area, I have a window to outside, that for all intents and purposes, is pitch black (-6 EV).  So I estimate the test scene to have around 17 EV of DR, with reasonably good gradients throughout.

The part I found most difficult, is getting a nice gradient from the light, for very good coverage in the area around 0 EV through -4 EV from sensor saturation.  I have ideas for the next test batch   Daytime here so I cannot recreate the scene, but I will take a bracket later tonight when I run the tests again.


One day I will learn how to light a portrait with the same care I place onto test scenes. 

[Audionut]

Ouch, looks like you didn't update the .mo link, and I didn't check functionality.
Third time is a charm right!  Good news is, I've become really proficient at changing ISO in movie mode, without triggering the SNR curve.

This one causes conflicts with raw_rec and cr2hdr.

[a1ex]

Whoops, updated now.

No conflicts here when merging unified and iso-research. I usually compile the module directly from the branch, without merging anything.

edit: ah, you mean compile error.

[Audionut]

Yes I did mean compile errors 

Finally finished stuffing around, and here is a good bunch of results.  Enjoy!
https://www.dropbox.com/sh/ktc2kyabmozjofq/AAC7kSBnzX3E5cwoLn9nrsbYa

One with a little ADTG tweaking 


Edit, I did this series as, 1080p, crop, 720p, ADTG tweaks.  By the end, the camera was getting a little warm, and probably affecting results, I guess.  They all had a resolution width of 1080p in ML.

Crop series doesn't have the coverage that I hoped, of course, I didn't remember that I could increase resolution until after I completed the captures. 

Is there anyway to determine the CMOS/ADTG settings in crop mode?

[a1ex]

I expect temperature to cause differences in the read noise (in this model), but I'm interested mostly in the shot noise. So it should be fine.

CMOS/ADTG settings are printed by both iso_regs and adtg_gui (if you don't change any settings). Not all of them have effect in both modes though.

On 5D3, the ADTG preamp (8/9/A/B) is 91 in 1080p, 102 in 720p and 59 in 5x/photo. My previous tests showed the unit for this one is 0.006 EV, so the differences (compared to 5x/photo) are +0.19 EV for 1080p and +0.26 EV for 720p. I don't know if these differences result in different amounts of captured highlights.

Anyway, these differences should be OK if you can work with the "pi=3" hypothesis.


From the above data, I'll try to guess the pixel binning factors from LiveView.

Pixel binning discussion continued at http://magiclantern.fm/forum/index.php?topic=16516.

[Audionut]

On 5D3, the ADTG preamp (8/9/A/B) is 91 in 1080p, 102 in 720p and 59 in 5x/photo.

Here, they are 59, 63, 39.  Highest values of the set.

If I reduce ADTG preamp, the curve in the highlights has a slight bend towards lower EV values on the graph.  With ADTG 888x, I can create a huge bend in the curve at the highlights.  I seem to have deleted the graph, I'll post one tomorrow.

Notice with this capture, "5D3-1080p-ADTG-FE-0x3+888x-0x37x.png", ADTG 888x has been reduced to much.


What do you suspect is happening with the clipped shadows @ ISO 800?

[a1ex]

Clipped shadows? Not sure, can you take some silent pictures in that mode? (a good one and a bad one should be enough).

[Audionut]

I haven't inspected any images (yet).  Look at the curve data.

It only happens in LV.

[a1ex]

Dynamic range plot from Audionut's data (5D3, movie mode, no tweaks):



(noise graphs here: https://www.dropbox.com/sh/ktc2kyabmozjofq/AAC7kSBnzX3E5cwoLn9nrsbYa )

Therefore:
- 5D3 video shooters: do not be afraid of ISO 6400 in non-crop modes (the improvement is a consequence of pixel binning, see my previous post)
- DR estimated as log2(white-black) - log2(DN where SNR = 1)
- the difference beween photo and LV crop ISO appears to be 0.4 EV (LV being darker), therefore I've shifted all the LV plots by 0.4 EV to the left (needs to be confirmed by checking the clipping point; I've got the difference from the number of electrons in the noise model)
- this graph is not directly comparable to the previous ones (I believe this method is more accurate, but need to double-check the theory to be sure)

Code: [Select]

isos =      [ 100    200    400    800    1600   3200   6400  12800 ];
dr_720 =    [ 11.02  10.96  10.93  10.85  10.67  10.36  9.89  8.89  ];
dr_1080 =   [ 11.10  11.05  11.02  10.93  10.73  10.39  9.88  8.88  ];
dr_crop =   [ 11.22  11.13  11.00  10.82  10.32   9.68  8.92  7.70  ];
dr_photo =  [ 10.92  10.83  10.69  10.46  10.02   9.40  8.49        ];


[SpcCb]

I expect temperature to cause differences in the read noise (in this model), but I'm interested mostly in the shot noise. So it should be fine.

Indeed, analysis I made show that temperature does not significantly affects RON. Values are slightly under 1% per a 50°C variation, in the range -50°C -> +60°C, temperature recorded directly on the back side of the CMOS with a special device (the internal thermometer is not relevant because placed on the mainboard).

Beside, the thermal signal well follow the CMOS temperature, causing major noise issues when we use our cameras with a short exposure time when the temperature rises (thermal signal is _mainly_ function of the temperature and the exposure duration).

So when we made noise analysis it is important to use a process where CMOS temperature is included.

(...)
From the above data, I'll try to guess the binning factors from LiveView (and I'll ask SpcCb to double-check what follows):
(...)

Very interesting data.
But I don't figure yet why RON blow up @5x with high ISO face to photo mode. Maybe a level intercorrelation inside the logic pixel intrication area because of the .8n reduction factor.

BTW I did not know there was a reduction factor in 5x video mode; I cant make tests with 5D3 here, 'does not have Bayer matrix anymore, but I'm interested to make test to see if it's the same thing with a 5D2. What kind of resolution chart should we use?