CMOS/ADTG/Digic register investigation on ISO

[a1ex]

5D2:

CMOS[4] = 0x242 at iso 100...800 and 0x244 at iso 1600. Setting it to 0x[46ce]4[24] (e.g. 0x442 at low ISO or 0x444 at high ISO) seems to squeeze 0.2 more stops of DR. Not yet sure if in highlights or shadows (I believe it's in shadows, since clipping point didn't change); feel free to pixel-peep and tell me.

5D3:

CMOS[3] = 0x944 at lower ISO and 0x144 at higher ISO. Doesn't seem to make a difference.
CMOS[4] = 0x718. Set it to 0x300...0x37f to squeeze 0.1 stops of DR. Setting he 0x80 bit results in white image. Other values like 0x100, 0x200, 0x400 result in different noise/DR levels.
CMOS[6] and [7] seem to do something about white level clipping and darkening the image. No clear conclusion yet.

[dspographer]

I haven't read this entire thread, so I don't know if this has been discussed: but the raw converter should be updated to be able to handle the new type of saturation. I asked the libraw author what needs to be done and this was his answer:
http://www.dpreview.com/forums/post/52994258

[a1ex]

Short answer: current raw converters will work unmodified.

However, for best results, I believe raw converters should use an autodetected white level, instead of assumming a fixed value. This is especially important *without* this tweak.

With plain Canon firmware, white level varies wildly with intermediate ISOs and also with aperture. With the tweak, I'm disabling these variations.

There are also white level variations at long exposures. I can't do much about these.

There are no nonlinear issues in Canon sensors as far as I could tell. When it clips, it clips abruptly. There are, however, bad pixels with values above the clipping point, and one should be careful about this when autodetecting the white level.

I'm planning to submit a patch to dcraw and ufraw, with white level autodetection. Dcraw assummes fixed values around 13000...15600, depending on the camera model, which is plain wrong (sorry). I believe Dave simply took the white level from one of the test shots he received (because I could get his exact white level by adjusting the aperture). I believe this is the cause of most (if not all) pink highlight problems with dcraw-based converters.

Things might be different with Dual ISO, but that's another story (that's something I'm handling in the converter).

[Audionut]

I had a screenshot with DR @ 11.494 with a little less ADTG gain, but I lost it somewhere.  Still, this one is 0.13EV better then my previous best (so close to 11.5). 
I should be in bed, not tweaking registers 
I'll post some more information tomorrow.

[a1ex]

With a little less ADTG gain than calibrated value, the DR reported by raw_diag may be false (overestimated), because you'll get variations in clipping point.

If in doubt, recalibrate the gain. This will make sure everything clips at the same point.

[Audionut]

Sorry, it's late.

A little less negative gain.  So a higher register value. 

The histogram wasn't as clean, but DR was higher.

[a1ex]

I believe DR is also influenced by roundoff errors, so I'm not sure what to say yet.

Maybe using a more robust indicator instead of stdev (e.g. MAD) makes more sense?

[dmilligan]

There are no nonlinear issues in Canon sensors as far as I could tell. When it clips, it clips abruptly.

This seems unlikely to me, electronics are by nature non-linear, esp. near saturation. What was your methodology?

http://photo.stackexchange.com/questions/33984/how-linear-are-dslr-sensors/33985#33985

However when a photosite is nearing saturation various electrical effects reduce the charge generated by incident photons leading to a roll-off of the response curve (i.e. it becomes shallower).

Rodger Clark describes a methodology for determining the linearity of the sensor reponse (among other things) in this article:
http://www.clarkvision.com/articles/evaluation-1d2/

[a1ex]

What was your methodology?

cr2hdr --iso-curve

However when a photosite is nearing saturation various electrical effects reduce the charge generated by incident photons leading to a roll-off of the response curve (i.e. it becomes shallower).

I wish it was like that, but could not find any sign of it. A graph from last night, with ADTG gain lowered much under the sweet spot:



(I could not find any correlation between these variations and the actual signal data, so I believe they are just noise)

Also, I could not see any nonlinearity on the graph from Roger Clark. So, for practical purposes, the data is linear and clips abruptly.

[Marsu42]

Short answer: current raw converters will work unmodified. However, for best results, I believe raw converters should use an autodetected white level, instead of assumming a fixed value. This is especially important *without* this tweak.

Is this also true for ACR, or only for the oss ufraw/dcraw, i.e. when using Adobe apps, will using mini_iso result in artifacts or other problems? From what I've tested for myself everything looks fine, but then again I didn't know what problems to look for.

