Thus analysis will be difficult because it's a 'black box' thingy with all those amps ADCs and more inside.

I figured that I'd start with rows and columns. Here's a selection 2 pixels high and 200 wide (if it's not at least two in the small dimension, you only get half the channels).

And here's one 200 high and 2 wide:

I don't know if I've gotten to a single amp and ADC in either case, but if I have, the following is a reasonable interpretation. There are peaks separated by about 20 counts, as you would expect from an ISO about 20 times the unity gain ISO. There appears to be noise after the amp and before the ADC with a standard deviation of about 6 LSBs. However, it also looks like the ADC is functioning effectively as a 12-bit device. What's up with that?

I don't know if I've gotten to a single amp and ADC in either case, but if I have, the following is a reasonable interpretation. There are peaks separated by about 20 counts, as you would expect from an ISO about 20 times the unity gain ISO. There appears to be noise after the amp and before the ADC with a standard deviation of about 6 LSBs. However, it also looks like the ADC is functioning effectively as a 12-bit device. What's up with that?

To paraphrase Slick Willy "it all depends what the meaning of 'up' is . ."

Earlier, out of interest, I calculated the D800 Unity Gain ISO using Clark's method. For a 12-bit in-camera setting it comes to 666 (!). For a 14-bit it comes to 108 which is quite interesting. So, back to 666, 20 times brings us to 13,300 ISO, not 6,400. I'm probably obfuscating the difference between theory and practice, so feel free to ignore this post.

You can see that there are a lot of missing codes. In fact, there are typically three empty codes between each occupied one.

If the gears in your head are turning and you're thinking, "Yes, but with a unity gain ISO of around 300, at ISO 6400, the "gain" is about 20, and there should be more missing codes than that." Well, you're right, but consider the limitations of the experiment. With this test, I am probably using all the amplifiers and maybe all the ADCs, all of which have slightly different characteristics. If I could test one amp and one ADC, I'd probably get bigger gaps in the histogram.

Your examples are excellent, Jim, and stimulate further thinking. Interesting that the values have roughly the same sized gaps (i.e. 1 value about every 4 ADUs) and those that are present are the same for the three channels (i.e. 434, 438, 442 etc.). This could suggest that the histogram was fully populated at the output of the ADC, but that there was a digital multiplication by a factor of around four (the other gaps could be explained if it wasn't exactly 4x) after that before the data was written to the raw file. In other words gain is increased on the actual ADC (analogically?) up to somewhere around ISO 1500 (6400 divided by 4+). The fact that the amps and ADCs are not all exacly the same contributes to the (nevertheless outstanding) read noise of the D800e, helping to fully populate the histogram up to that point. After that it is a simple digital multiplication by 4+, creating the gaps.

We are able to record virtually the same information as in the first case plus some more.

I would phrase it, "We are able to record virtually the same information, plus some more noise, and not as much of either at it looks like we are recording from looking at the broad-brush histogram (because of the missing codes we can't see when we're looking at the whole histogram)."

Jim

I assume that you are referring to the case where, for a set exposure and having the highlight headroom in the raw data, one would increase ISO from 100 to 400. Yes, I agree. Except that I suspect that we would be able to record the same information, in part because of read noise dithering and in part because of shot noise dithering - the gaps would need to be much bigger than that to start affecting perceived information at these Raw values. It would be interesting to see the histogram in the first hundred ADUs or so.

I don't know if I've gotten to a single amp and ADC in either case, but if I have, the following is a reasonable interpretation. There are peaks separated by about 20 counts, as you would expect from an ISO about 20 times the unity gain ISO. There appears to be noise after the amp and before the ADC with a standard deviation of about 6 LSBs. However, it also looks like the ADC is functioning effectively as a 12-bit device. What's up with that?

Still exactly the same values show (and don't show) up with the same interval. Looks like about 4x digital amplification after the ADC, which would make it function look like a 12 bit one [EDIT: the other 2 bits represent data beyond full scale].

On the other hand good show on attempting to isolate the amp/ADC. You've probably got more than one there. This is quite an eye-opener and I need to digest all this great info a bit.

Earlier, out of interest, I calculated the D800 Unity Gain ISO using Clark's method. For a 12-bit in-camera setting it comes to 666 (!). For a 14-bit it comes to 108 which is quite interesting. So, back to 666, 20 times brings us to 13,300 ISO, not 6,400. I'm probably obfuscating the difference between theory and practice, so feel free to ignore this post.

Ted, I get what Jim suggested, about 320 ISO at 14 bits. I get that by taking FWC of roughly 52600 dividing by the number of ADUs at full scale (16382 for the 'e') and multiplying by 100. The method you outlined does exactly the same but with a few redundant operations: reread your post, the answer is always n*100

With the D4 under the same conditions, all bits are used. First, a 200 x 2 column view:

Next, a 2 x 200 row view:

From the greater fill in the column, I'm guessing that the ADCs read by column. With a Unity Gain ISO of about 700, an electron charge should make a 10 LSB difference. The data can be interpreted that way if you're looking for it. The standard deviation of the noise appears to be on the order of 2 LSBs. The counts are low enough that all this interpretation is suspect, however.

Making the column 1000 pixels high shows no periodicity in the histogram. I think that a definitive answer will need some more sophisticated analysis than histograms. Does anyone know a good way to turn raw files into 4 monochromatic TIFFs, preferably in batches? I'm not excited about using DCRAW. ImagesPlus?

Ted, I get what Jim suggested, about 320 ISO at 14 bits. I get that by taking FWC of roughly 52600 dividing by the number of ADUs at full scale (16382 for the 'e') and multiplying by 100. The method you outlined does exactly the same but with a few redundant operations: reread your post, the answer is always n*100

Thanks, I didn't know the FWC so I used a value from a similar camera which I shouldn't have, tsk.

I think that a definitive answer will need some more sophisticated analysis than histograms. Does anyone know a good way to turn raw files into 4 monochromatic TIFFs, preferably in batches? I'm not excited about using DCRAW. ImagesPlus?

ImageJ does lots of things that I've never used and don't understand.IrfanView can mess with colors but I'm [edit] not sure about at RGGB level.I don't have any non-Foveon raw files, well apart from old compressed D50 NEFs.

Jack, even if I screwed up and turned lossy compression on, it shouldn't cause this effect, since the signal level is about 5 stops below full scale.

Of course. I meant that you only need 600 or so codes to represent fully information from a 12-bit ADC with 4095 at full scale. Lots of free levels there and nobody's noticing. Apparently Nikon also does WB preconditioning, that's why you get gaps in the Raw data even in the green channel at ISO 100.

Still exactly the same values show (and don't show) up with the same interval. Looks like about 4x digital amplification after the ADC, which would make it function like a 12 bit one.

I got interested in the missing codes, and evaluated some exposures made with five different cameras under the same conditions. The subject was the back of a lens cap. The exposure was 1/4 sec. The aperture was all the way stopped down, just to make sure. The ISO was 6400. The exposures were the first after the camera had "rested" a bit, although I'd seen not much in the way of thermal effects previously. I selected a central area 200x200 pixels, and ran a histogram of the region between a count of 4 and one of 100.

I used dark noise as a way to make sure that the always-on-no-matter-what-you-do tone curve compresion of the Sony cameras wouldn't come into play.

First, let's look at the two cameras that behaved as expected. The first of those is the Nikon D4.

A few missing codes in the red and blue channels, which could well be due to ADC defects, or also digital gain applied to the red and blue channels. I'm thinking it's digital gain, because the noise appears to be higher in the red and blue, and I can't think of a reason why that would happen.

The next unsurprising results are from the Leica M9:

Noisier than the D4, to be sure, but that's no surprise, and no missing codes at all.

The Sony RX-1 shows an interesting result:

There are missing codes galore. The two green channels look quite different from each other. The upper green channel and the blue channel seem to be acting as if they'd been digitized by a 12-bit ADC, while the lower green channel and the red channel are doing a fairly good imitation of 13-bit digitized signals. The loss of the LSB might be due to some kind of digital gain that Sony puts in at higher ISOs, but I can't image that they'd so that with some channels and not with others, so I am at a loss to explain the low-resolution green channel and the blue channel results. A really bad ADC might miss some codes, but this is a 40,000 pixel sample (10,000 for each color plane), and probably is using several ADCs. I'm at a loss here.

Next up, the Sony NEX-7:

Wow! We're seeing steps of about 16 LSBs between occupied buckets, but it's not exactly 16 LSBs, and it's not just as if the lower four bits have been lopped off.

Finally, the Nikon D800E:

This is interesting, because, although the channels are mostly looking like they'd been digitized with a 12-bit ADC, there are many places where adjacent 14-bit codes are occupied, indicating that the comblike nature of the histogram is not the result of any planned processing.

Maybe this is an invalid test because dark noise may be patterned, but I think there's something worth exploring here. The results for he M9 and D4 indicate that some cameras respond to this test in a way that you'd expect them to.

I'm not sure where to go from here, but I'm going to pursue this. It could have serious implications for what Unity Gain ISO should mean to photographers using the D800E and the two Sonys.

I got interested in the missing codes, and evaluated some exposures made with five different cameras under the same conditions. The subject was the back of a lens cap. The exposure was 1/4 sec. The aperture was all the way stopped down, just to make sure. The ISO was 6400. The exposures were the first after the camera had "rested" a bit, although I'd seen not much in the way of thermal effects previously. I selected a central area 200x200 pixels, and ran a histogram of the region between a count of 4 and one of 100.

I used dark noise as a way to make sure that the always-on-no-matter-what-you-do tone curve compresion of the Sony cameras wouldn't come into play.

Fabulous work, I always wondered exactly where the gaps in the low ADUs (i.e. where Raw 'gamma' is not applied) came from.

Quote

First, let's look at the two cameras that behaved as expected. The first of those is the Nikon D4.A few missing codes in the red and blue channels, which could well be due to ADC defects, or also digital gain applied to the red and blue channels. I'm thinking it's digital gain, because the noise appears to be higher in the red and blue, and I can't think of a reason why that would happen.

Iliah Borg calls this WB preconditioning (watch the spelling ;-) Is the measured standard deviation after you take into account zero blocking proportional to the size of the gaps?

Quote

The Sony RX-1 shows an interesting result:...I'm at a loss here.

I also have no idea as to the dramatic difference in the population of the green and blue channels. It's unlikely that you selected say 2 amp/ADC combos for G1 and B and 4 amp/ADC combos for G2 and R, right? Is it a coincidence that the missing/existing codes alternate between G1 and B?

Quote

Next up, the Sony NEX-7:Wow! We're seeing steps of about 16 LSBs between occupied buckets, but it's not exactly 16 LSBs, and it's not just as if the lower four bits have been lopped off.

They are all the exact same codes, even though unevenly spaced. If they were evenly spaced every sixteenth, say, could we say that Unity Gain was around ISO 400? Sensorgen says that the NEX7 at ISO 6400 has FWC of 505 e- which would suggest a Unity Gain of around ISO 800. Could the unevenness yet consistency of the codes indicate some kind of digital post processing?

Quote

Finally, the Nikon D800E:This is interesting, because, although the channels are mostly looking like they'd been digitized with a 12-bit ADC, there are many places where adjacent 14-bit codes are occupied, indicating that the comblike nature of the histogram is not the result of any planned processing.

Maybe this is an invalid test because dark noise may be patterned, but I think there's something worth exploring here. The results for he M9 and D4 indicate that some cameras respond to this test in a way that you'd expect them to.

Yes, the tiny adjacent codes are intriguing. One thing I may suggest if you haven't done so already is to explore the masked pixels for clues (check the relative box in RawDigger preferences to see them in files that it can handle). As for dark noise, perhaps using a shorter shutter speed for the Nikons would help. I read somewhere that Nikon subtracts data collected in the dark sensels to compensate for this before writing data to the Raw file. Nikon supposedly also compensates for banding (don't know how) - could the tiny adjacent data be a leftover from those operations?

Quote

I'm not sure where to go from here, but I'm going to pursue this. It could have serious implications for what Unity Gain ISO should mean to photographers using the D800E and the two Sonys.

Jim

What about for the D4 and the M9? Weren't you surprised that there were no systematic gaps proportional to gain beyond Unity Gain there? For instance, according to sensorgen, there are 9 times as many linear Raw values as electrons in the D4 at ISO 6400, suggesting a unity gain of around ISO 700. Where are the gaps?

And absent the gaps or with gaps that have nothing to do with it, what is the usefulness of Unity Gain?

Making the column 1000 pixels high shows no periodicity in the histogram. I think that a definitive answer will need some more sophisticated analysis than histograms. Does anyone know a good way to turn raw files into 4 monochromatic TIFFs, preferably in batches? I'm not excited about using DCRAW. ImagesPlus?

Jim

Jim,

Iris is a freeware astronomical program that can do the job. The split_cfa command separates the CFA into blue, red, and green1 and green2. It is a quite sophisticated program with a graphical interface. The list of commands is here. Many of these commands (including split_cfa) must be accessed from a command line rather than the graphical interface. I have not figured out how to use a batch mode, but it does have simple macro programing feature that takes parameters. The native file format is FIT (favored by astronomers), but it can save as TIFF.

ImagesPlus does have batch modes. It splits the CFA into three monochrome images, with the green channels combined (the green image is twice as large in the vertical dimension than horizontal. It costs $200, but does have a demo that you can try out.

Iris is a freeware astronomical program that can do the job...ImagesPlus does have batch modes. It splits the CFA into three monochrome images, with the green channels combined...

Thanks for the tip, Bill. I looked at the date of the last update on the Iris site and decided to buy a copy of ImagesPlus. When the selling price is in the low hundreds of dollars, the real cost of using a program like this is the time spent learning it. Actually, now that I think about it, that's true of Matlab, too, even though it costs a lot more.

What about for the D4 and the M9? Weren't you surprised that there were no systematic gaps proportional to gain beyond Unity Gain there? For instance, according to sensorgen, there are 9 times as many linear Raw values as electrons in the D4 at ISO 6400, suggesting a unity gain of around ISO 700. Where are the gaps?

Jack, there aren't any photon-created electrons in the test image; the inside of the camera was as near to a photon-free zone as I could make it. I think we're just looking at electrical noise, exacerbated by turning up the gain with the ISO control. You could consider the signal to be zero, and that bucket is so full that I had to cut it off the histogram so that you could see the other buckets. I could have used the log scale for the y axis, but sometimes that's confusing to people.

So, I'm not surprised. I'll be working on some images today with real photons, and not very many of them. Maybe we'll see gaps in the D4, but I'm betting the M9 noise will prevent that.

Also, I don't think we need to have SNRs greater than one in the deep shadows (a necessary condition for gaps) for Unity Gain ISO to make sense. But let's wait on that until I figure out what's going on with the D800E and the two Sonys.

Was back at the OP, struggling to understand the basic principle of the Method.

Still doing that, but while Googling, found this link which was highly relevant to high ISO and particularly the answer by jrista addressed the subject of unity gain very well and is quite relevant to this discussion. IMHO.

I think that a definitive answer will need some more sophisticated analysis than histograms. Does anyone know a good way to turn raw files into 4 monochromatic TIFFs, preferably in batches? I'm not excited about using DCRAW. ImagesPlus?

Hi Jim, and others,

There are several software packages that can be of use, but one could use a combination of DCRaw to produce a non-demosaiced output file, and use ImageJ to do some image calculations (also allows to subtract image pairs).

DCRaw -D -4 -T filename

should produce non-demosaiced, linear gamma, 16-bit TIFF output without the 'masked-pixels'. Replacing '-D' with '-E' should include those masked pixels.

In ImageJ, that tiff file can be split into 4 separate channel files with a simple Macro (see attachment), which is to be placed in the \ImageJ\plugins\Macros subdirectory. I've adapted the macro I found on the ImageJ discussion list. I had to insert a short wait() time-out to avoid some images not getting shifted before getting resampled. Maybe it's caused by a parallel processing task getting out of sync.

One needs to verify that the channels are correctly named for a specific camera/Raw format/DCRaw conversion combination. The macro can be easily adjusted with a text editor. Different Raw formats may use a different order of the R/G1/B/G2 sensel filters, and different amounts of masked pixels can surround the effective image area. The attached macro seems to produce the same output pixel values as RawDigger does for my camera.

The benefit of using ImageJ is that the macro can be extended with all sorts of useful operations. One can e.g. subtract the 2 Green channels of an image of a diffusely lit smooth surface (after first adding an offset to the first image) as a means to eliminate pattern noise when only one image is available instead of an exposure pair specifically recorded for that purpose.

There are several software packages that can be of use, but one could use a combination of DCRaw to produce a non-demosaiced output file, and use ImageJ to do some image calculations (also allows to subtract image pairs).

Thanks, Bart, but I think I'm going to use Matlab for the image processing once I get the raw image planes. Not that it will be better than a specialized image processing program, but it's a program that I know (reasonably) well. I can't create those incredibly dense APL-like constructions, so real Matlab experts probably would look down on me, but the trade-off is that anyone with C++/Java experience can make sense of my code.

I looked at DCRAW, and went to a couple of the websites that offered compiled code, and was put off by the extra stuff that seemed to some with it. I don't want to buy a C compiler, and I'm -- probably unjustifiably so -- scared of using a free compiler that I don't know for sure is without side effects.

And absent the gaps or with gaps that have nothing to do with it, what is the usefulness of Unity Gain?

Jack, no matter what you think about the dithering effect of noise in the system, we do agree on one thing: there's a point at which you don't improve the SNR by turning up the ISO knob. If you think that noise dithering swamps out the theoretical gain in SNR of Unity Gain ISO, then you think that point comes sooner (at a lower ISO) than you do if you buy the whole Unity Gain ISO worldview. But either way, you stop twisting the knob.

Right?

By the way, if SNR is all that you're measuring, here's a D4 test that indicates that, five stops under clipping, that, once you subtract out the effect of varying photon noise, there's no much change in SNR from ISO 100 through 6400. I now think that SNR, because of its insensitivity to quantizing depth in the presence of significant photon noise, is not the best tool for looking at noise, so take these curves with several grains of salt. I have some ideas for getting at the visual effects of the way noise and bit-depth interact, but I'm not ready to post anything on that yet.