CMOS/ADTG/Digic register investigation on ISO

Started by a1ex, January 10, 2014, 12:11:01 PM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

Audionut

Here are 2 histograms showing the description from my last post.

ADTG 2/4 equal values.



ADTG 4 reduced.



With ADTG 4 reduced, the histograms look remarkably similar.  For reference, without ADTG tweaks, the histogram is a single peak of pixels at saturation, with a small amount of pixels above this saturation point.

Looking closely at the data, it appears as though having only some amount of saturation, is not sufficient for correctly rendered images.  You'll notice on the histograms that there is some data above the saturation point, and reducing the gains sufficiently, this data is no longer there (presumably it has been pulled back into a useable range).  However this results in artifacts in the image.

This is the image of the second histogram above.



It should be pure white.  Observing the color channels individually, the B, R and G2 channels show this pattern.  The G channel, which still has data above the saturation point, still retains an even appearance. 
I would say this data above the saturation point is simply noise, and where the gains are reduced to much, this noise gets pulled back into the rendered image.

I thinking about WL detection in ML.  Rather then guessing the hot pixels (based on some percentage), it may be useful to determine the saturation level based on the amount of pixels, at some level based on the histogram, with pixels above the saturation level being discarded.  I can't think of any situations in nature where this would occur, so it should be safe to assume that any pixels above the spike at white, are simply noise.

a1ex

Right, detecting a sharp peak makes sense.