[ayshih]

Saturate offset is not adjusting the black level per se, it's only adjusting the offset*.
B/W offset isn't any form of gain, it's digitally shifting the analog signal into the recorded bit depth.
...
*The offset is so far down into the noise floor that it does not effect black in the recorded image.  The offset can be adjusted higher then the default value, but there doesn't appear to be any gain to DR.

It's a bit of an aside, but I object to your characterizing SaturateOffset as only an "offset", and the implication that changing SaturateOffset is not useful for improving DR.  However, perhaps I am reading too much into your choice of words.  SaturateOffset changes the digitized value of the black level without changing the digitized value of the white level, which has DR consequences.

In my mental picture of the electronics, there are two relevant DACs:

• The first DAC produces the reference voltage for the black-level clamp, and this clamping occurs before the ADTG/DFE amplification stage.  The corresponding register is SaturateOffset (0xc0f0819c).
• The second DAC produces an analog offset that is added to the signal after both amplification stages, before it is fed into the ADC.  The corresponding register is B/W offset (0xC0F08034).

Thus, changing B/W offset just shifts the digitized values because it just shifts the signal up or down in analog space.  There is no change in the dynamic range because the black level and white level move together and the read noise stays the same.

On the other hand, SaturateOffset is more than just an offset because it comes before at least one stage of amplification.  At the output of the amplifier, it becomes directly related to the separation between the black level and white level (which is the saturation at the rail of the amplifier).  Increasing SaturateOffset decreases this separation, meaning that saturation occurs at a lower analog signal, so your DR must decrease.  Conversely, decreasing SaturateOffset must increase your DR.  (The changes in DR may be negligible if the register change is small).

For example, at ISO 100 on the 50D, you can achieve most of the DR improvement by just changing these two registers, without touching any amplifier gains.  (While changing B/W offset itself doesn't change DR, increasing it provides more room to decrease SaturateOffset.)

[a1ex]

Is this also true for ACR, or only for the oss ufraw/dcraw, i.e. when using Adobe apps, will using mini_iso result in artifacts or other problems? From what I've tested for myself everything looks fine, but then again I didn't know what problems to look for.

The only problems that may appear are either pink highlights or too many clipped highlights. Adobe DNG Converter seems to use a white level fixed to 15000, but it's important how the data above this level is actually handled (wheter it's used for highlight recovery or not).

You can check with "exiftool IMG_1234.dng -WhiteLevel=3000"; if you can recover the highlights, all is fine. With ufraw you can't.

[dspographer]

a1ex:
Have you looked at saturation vs which of the parallel read channels is being used? I am wondering if the 2 apparent clipping points in your plot are from different read channels.

cr2hdr --iso-curve

I wish it was like that, but could not find any sign of it. A graph from last night, with ADTG gain lowered much under the sweet spot:



(I could not find any correlation between these variations and the actual signal data, so I believe they are just noise)

Also, I could not see any nonlinearity on the graph from Roger Clark. So, for practical purposes, the data is linear and clips abruptly.

[a1ex]

Yes, they are. Each column has its own clipping point (but there are two groups, indeed). The pattern repeats roughly every 4 columns, but there are clipping point variations on top of that.

I've removed the constant offsets and looked in the clipped area, but could not find any image details. I will do a controlled experiment and post a detailed analysis if there are people interested; this one was just from troubleshooting a dual ISO shot from 6D.

But this is not what you are getting normally in a CR2 file. In a CR2, things are simply clipped sharply (at the level where the mouse cursor is in my graph). This graph could be relevant for recovering even more DR with some clever algorithm, but from my early tests it seems quite unlikely.

[dspographer]

Have you done any studies to see how stable the clipping point is? I am wondering if the fixed level chosen for .CR2 files might be too high for some circumstances. Some major things that come to mind that might change the clipping point are: battery voltage, temperature, and camera to camera variation.

[a1ex]

At short exposures I get the same white level every day (checked with raw_diag, with these tweaks enabled and ADTG gain at sweet spot, not below). On 5D2 I've configured it at 16380, but I can choose any other value.

At long exposures, white level may become lower, but this also happens with Canon firmware.

[dmilligan]

Also, I could not see any nonlinearity on the graph from Roger Clark. So, for practical purposes, the data is linear and clips abruptly.

