CMOS/ADTG/Digic register investigation on ISO

[g3gg0]

thanks for the plots.
it really looks like i expected it to be. values in the first OB line are either "overexposed" or "underexposed", the whole line too bright or dark.
thats because before reading out the sensor, the black clamp is at a not-perfect value.

then the first line is sampled. all values that go into the ADC get the black clamp voltage added.
as it is too high or low, the output will be too dark or bright.
the ADC will adjust the black clamp voltage (from an DAC) (*) to a value that makes the black region looking the best.
(we dont know the real target values yet)

this process happens in the first few lines, thus they are crap. totally white or black or just b/w noise.
lets call this the OB calibration.

for every line now the ADC uses the OB pixels in front of the real image to re-adjust the OB clamp to match the target value.
there should only be a small drift (i guess only V_adcref swings should need compensation)

so with dual_iso (if i understood alex correct) the ADC will have a lot of to compensate. it might or might not be finished with that adjustment when image data in this line starts.

@alex:
you wrote that with high iso difference the value of the OB areas to the left varies much more.
did you check the variation of the leftmost OB pixels compared to the rightmost OB pixels (on the left side of the image) in dual_iso images?
the rightmost OB pixels in front of the image data could give you a good hint how good the black level was compensated.
all lines should have about the same value there. (*) ...if the values are updated after every pixel though...

if these theories are correct then you might confuse the ADC with dual_iso as it doesnt have enough time to compensate OB.
this maybe just happens under extreme conditons, like a hot sensor or bad battery.
still i think we should know about this fact.

(*)=what i still dont know is if the black clamp is updated after every pixel or after the OB area ends (every line in top OB and on the left OB area when its over)

[a1ex]

Yes, so the top few lines are the raw (uncorrected) output from the amplifiers. Notice how it repeats every 8 columns.