The difficulties appear when the peak isn't very sharp (amplifier gains set way too low), or when the image doesn't have a peak (the image is not overexposed, but it's close - so, in this case, white level detection via percentile would cause useful detail to be marked as "clipped").

Audionut

Personally, I wouldn't consider a situation where the gains have been set to low.  This is a user problem.

@ISO 200, ADTG 4 gains can only be reduced a little further to match the gain of ADTG 2.  For instance, ADTG2 - 888x - 0x37x, ADTG4 - 888x - 0x36x

a1ex

Changing the topic a bit.

I was trying to understand how Roger Clark figured out the full well capacity in electrons, so I've implemented a fairly similar method in raw_diag.

Click for his analysis of 5D3, 6D, 5D2 and 7D.

Basic theory:

- SNR curve can be estimated from the difference of two test images, taken with identical settings, from a static scene.
- Roger recommends shooting a out-of-focus white wall and take a bunch of images. I went for something much easier (but less accurate): simply shoot a out-of-focus HDR scene (with both deep shadows and clipped highlights) and take two test pictures. I think it's enough for our purposes.
- The difference will contain noise multiplied by sqrt(2), because noise from two subsequent images is not correlated (well, mostly).
- If you take small patches of the same color, we can say the patch average (taken from one of the test images) is the input signal, and the patch stdev (taken from the difference image) is the noise level at that input signal. So, we have all we need to plot the SNR curve.

Curve fitting:

- Now, we can fit an ideal model for the SNR curve. I'll use one that combines read noise (assumed constant additive Gaussian) and shot noise (which follows Poisson statistics). Something like this:


dn = patch_average - black_level;
electrons = dn * gain;
shot_snr = sqrt(electrons);
shot_noise = dn / shot_snr;
combined_noise = sqrt(read_noise*read_noise + shot_noise*shot_noise);
model_snr = log2(dn) - log2(combined_noise);


- So, we have a model with two parameters (read_noise and gain), that gives an ideal SNR. We can compare that SNR with measured values (from the SNR curve) and minimize the difference between our model and our measurements.

- Robust statistics tricks / speedup: we have up to 20000 data points; a few of them are outliers, but most of them are OK. I've grouped them into bins, every 0.5 EV, and took the median from each bin. So, now I have up to 28 data points, without outliers. Clean and fast :)

- Since I don't know how to find a closed-form solution for the best fit (if you know how, please enlighten me), I went for a very simple minimization routine: at each step, choose a random point nearby and evaluate the function there; if it's better, keep it, if not, discard it. It does the job.

My results:

I've only tested ISO 100 and 1600 in photo mode.





Wanted: your results



1. grab raw_diag.mo (no need to compile anything, just place it in your MODULES folder).
2. use 1/50 for PAL, 1/60 for NTSC, or any shutter speed if you don't use artificial lights.
3. point the camera to a out-of-focus HDR scene, and adjust ISO and aperture to get a good picture (both clipped highlights and fairly deep shadows).
4. enable Debug->RAW Diagnostics, and from there, select "SNR curve (2 shots)". Disable the other analyses types (unless you want them). Make sure "Auto screenshot" is enabled (it is by default).
5. take the two test pictures from Debug -> RAW Diagnostics -> Dummy bracket. Simply click it once and wait until it's finished.
6. post the screenshot (it's called SNR2.PPM and it's saved under the RAW_DIAG folder; convert it to PNG first to make it smaller, and give it a meaningful name).

I'm looking for results covering all ISOs, for all cameras, both photo and movie mode.

If you wish to review the code or compile yorself, look here.

Have fun!

Audionut

5D3 - Photo mode.  Canon ISOs @ f/1.4 and f/4.0.

ML ISO shots have ADTG 2/4 0xFE 0x3, CMOS4 0x308 and ISO digital gain 0x200 (Canon f/4.0 default) in common. 

ISO 100, ADTG2 888x 0x3cx, ADTG4 888x 0x3ax.
ISO 200-25600, ADTG2 888x 0x38x, ADTG4 888x 0x37x.

Making sure not to have gains reduced to much.

https://www.dropbox.com/sh/ktc2kyabmozjofq/AAC7kSBnzX3E5cwoLn9nrsbYa

If you aren't aware, you can click the blue download button and save the results directly to your own dropbox. :)
It would be handy if the screenshot only captured useful data.  That is, it didn't capture the first image in this dual image sequence.

For those of you who fancy "unity gain", you may be interested in ML ISO 800.


Audionut

Care to share your thoughts on why the SNR reduces around 0.5 EV in the highlights, with an ISO bump?

a1ex

Cool, so the tweaks are confirming the ISO changes with a totally different method (Poisson statistics, instead of linear matching of raw data).

ISO 100, f4->f1.8:
OB noise increase: 6.48 -> 7.14 (1.1x)
read noise increase: 6.71 -> 7.38 (1.1x)
gain decrease: 5.18 -> 4.74 (1.09x)

=> the digital gain applied at f1.4 is about 1.1x. From the digital gain register, previously we have estimated it at 569/512 = 1.11x. Not bad.

LiveView results are interesting, but need to figure out the math first. They might show how many pixels are binned.

@dsManning: can you retry the LiveView tests at ISO 400 and above? They have obvious outliers.

Quote
Care to share your thoughts on why the SNR reduces around 0.5 EV in the highlights, with an ISO bump?

Not sure I understand the question, but I assume it's the difference between ISO 100 f4.0 and ISO 200 f4.0, for example. ISO 200 captures half of the photons, compared to ISO 100, so the shot noise is 1.41x higher. In shadows, the read noise is dominant, and it changes very little from 100 to 200. In highlights, the Poisson noise is dominant, so the difference is roughly half-stop.

For exact figures, you can take the equation of the ideal SNR curve (pasted above), plug the two parameters (estimated read noise & gain) and do the math for any signal level.




This SNR model can be interesting for profiled denoising, since you can model the noise curve with only two parameters (cc @hanatos from Darktable).

Audionut

Quote from: a1ex on June 05, 2014, 09:03:31 AM
ISO 200 captures half of the photons, compared to ISO 100, so the shot noise is 1.41x higher. In shadows, the read noise is dominant, and it changes very little from 100 to 200. In highlights, the Poisson noise is dominant, so the difference is roughly half-stop.

Of course, now it makes sense, thanks.  :)

vicnaum

Do I have to use a tripod? Found it - yes.

How long should it take to sample data? Mine's already working a couple of minutes - maybe it halted?
(600D)

Well, tried it for a couple of times. One time it always said "RAW Error", second time it halted again.

a1ex

Well, it just has to stay fixed while it's taking the two exposures. In LiveView it's not a problem (no mechanical movement), but outside LV it might be (since the mirror vibrations can be strong).

However, if the image is defocused, minor vibrations are unlikely to affect the results.

Computations take a few seconds, maybe 1 minute... didn't time it. If in doubt, record a video of what happens and upload it.