Right, but he was not using your ADTG trick, nor the same camera or even the same generation of camera. I simply posted that article as a demonstration of methodology, the idea being that you or someone else carry out that same methodology with the ADTG trick to determine if we are reaching into the non-linear part of the sensor response.

The basic idea is that you take pairs of exposures and subtract them, this residual is simply the square of the noise of one of the exposures, since photon noise is simply the sqrt of the number of photons, we can determine the true reponse in photons based on the std dev of the residual frame.

[a1ex]

The basic idea is that you take pairs of exposures and subtract them, this residual is simply the square of the noise of one of the exposures, since photon noise is simply the sqrt of the number of photons, we can determine the true reponse in photons based on the std dev of the residual frame.

I'm actually using this trick to get an estimation of the noise from bracketed shots on a sturdy tripod (download the samples from engardeknave from the CeroNoice thread), and I found the noise estimated in this way to be very good regarding Gaussian shape and lack of autocorrelation.

[jkaura]

You can check with "exiftool IMG_1234.dng -WhiteLevel=3000"; if you can recover the highlights, all is fine. With ufraw you can't.

Tried this briefly with one DNG image file in Adobe Lightroom 5 and, indeed, the highlights were lost. After setting the white level to 3000 in the EXIF metadata, one cannot recover the lost highlights using the conventional Exposure, Highlights, White or Tone Curve adjustments.

In fact, my attempts to restore the original white level back by executing:

Code: [Select]

exiftool IMG_1234.dng -WhiteLevel=15000
on the command line did not succeed completely even after reading the metadata back from the file. Changing DNG camera profile from Adobe Standard to Camera Standard on the Camera Calibration tab fixed the issue temporarily but after returning from the Library module back to Develop module, the highlights seemed to be lost again. I should better comprehend myself with the Lightroom's metadata management since I don't quite understand how reverting the white level setting (at EXIF level) should be done in Lightroom. Anyway, it seems to me that the most recent release of this software does not resolve the white level from the actual image data.

[Marsu42]

I should better comprehend myself with the Lightroom's metadata management since I don't quite understand how reverting the white level setting (at EXIF level) should be done in Lightroom. Anyway, it seems to me that the most recent release of this software does not resolve the white level from the actual image data.

Thanks for trying this - so if I understand correctly, acr (or at least lr) cannot harvest the dynamic range gained from using mini_iso?

Btw I wouldn't have expected that simply changing one exif tag is enough for acr, I guess they're using a bunch of maker notes and dng tags for the technical stuff and the exif data is only there for a limited subset of image property descriptions.

Last not least, if saving/restoring metadata doesn't do it, maybe it's worth a try to remove the dng from the catalog and then re-add it, maybe not all "internal" tags Adobe doesn't expect to change are updated when reading an exif-modified dng (just a guess).

[a1ex]

I'm asking you to check that, so I know what level I should choose in mini_iso (and whether it makes sense to make it configurable).

@jkaura: I think this explains why I've got better highlight recovery (compared to ACR) with a really dumb algorithm: http://www.magiclantern.fm/forum/index.php?topic=9458.msg91590#msg91590

and from your findings, I believe that - on top of the DR graphs I'm plotting - you will also get back some more highlights at wide apertures, that might be lost because of digital amplification of the raw data. Check the first post for details.

[Marsu42]

I'm asking you to check that, so I know what level I should choose in mini_iso (and whether it makes sense to make it configurable).

Make what exactly configurable - the cr2 tags aren't modified by mini_iso, or are they?

[a1ex]

The CR2 doesn't have any tag for white level, but I can change the range of recorded data (black and white level).

[jkaura]

Last not least, if saving/restoring metadata doesn't do it, maybe it's worth a try to remove the dng from the catalog and then re-add it, maybe not all "internal" tags Adobe doesn't expect to change are updated when reading an exif-modified dng (just a guess).

Thanks for the tip, that worked for me! After removing the photo from the catalog and reimporting it, the white level seems to be again at a normal level.

[Marsu42]

Thanks for the tip, that worked for me! After removing the photo from the catalog and reimporting it, the white level seems to be again at a normal level.

Yippee, I'm contributing something useful again for a change :-p

The CR2 doesn't have any tag for white level, but I can change the range of recorded data (black and white level).

Meaning as in "keeping the increased dr, but just recording it with different 14bit (16bit?) values", or as in "dimming down the effect of mini_iso because acr currently cannot cope"?

Edit: In any case, an alpha mini_iso.mo with advanced configuration for this to debug probably is a good idea, esp. if the source code isn't available yet.