This number being small, a possible hypothesis is that it's simply not enough to correct the banding because the noise could not be averaged well enough (so finding the register that increases the number of these lines should help). To check this hypothesis, I'd like to see such a screenshot from 6D (which doesn't suffer from FPN).

Regarding dual ISO, here's a screenshot that shows both OB zones (100/6400):


A while ago you found a register named "line count that gets darker" (ADTG2[82F3]). For some reason I've tagged it as NRZI, though I didn't double-check it. So, now I've changed this register from 0x30 NRZI (0x20 decoded) to 0x50 NRZI (0x60 decoded) and the result is:


(that is, the OB area is now larger by ~70 pixels)

[Audionut]

From the pdf g3gg0 linked last page.

Optical Black Clamp

The optical black clamp loop is used to remove residual offsets in the signal chain and to track low frequency variations in the CCD’s black level. During the optical black (shielded) pixel interval on each line, the ADC output is compared with a fixed black level reference, selected by the user in the clamp level register. The value can be programmed between 0 LSB and 255 LSB in 1023 steps. The resulting error signal is filtered to reduce noise; the correction value is applied to the ADC input through a DAC. Normally, the optical black clamp loop is turned on once per horizontal line, but this loop can be updated more slowly to suit a particular application. If external digital clamping is used during postprocessing, the AD9992 optical black clamping can be disabled using Bit D2 in the AFE Register Address 0x00. When the loop is disabled, the clamp level register can still be used to provide fixed offset adjustment.

The CLPOB pulse should be aligned with the CCD’s optical black pixels. It is recommended that the CLPOB pulse duration be at least 20 pixels wide. Shorter pulse widths can be used, but the ability for the loop to track low frequency variations in the black level will be reduced. See the Horizontal Clamping and Blankingsection for timing examples. 

[SpcCb]

(...)
@SpcCb: that colorful palette is likely a bug in the screenshot code (another reason to rewrite it) or in the file copying code. Reproduced it.

When I saw that I retried a couple of times, but I thought it was not a problem because we want to check zone sizes.

Regarding linking errors:

camera_model_short became private because most modules were checking only the camera model name, but not the firmware version. This could cause trouble if somebody loads a module expecting a different firmware version (the upgrades in progress are 5D3 113->123, 7D 203->205 and 700D 111->113). So, to force all modules do proper checking, I made the old way obsolete.

(...)

I understood, it is not adequate to only check the camera model, firmware version also need to be check.

So to port mini_iso tool on last nightly builds I thought to update:

Code: [Select]

if (streq(camera_model_short, "target_model"))with:

Code: [Select]

if (IS_CAMERA("target_model", "target_firmware"))Should work like that isn't?

I don't use ATDG_GUI actually; I tried to compile ML with adequate config to run it but for the moment I only get wrong compilation and my camera crashes all times on load, I don't see why for the moment and it's a bit freaky to crash camera every times.

[a1ex]

Again: do not rush, be patient.

[Marsu42]

camera_model_short became private because most modules were checking only the camera model name, but not the firmware version.

To "fix" it and continue using the legacy binary, simply un-private the symbol in your local build - you can then be more patient to wait for the result of the current in-depth investigation.

[g3gg0]

Yes, so the top few lines are the raw (uncorrected) output from the amplifiers. Notice how it repeats every 8 columns.

hmm not sure. might even be corrected, but with the wrong black clamp value.
dont remember that the datasheets said to output dummy values during OB areas. have to doublecheck.
i thought these are the *corrected* values, but with a *wrong* black level untuil the internal calibration has no need to update black clamp anymore.
might be updated after every pixel, might also be updated after every line (when the OB state input is toggled) dont know.

the images you posted show in the top OB area how the b/w noise gets a gray noise smoothly. (3rd pixel line?)

(that is, the OB area is now larger by ~70 pixels)

hmmm 0x40 (=64) lines more?
after the original OB area, the brightness goes down a bit?

during OB area we see the same pattern that causes vertical banding on most models?
ever 8 pixels a bit brighter/darker? i see some connection between the two things...

[a1ex]

The top OB has some correlation with the vertical FPN, but it's fairly weak. I could use that info to reduce its stdev from ~0.72 to ~0.5, but didn't check with a validation data set.

[g3gg0]

weak = not the same amount, but the same pattern?
then its an offset

edit: i mean the same offset that was scaled in these pixels due to black level being wrong.

[a1ex]

weak =

Code: [Select]

b = mean(im(80:end,:));
top = mean(im(1:80,:));
t1 = mean(im(5:40,:));
t2 = mean(im(45:80,:));

xcov(top,b) => 0.31
xcov(t1,b) => 0.35
xcov(t2,b) => 0.64

Will add some graphs later.

[SpcCb]

Again: do not rush, be patient.

Don't worry, I'm very.
Au contraire, I find that ML evolutes too fast! (many times I oar to assimilate new possibility )
But here it is to get a tool to help: Since last month I run a mod min_iso to observe impact of TV/ISO/ADTG/etc. settings on OBRA.

[g3gg0]

what if:
we have two/four ADC converters with 8 channels each.
every ADC converter has 8 channels, just like the 4 channel one here

4x ADTG with 8 channels each: explains the 8 pixel pattern.

[SpcCb]

Do you think this architecture concerns 5D3 only or _some_ other cameras too?
Thought is if we could drive CDS it could help to reduce FPN.

[SpcCb]

In addition to this, maybe it also could help:



Area delimitations are not accurate because it depend of the architecture, but this is the typical setup for CMOS, specially those made for high speed video applications.
The setup looks to what we get on our cameras, apparently.

[Greg]

500D

[g3gg0]

In addition to this, maybe it also could help:

my current theory is that these top zones are no digital data.
its just the output of the ADC as it is in its black clamp learning phase.

[SpcCb]

If you refer to the very first rows (4~5) I agree; the device maybe uses these rows to acquire the proper black level (apparently the first rows to be read out).

[Audionut]

ADTG6[8880] - Lower values


Higher values



ADTG6[886a] 0x10

A while ago you found a register named "line count that gets darker" (ADTG2[82F3]). For some reason I've tagged it as NRZI, though I didn't double-check it. So, now I've changed this register from 0x30 NRZI (0x20 decoded) to 0x50 NRZI (0x60 decoded) and the result is:

0x6f (decoded)


0x0


As far as I know, the optical black area is labelled as such, because it doesn't receive photons.
So the image must be digitally shifted?

[g3gg0]

ADTG6[8880] - Lower values

-> target black value the black clamp should be calibrated for?

ADTG6[886a] 0x10

-> number of top lines the ADTG has to interpret as OB area?

[a1ex]

Latest raw_diag has a tool that renders dark frames as grayscale, without demosaicing, downsampled by averaging from full size to 720x480, which reveals FPN. Gray levels from +/- ob_stdev/4, which maps to roughly +/- 2 averaged_stdev after downsampling.



Samples: ISO 100, 100 (second try), 1600, 6400, 100 pulled from 200, all 1/8000. Notice the lack of correlation between the two ISO100 dark frames, and notice how clean ISO 6400 sems to be. However, don't forget these are not absolute noise levels; they simply show the ratio between FPN and Gaussian noise.

Quick theory about why FPN gets revealed by downsampling:

Assume the total noise is a Gaussian noise applied to each pixel + Gaussian FPN applied to each column.

If you downsample the image by 0.125 x 0.125 (that is, 1/8 in each direction), the noise stdevs will be, compared to a 1:1 crop:

    sqrt(8x8) = 8 times smaller for the Gaussian noise
    sqrt( 8 ) = 2.8 times smaller for the Gaussian FPN

=> Gaussian noise gets averaged out faster than FPN.

Roger Clark has similar samples here: http://www.clarkvision.com/articles/evaluation-canon-5diii/index.html
but I believe they are downsampled by nearest neighbour (Audionut, since you already have contact with him, maybe you can ask?)

In this case (no averaging involved), the stdevs for noise and FPN would be similar to the ones from a 1:1 crop (which could explain why his 1600 sample is cleaner than mine).

[Audionut]

Roger Clark has similar samples here: http://www.clarkvision.com/articles/evaluation-canon-5diii/index.html
but I believe they are downsampled by nearest neighbour (Audionut, since you already have contact with him, maybe you can ask?)

I thought they were crops.

Table 2a. Apparent Read Noise, Central Image

Central 500 x 300 pixel statistics:
min= 132 electrons
max= 198 electrons
mean= 162 electrons
standard deviation= 2.99 electrons

But I'll ask.

The high frequency components of grain are generally visually pleasing, because they help to increase apparent detail.  Averaging removes the high frequency components of the image, leaving only the low to mid frequency components.  In this case it's even worse, because all those fine details (noise or otherwise), combine to become lower frequency components. 

Averaging increases apparent edge detail.  This is excellent on wanted (edge) detail, not so much on detail that isn't wanted.  Averaging also increases aliasing, but this isn't a problem with FPN, because the edges are straight.

The maths might say the noise level (of the FPN) was decreased 2.8 times when it was averaged, but it doesn't tell you exactly what happened with the remaining noise.  In this case, while the total noise dropped, the remaining noise became more visually destructive.

https://theory.uchicago.edu/~ejm/pix/20d/tests/noise/index.html#patternnoise

This gives an indication of how visually disruptive pattern noise can be -- even though the fixed pattern noise is only about 20% of the overall noise, it is quite apparent because our perception is adapted to picking out patterns, finding edges, etc.

There are a number of algorithms being designed to measure this subjectivity, but afaik, our eyes are still the best determinator.

http://en.wikipedia.org/wiki/Human_Visual_System_Model


For a visual representation of the FPN, the averaging works extremely well.  Because it emphasis the FPN (visually).

Since the FPN remains consistent (mainly vertical in this case), do you think you could measure the average brightness in a column (1 pixel wide, or maybe even 2 or 3 pixels wide will be sufficient), and then analyse the data in a row?

By measuring the data vertically, you should end up with a data set like so.

1, 3, 5, 1, 1, 5, 1, 9, 3, 6, 7

Since the Gaussian component of the noise should hover around a median (equal in each vertical measurement set), the data set should accurately represent the FPN component?

[a1ex]

The maths might say the noise level (of the FPN) was decreased 2.8 times when it was averaged, but it doesn't tell you exactly what happened with the remaining noise.  In this case, while the total noise dropped, the remaining noise became more visually destructive.

It does - the random component decreased 8 times. That's why the FPN became more destructive.

The ratio between FPN stdev and overall noise stdev should be a good indicator of how badly the FPN affects the image.

Since the FPN remains consistent (mainly vertical in this case), do you think you could measure the average brightness in a column (1 pixel wide, or maybe even 2 or 3 pixels wide will be sufficient), and then look at this data horizontally?

If I understand the question well, the FPN analysis from raw_diag does exactly this.

If you subtract the two FPN components, estimated by averaging, you end up with this.

Problem: you can't do that on a dark frame and then use that data to correct a useful image, because the FPN is not correlated between images (well, the autocorrelation is extremely weak, as you can see from the "xcov" analysis in raw_diag).

[g3gg0]

i believe your theory about the missing corellation of FPN between shots.the shots show that.

but. how do we get a FPN that is horizontally and vertically repeating in the single image?

if you average the top OB area, you will get the vertical FPN, right?
now subtract that from the whole image and do the same for horizontal FPN using the left OB area.
also subtract that noise frome very column and the low frequency part of the noise should be gone?

[a1ex]

if you average the top OB area, you will get the vertical FPN, right?

Nope, answered here.

You do get an improvement, but it's small.

[SpcCb]

Latest raw_diag has a tool that renders dark frames as grayscale, without demosaicing, downsampled by averaging from full size to 720x480, which reveals FPN. Gray levels from +/- ob_stdev/4, which maps to roughly +/- 2 averaged_stdev after downsampling.

Samples: ISO 100, 100 (second try), 1600, 6400, 100 pulled from 200, all 1/8000. Notice the lack of correlation between the two ISO100 dark frames, and notice how clean ISO 6400 sems to be. However, don't forget these are not absolute noise levels; they simply show the ratio between FPN and Gaussian noise.

(...)

Wohh, you get a strong corners illumination @ISO 1600 & 6400!
'Hope this is not a electromagnetic field effect as we got on old camera models (350D etc.).

(...)
The high frequency components of grain are generally visually pleasing, because they help to increase apparent detail.
(...)

I agree. It is an interesting psycho visual effect.
Plus, it help to dither level banding effects in image with large gradients or pseudo flat areas.