dsManning

Quote from: a1ex on June 05, 2014, 09:03:31 AM
@dsManning: can you retry the LiveView tests at ISO 400 and above? They have obvious outliers.

Fixed.  Same link as above.

https://www.dropbox.com/sh/spiepm7sbts0t7t/AACu3FU3iB6GfDKlkLvwTidva


Quote from: vicnaum on June 05, 2014, 03:21:26 PM
Do I have to use a tripod? Found it - yes.

How long should it take to sample data? Mine's already working a couple of minutes - maybe it halted?
(600D)

Well, tried it for a couple of times. One time it always said "RAW Error", second time it halted again.

Make sure image review from the Canon menu is set to hold.  I had some issues with the different image layers (plot.mo grid, graphed data, curve line) all ended up in different .ppm files.  Seemed like it didn't have the time to process when it jumped back to liveview.  MAY be your trouble.

a1ex

This image shows very good coverage (which is important, since this fitting problem is a bit ill-conditioned).



Are there any conflicts with the plot module? I didn't use it yet, but this refactoring is on my todo list.

dsManning

Quote from: a1ex on June 05, 2014, 04:00:31 PM
Are there any conflicts with the plot module? I didn't use it yet, but this refactoring is on my todo list.

No it seemed to work fine once I got the settings correct.  Before I had image review set to hold in the Canon menu I was getting the data, but I was also getting separate .ppm files in different folders under RAW_DIAG folder (IMG_0001, IMG_0002, etc).  Shown below.

https://www.dropbox.com/sh/l4dlb32q75pqwkn/AAClqaIXy6vsCF6pGyFEcQt9a

vicnaum

Well, it still hangs. With Review Hold, without hold (Off), with 2sec hold. It just draws a dozen of dots and then becomes unresponsive. It hanged with LED on, hanged with LED off.
I used 600D may 08 nightly, then cleared the card and installed clean may 13 - same thing. Btw, 600D has all builds Failed starting from May 13.

Here's the vid:


And here's what's in PPMs:


Btw, I also get this SNR curve (noice profile) table overlay slightly blinking in every menu (including canons own) and LV - even after restart with battery out.

a1ex


dsManning

One thing I noticed while in LV was that I had to hold the half shutter till a box popped up top left of screen saying raw_diag.  Dummy Bracket didn't work for the 50D in LV.  Uploading a quick video (got a terrible curve, not on a tripod, no audio, just showing how to make it work) to show that it works in LV, just have to not use Dummy Bracket.


Greg


a1ex

Quote from: dsManning on June 05, 2014, 05:33:48 PM
Dummy Bracket didn't work for the 50D in LV.

Were you in movie mode LiveView, or photo mode LiveView? It matters here.

dsManning

Quote from: a1ex on June 05, 2014, 07:24:48 PM
Were you in movie mode LiveView, or photo mode LiveView? It matters here.

Movie mode.  Get mixed results with LV on and Dummy Bracket.  Here is another one.  This one seemed to process, but the overlays are strange if I don't do halfshutter.

https://www.dropbox.com/sh/l4dlb32q75pqwkn/AAClqaIXy6vsCF6pGyFEcQt9a

Marsu42

Quote from: a1ex on June 05, 2014, 01:23:21 AM
Wanted: your results

You keep updating the module in the repo - should we wait some more, or is this the one you want the tests to be run with? If I take the time to cover the 6d, I really don't want to do it twice :-p

a1ex

The changes were not essential, so you can just grab a copy and run the tests. All the previous graphs are still valid, maybe with less fancy displays.

a1ex

Reproduced the lockup in 5D3 at 50fps and hopefully fixed it.

I made some core changes for a clean fix, but I've applied some workarounds in the precompiled binary, to allow it to run on older nightlies out of the box. So, download the binary raw_diag.mo from this post (or the first post, it's the same) and it should just work.

SpcCb

Ran on 5D2 with 2014-05-30 NB, 2 shots pass but get the message: "You may need to solder some RAM chips :(".

edit:
Debug shows a memory error -> shoot_malloc(29MB) failed at raw_diag.c:445, raw_diag_task.

a1ex

Solved (well, workaround; will still show error in the Debug menu, but it will work).