Luminous Landscape Forum
Equipment & Techniques => Digital Cameras & Shooting Techniques => Topic started by: Guillermo Luijk on December 13, 2007, 07:48:34 pm
-
In the same way I did a subjective test to check how much DR is usable in the Nikon D3 (Nikon D3 Dynamic Range Test: 9 f-stops (http://luminous-landscape.com/forum/index.php?showtopic=21507)), and Sony A700 (Sony A700 Dynamic Range test: 9.5 f-stops (http://luminous-landscape.com/forum/index.php?showtopic=21581)), I repeat it here for the Canon 40D. My final verdict is: 9 f-stops of usable DR.
The same processing and criteria applied as in the other tests (see Nikon's link).
This was the high DR scene:
(http://img263.imageshack.us/img263/5464/oscuravw4.jpg)
A bit brighter to distinguish what's going on:
(http://img100.imageshack.us/img100/5691/claramj4.jpg)
And the noise tests on the 7th, 8th, 9th and 10th f-stop areas, marked respectively as -6EV, -7EV, -8EV and -9EV:
(http://img263.imageshack.us/img263/9062/zonasvb4.jpg)
-
Guillermo,
what about posting the raw file? One should be able to reproduce what you have done (for the Sony A700 as well).
-
Guillermo,
what about posting the raw file? One should be able to reproduce what you have done (for the Sony A700 as well).
[a href=\"index.php?act=findpost&pid=160523\"][{POST_SNAPBACK}][/a]
ok ok I will ask (think they are not mine, and are the houses of people I even don't know)
-
Guillermo, have you tried playing with my DR test target & method and comparing the results with your tests so far?
-
With all the tests that you have posted, you have used different images. If you are comparing different cameras, don't you think you should be using some sort of standard image so that you are actually testing the response of the camera against a similar image. For example with the Sony, you used a window that had a curtain against it while with the Nikon D3, you used a window with a background lit by skylight, In the sony the curtain was underexposed by about 1/2 stop while the nikon was overexposed by at least 3.5 stops. In terms of comparisons this is not a particularly scientific test.
If you take a meter reading, preferably an incident meter in the various areas, What type of difference in light values are you getting?
-
Guillermo, have you tried playing with my DR test target & method and comparing the results with your tests so far?
[a href=\"index.php?act=findpost&pid=160535\"][{POST_SNAPBACK}][/a]
Not yet, anyway I don't have all those cameras so could do it just in my 350D. If I find time this weekend I will give it a try Jon.
-
With all the tests that you have posted, you have used different images. If you are comparing different cameras, don't you think you should be using some sort of standard image so that you are actually testing the response of the camera against a similar image. For example with the Sony, you used a window that had a curtain against it while with the Nikon D3, you used a window with a background lit by skylight, In the sony the curtain was underexposed by about 1/2 stop while the nikon was overexposed by at least 3.5 stops. In terms of comparisons this is not a particularly scientific test.
I completely agree, it would be desirable to use the same scene for all of them. Unfortunately for me it's impossible to have all those cameras gathered together. In fact I didn't shoot them, I just was sent the RAW files from different people.
My point is that this can be a good starting reference just to find out that there are really no huge differences in the practical DR you can expect to achieve with today's cameras. 2 years ago DR used to be around 8, now has improved to 9, so DR shouldn't be a critical decision parameter in a purchase (of course leaving aside the Fuji Super CCD, which is a completely different philosophy, and is very far from the others).
Regards.
-
Guillermo,
what about posting the raw file? One should be able to reproduce what you have done (for the Sony A700 as well).
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=160523\")
Hi Panopeeper (and anyone interested) I was allowed to offer both RAW files:
[a href=\"http://www.guillermoluijk.com/download/sonya700_drtest.arw]Sony A700 RAW file[/url]
Canon 40D RAW file (http://www.guillermoluijk.com/download/canon40d_drtest.cr2)
I am specially interested that you check the Sony A700. In my test I actually doubted between 9,5 or 10 f-stops of DR, and chose 9,5 to be more conservative. But now I have realised I did a mistake: the zones were incorrectly labelled and where I said -10EV it actually was -9EV. So the final subjetive DR was shifted. It should not be 9.5 but 8.5, or maybe 9 f-stops, being less conservative.
So the final conclusion is there is no clear winner among Nikon D3, Sony A700 and Canon 40D in terms of DR; it seems all last year cameras have raised DR from 8 to 9 f-stops, and DR at low ISO is not a critical choice parameter.
Regards.
-
Guillermo,
I checked out both images.
1. I find both unsuitable for this purpose; not only because of the low exposure (see the histograms), but because of the lack of clear, uniform surfaces in different tones, which are necessary to judge the noise. However, this is a non-issue anyway, as long as uncoordinated, casual shots will be used, which can not be compared. So, let's stay subjective.
2. I don't understand how you came to the results with the 40D. For example the top right corner of the TV is under the -10th stop.
3. I don't know the A700. I was looking at it in DNG format (I did not bother yet to implement the handling of its messy native raw file in my program). I find the low noise in the very deep shadows impressive; on the other hand, I see (relatively) considerable noise in not so dark areas. Unfortunately, there is no good basis for comparison with the 40D (equally uniform areas in equal tones).
[attachment=4257:attachment]
-
2. I don't understand how you came to the results with the 40D. For example the top right corner of the TV is under the -10th stop.
I think is for the RAW development criteria I chose, and for a particular problem with the 40D's RAW and DCRAW:
I applied white balance, and the criteria to do it was to develop the RAW file with <=1 multipliers, so no information is lost, with DCRAW's -H 2 option that guarantees neutral gray in the blown highlights. With this procedure a gap is always created in the highlights and I took the criteria to eliminate that gap (i.e. increase linear exposure of the resulting image to fit right part of the histogram).
I am not 100% happy with this criteria, but I think this approach is the closest to the way I would develop the RAW with the idea of not losing any information in mind.
What happened with the 40D file (and so as with the 30D file I have just analysed)? after the highlight clip there is still some more information in the non-WB image. DCRAW preserves it, probably it would be better not to do it, but I cannot take control of that part of the process since it's developement stage.
See these histograms:
NO WB APPLIED:
(http://img525.imageshack.us/img525/8803/img2191hisqv5.gif)
AFTER WB WITH -H 2 (highlight preservation and neutral gray blown areas):
(http://img339.imageshack.us/img339/3523/img2191hisxh9.gif) . (http://img337.imageshack.us/img337/585/magml6.jpg)
You can see the end part of the histogram provided by DCRAW is wrong, and a magenta cast was introduced in the highlights becuase DCRAW considered the highlights that needed to be white as that negligible information contained in the non-WB gap, while the real gross part of blown information was coming after. I am going to report about this white point to David Coffin; it already happened to him with other camera (Fuji or Oly I think).
I guess this is not DCRAW's fault, simply 40D's RAW files contain information after the white point, so it's a design problem in the RAW data produced by the 40D. But still it affects DCRAW and any other RAW developer. This is clear when looking at the linear non-WB histogram:
NO WB APPLIED LINEAR:
(http://img339.imageshack.us/img339/9726/img2191hisbn0.gif)
There are non-null data after the highlight blown peak.
Anyway, after getting that histogram, and knowing by certain that the shadows are correcltly aligned, and only the highlights were wrong, I simply shifted exposure linearly up again (as I would have done in a normal picture edition) to make the blown areas white instead of magenta. And surely that's why I got a zone distribution higher that yours. But I insist that it was the closest approach to what I would have done from a photographic point of view.
I agree with you there is too much mess to be too confident with the results.
Of course we could have done to a non-WB analysis, which is technologically correct, but I wanted a demosaiced-WB approach in these tests.
Another option would have been to develop with >=1 WB multipliers, leaving G channel fix, but again that produces the G channel not to have a proper value in the blown highlights and another even more niticeable magenta cast appears:
AFTER WB WITH -H 0 (>=1 multipliers):
(http://img171.imageshack.us/img171/4159/img2191hisxd3.gif) . (http://img171.imageshack.us/img171/9660/magaq8.jpg)
Are you doing all your measures with undemosaiced data? Did you see anything about this apparent highlight clip missalignment?
-
Guillermo,
I analyze the raw images with my own program. White balanced or not, it's only a click, and the program shows the pixel values and the std deviation of the original raw values as well as the transformed RGB values.
My program is not doing a true de-mosaicing, nor color space translation; it simply averages the same-colored pixels of a CFA (usually two greens, one red and one green), and uses those values for the mapping (in this mode all four pixels of a CFA have the same color). This method eliminates the possibility of non-displayable colors due to color space transformation.
There is an alternative mode: each pixel is either red, or green, or blue (i.e. the other components are 0), and that value gets mapped. I use the latter for example when judging the sharpness and resolution of a lens.
Anyway, I don't intend to use this occasion to "advertise" my program (it's free anyway, but the manual is outdated).
Back to "your" shot:
1. the saturation level of the 40D with ISO 100 is 13820. The histogram I posted is in the space 0-13900,
2. the useful masked pixel values are between 1010 and 1030 or so (there are many outlandish values). Let's work now with a fixed value of 1020.
So, the top possibe effective pixel value is about 12800 after discounting the black level. I made a selection on the top right corner of the TV screen (the images is displayed with +5 EV, in channel mode, i.e. not "color mixed"). The average of the reds is 1039, the greens 1049 and the blues is 1037. Discounting the "universal" black level, these are 19, 29 and 17.
12800 (0 EV) 6400 (-1 EV) 3200 (-2 EV) 1600 (-3 EV) 800 (-4 EV) 400 (-5 EV) 200 (-6 EV) 100 (-7 EV) 50 (-8 EV) 25 (-9 EV) 12 (-10 EV) 6
So, the red and blue pixels of the selected area are in the -9th EV, the greens are at the border between the -8th and the -9th. Of course, even slight changing of the selection changes these values; therefor, "standardized shots" are necessary to compare cameras.
The above assumes, of course, that halving the pixel value range corresponds to reducing the exposure by 1 EV. In a previous thread I disputed, that this has to be so, not that it is so. This can be verified with a step wedge, which I don't have.
-
All this info is really interesting, I am going to give your program a try (I already knew it was yours). So my -9EV calculation for the TV set was ot so wrong.
Regarding the non-zero values after the presumibly blown highlights peak, did you find them? I am restricted to what DCRAW shows me and here it was not good enough. There is a function in DCRAW's source (scale_colors()) wich scales all levels so that after having substracted the black offset they extend from 0..65535 in the demosaiced 16-bit data. It seems for some reason, in the 40D this scaling let the main peak of blown highlights with a value quite lower than 65535. Probably Coffin was using some scaling parameter that was wrong.
I wonder if you were able to see those ghost pixels beyond the blown highlights peak you can see in my non-WB histograms.
-
Regarding the non-zero values after the presumibly blown highlights peak, did you find them?
After the blowing there is nothing. Thie question is, what is interpreted as blowing. The histogram I posted does show a thin red and blue line at the very end, but it is barely visible. That is the clipping point; I guess this is at the same location as in your histogram (it has to be, does not it?).
I uploaded a layered TIFF showing the relevant area (the window) with some screen captures: http://www.panopeeper.com/Demo/Guillermo_4...t_analysis1.TIF (http://www.panopeeper.com/Demo/Guillermo_40D_DRtest_analysis1.TIF)
The first layer is in composite color view (averaged colors), showing only from 12000 to 14000. This yields very high contrast, but the colors are wrong, of course, because of the clipping. The clipped pixels are with 0 in the next layer, that shows, which pixels are affected by clipping. However, this is not exact because of the mixing of colors (a pixel appears black only if all three components clipped).
As you can see, *all* pixels of the upper part of the window are clipped, i.e. there is no detail to get there.
The third layer shows the same data but in channel view, i.e. each displayed pixel is either red or green or blue; the color is very bad, but this is much sharper than the composite color view.
The fourth layer is channel view but the clipped pixels are black. This shows exactly, where clipping occured.
The following four images are in exposure view. Every displayed pixel is either red or black, or green or black, or blue or black, depending on which pixel it is in the CFA, and if the pixel value is within the selected range (or outside the range, if chosen so). Note, that the intensity of the pixel is fix in this mode, it does not reflect the pixel value.
The first of these shows those pixels, which are outside of 13823 (the limiting value is always both inside AND outside). If your monitor has small pixels, then the colors melt together, but if you magnify it, you see the individual pixels in their own color (I did not want to multiply the number of layers by three to show each color on its own).
The next layer shows the pixels from 13824. See the pixel stats: the difference is not much, only a few pixels are with exactly 13823.
The next layer is with 13825. There are only red pixels there, i.e. 13824 was the clipping point for green and blue, but the red did not clip yet. However, the following layer shows, that there is nothing with 13826, i.e. the difference in the clipping points is only one level (there are other sensors with much larger differences).
I am going to give your program a try
You can download it from http://www.cryptobola.com/Photobola/Rawnalyze.htm (http://www.cryptobola.com/Photobola/Rawnalyze.htm)
I started implementing the native raw file support a few days ago, only DNG was supported before. The list of supported native raws is in Rawnalyze.htm (your camera is supported).
The manual is several months old, many features are not even mentioned. I will create a new one in one-two weeks.
-
Hi Panopeeper, sorry for messing you up with all these questions.
I have done what I should have from the beginning, analyze the undemosaiced RAW data (DCRAW's -D option), and now I see clear that all those considerations about the pixels after the blown highlights peak are due to some DCRAW's fault in the scaling process prior to demosacing.
In the pure RAW histogram (I still cannot distinguish R from G or B channels, but it's not necessary here) I can see the RAW file was perfect and found the same as you:
- A peak containing blown channels exactly in level 13825 and from there there is NOTHING up to 16383
- 3 pixels (I cannot say whether they are R, G or B ) in level 0
- An empty gap from 1 to 1002
- Main histogram starting at 1003
(http://img119.imageshack.us/img119/1307/dibube5.gif)
Just to show you what I was talking about, this is the demosaiced but non-WB (multipliers=1) linear histogram produced by DCRAW, Ymax=985 pixels:
(http://img143.imageshack.us/img143/2533/img2191hisyo1.gif)
White point is not properly shifted to match 65535, in fact after substracting the black level (DCRAW used 1024) it seems DCRAW scaled the channels so that the peak's relative position in the new 16-bit range remains the same. So there is demosaiced garbage after the blown highlights peak. And the same happens when we develop with WB producing the undesired magenta highlights.
I will definitively give a try to your PhotoBola (bola means ball in Spanish). BTW are you implementing one by one the decoding of the different vendor RAW formats? I ask this as I think DCRAW code is free to anyone wanting to use it, and Coffin focuses a lot to be able to decode any new format appearing in the market so it could save you work and keep your tool easily updated.
Thanks for your effort.
-
All this info is really interesting, I am going to give your program a try (I already knew it was yours). So my -9EV calculation for the TV set was ot so wrong.
Regarding the non-zero values after the presumibly blown highlights peak, did you find them? I am restricted to what DCRAW shows me and here it was not good enough. There is a function in DCRAW's source (scale_colors()) wich scales all levels so that after having substracted the black offset they extend from 0..65535 in the demosaiced 16-bit data. It seems for some reason, in the 40D this scaling let the main peak of blown highlights with a value quite lower than 65535. Probably Coffin was using some scaling parameter that was wrong.
I wonder if you were able to see those ghost pixels beyond the blown highlights peak you can see in my non-WB histograms.
[a href=\"index.php?act=findpost&pid=160948\"][{POST_SNAPBACK}][/a]
I gave up on DCRAW for extracting RAW data, until the program was given the -D (document) mode. Even then, it wasn't very useful as the data was mildly destroyed going into PS' stupid 15-bit+1 "16-bit" mode, since the data was only using the least significant bits of the 16-bit output to PSD or PGM.
-
Even then, it wasn't very useful as the data was mildly destroyed going into PS' stupid 15-bit+1 "16-bit" mode, since the data was only using the least significant bits of the 16-bit output to PSD or PGM.
I am very interested in this John, because I always wondered if the linear bit that we loose going into PS from a linear DCRAW TIFF is not lost in the same way when developing in ACR for instance. Does ACR perform the development and gamma correction in floating point before the final 15-bit rounding, or it applies a 16-bit linear rounding and then gamma?
The second option would be a bit stupid if you can afford the first at the same price, so I guess you get more precision from your RAW files developing them in a non-linear output developer such as ACR rather than in DCRAW (if the edition is tobe done on a gamma corrected image of course).
However I never noticed any kind of loss (posterization in the shadows and so forth) for putting DCRAW's linear files into PS. In fact when blending several different exposure shots into one HDR, the tonal richness in the shadows into PS is amazing even if starting from 16-bit linear.
-
I am very interested in this John, because I always wondered if the linear bit that we loose going into PS from a linear DCRAW TIFF is not lost in the same way when developing in ACR for instance. Does ACR perform the development and gamma correction in floating point before the final 15-bit rounding, or it applies a 16-bit linear rounding and then gamma?
I don't know how ACR works internally, except that it loads all 12-bit RAWs as at least 16(15)-bit, but using the LSBs of the 16(15).
-
I don't know how ACR works internally, except that it loads all 12-bit RAWs as at least 16(15)-bit, but using the LSBs of the 16(15).
[a href=\"index.php?act=findpost&pid=172322\"][{POST_SNAPBACK}][/a]
How do you know that it loads RAW files using LSB's?
-
How do you know that it loads RAW files using LSB's?
[a href=\"index.php?act=findpost&pid=172458\"][{POST_SNAPBACK}][/a]
Well, now that I think of it, what I am saying applies to DNGs and not necessarily to original RAWs.
If you make an uncompressed DNG from a 12 bit RAW, and put in lines of values that use up to the MSB of the 16-bit data, they will clip, of course, but their demosaicing influence can be seen in neighboring pixels. This means that the DNGs, at least, load with the 4 MSBs of 16-bit zeroed, normally, which means that the MSB of the original data is shifted 4 bits to the right, compared to the MSB of a true 16-bit DNG. The 12-bit RAW, therefore, is apparently discriminated against in terms of conversion precision.
I suspect that this is one reason that in ACR, and in other converters, people are seeing better results with 14-bit cameras, even though the extra 2 bits contain no significant signal.
-
If you make an uncompressed DNG from a 12 bit RAW, and put in lines of values that use up to the MSB of the 16-bit data, they will clip, of course, but their demosaicing influence can be seen in neighboring pixels. This means that the DNGs, at least, load with the 4 MSBs of 16-bit zeroed, normally, which means that the MSB of the original data is shifted 4 bits to the right, compared to the MSB of a true 16-bit DNG. The 12-bit RAW, therefore, is apparently discriminated against in terms of conversion precision.
I'm afraid you are attributing the DNG conversion characteristics, which are simply not there.
1. There is no difference in compressed vs. uncompressed DNG, except the method of storage.
2. 12bit raw data appears in the low-order 12 bits of the DNG data, and that is completely normal. The fact, that DNG keeps always either 8 or 12 bits means *nothing* relatnig to the quality of the stored data. You have to treat the stored pixel values as numbers without regard to the actual storage capacity (which 16 bits, except a few cases).
To properly interpret these numeric values, the WhiteLevel info has to be used. This is one of the numerous errors in the DNG specification: the sensor's bit depth is not apparent from the metadata, either WhiteLevel has to be rounded up, or the camera proprietory info needs to be used.
-
Well, now that I think of it, what I am saying applies to DNGs and not necessarily to original RAWs.
If you make an uncompressed DNG from a 12 bit RAW, and put in lines of values that use up to the MSB of the 16-bit data, they will clip, of course, but their demosaicing influence can be seen in neighboring pixels. This means that the DNGs, at least, load with the 4 MSBs of 16-bit zeroed, normally, which means that the MSB of the original data is shifted 4 bits to the right, compared to the MSB of a true 16-bit DNG. The 12-bit RAW, therefore, is apparently discriminated against in terms of conversion precision.
I suspect that this is one reason that in ACR, and in other converters, people are seeing better results with 14-bit cameras, even though the extra 2 bits contain no significant signal.
[a href=\"index.php?act=findpost&pid=172496\"][{POST_SNAPBACK}][/a]
I took a 12-bit raw file, developed it in ACR, written to tiff from CS3. I then took the tiff file into IRIS and generated a list of the levels in the green channel. At the lower levels it looks like this (first number is the level from the range 0-32767, second one is the number of pixels with that level):
109 0
110 0
111 0
112 494
113 0
114 0
115 0
116 0
117 0
118 0
119 0
120 0
121 0
122 0
123 0
124 0
125 0
126 0
127 0
128 420
129 0
130 0
and going to higher values
1000 0
1001 14407
1002 0
1003 0
1004 0
1005 15338
1006 0
1007 0
1008 0
1009 0
1010 16481
1011 0
1012 0
1013 0
1014 0
1015 17865
1016 0
1017 0
1018 0
1019 18862
and to still higher values
5000 0
5001 642
5002 642
5003 618
5004 602
5005 638
5006 0
5007 636
5008 594
5009 572
5010 663
5011 0
and to higher ones
10000 74
10001 155
10002 83
10003 155
10004 68
10005 81
10006 163
10007 78
10008 157
The large gaps at small 15+1 bit level are due to gamma correction from the 16-bit linear, demosaiced image data; the gaps get smaller at larger level until they disappear completely, and then in highlights two linear levels get squeezed into one output level by the gamma correction. If one does the same exercise with a 14-bit raw file, the output tiff will show the *same* gaps and highlight compressions.
Undoing the gamma correction, the inferred gaps in the raw data just prior to gamma correction are one part in 2^16 (this can be quite accurately assessed at the point in the raw data where the gaps disappear, at this point a change of one in the output level is equal to one unit of change in the input level just prior to gamma correction).
The conclusion? ACR is using the full 16 bits to calculate up to the point of gamma correction. If ACR were able to do a linear raw conversion, the file I analyzed would have no gaps in the 16-bit raw data. It's actually slightly better than that, since the output is a 16-bit signed integer, half the values go unused (the negative ones); the output is effectively 15-bit color depth, while the numbers before gamma correction have 16-bit depth. I presume the population of intermediate 16-bit tonal values is due to the interpolation of 12-bit values during the debayering step, which will fill in the missing values by taking averages over neighboring pixels. Operations on 12-bit tonal values that don't mix pixel data from multiple pixels will not accomplish that.
If ACR were doing calculations with less precision on 12-bit data, I would presume that the gaps in the tiff output would be larger (ie exhibit more combing). I don't see how these results fit with the proposal that ACR populates the LSB's to do its calculations, that would naively force the output to have bigger gaps between populated levels where both 12-bit and 14-bit files are mapped to the same tonal range 0-32K.
BTW, if one does this same exercise with C1 LE, or DPP, one finds no gaps at all in the tiff output. I interpret this to mean that these converters are doing their internal math in floating point rather than the 16-bit unsigned integer that ACR uses.
-
If ACR were doing calculations with less precision on 12-bit data, I would presume that the gaps in the tiff output would be larger (ie exhibit more combing). I don't see how these results fit with the proposal that ACR populates the LSB's to do its calculations, that would naively force the output to have bigger gaps between populated levels where both 12-bit and 14-bit files are mapped to the same tonal range 0-32K.
[a href=\"index.php?act=findpost&pid=172649\"][{POST_SNAPBACK}][/a]
What I did, precisely, was open an uncompressed DNG of a blackframe in a hex editor, and replace dashes of original pixels with contiguous lines of various values above 4095, from just above 4095 to up near 65K.
I then opened the DNG in ACR, and looked for these altered dashes, and they all clipped right within the pixels that I re-wrote, but playing with various parameters to emphasize the demosaicing effect in the surrounding pixels, I was able to see differences between the different dash intensities. That suggests that when a 12-bit RAW becomes a 16-bit DNG, ACR acknowledges those 4 MSBs, which should have all zeros, within its dynamic range.
I can't imagine why they would do this as a special case; that's why I thought that ACR gave precision to DNGs (at least), by aligning them on the LSB. Wouldn't it make more sense for ACR to shift 4 bits to the left, knowing that the highest value shouldn't be more than 4095? If they did do that, why would these 4 MSBs from the DNG still be there? There are no RAWs with more than 16 bits right now, and I find it hard to believe that adobe thought that far ahead, and dedicated the extra memory for greater-than-16-bit RAW.
-
I'm afraid you are attributing the DNG conversion characteristics, which are simply not there.
1. There is no difference in compressed vs. uncompressed DNG, except the method of storage.
Once again, we fail to communicate.
Nothing I said about the uncompressed DNG implied any difference other than compression/storage.
2. 12bit raw data appears in the low-order 12 bits of the DNG data, and that is completely normal. The fact, that DNG keeps always either 8 or 12 bits means *nothing* relatnig to the quality of the stored data. You have to treat the stored pixel values as numbers without regard to the actual storage capacity (which 16 bits, except a few cases).
It might be normal for DNG, but it is certainly not a good thing for the user. It might be advantageous to write a program that takes a DNG from a 12-bit source, and bit-shifts the 12 LSBs to the 12 MSBs, and multiplies the embedded whitepoint, and blackpoint, and any other levels-related value in the DNG by 16. This might also help aid in ACR's 1-dimensional (line or banding) noise reduction.
To properly interpret these numeric values, the WhiteLevel info has to be used. This is one of the numerous errors in the DNG specification: the sensor's bit depth is not apparent from the metadata, either WhiteLevel has to be rounded up, or the camera proprietory info needs to be used.
[a href=\"index.php?act=findpost&pid=172511\"][{POST_SNAPBACK}][/a]
Yes, but that doesn't tell us how much precision is used. The converter is still free to either scale the data before processing, or align in memory on the LSB.
-
What I did, precisely, was open an uncompressed DNG of a blackframe in a hex editor, and replace dashes of original pixels with contiguous lines of various values above 4095, from just above 4095 to up near 65K.
I then opened the DNG in ACR, and looked for these altered dashes, and they all clipped right within the pixels that I re-wrote, but playing with various parameters to emphasize the demosaicing effect in the surrounding pixels, I was able to see differences between the different dash intensities. That suggests that when a 12-bit RAW becomes a 16-bit DNG, ACR acknowledges those 4 MSBs, which should have all zeros, within its dynamic range.
I can't imagine why they would do this as a special case; that's why I thought that ACR gave precision to DNGs (at least), by aligning them on the LSB. Wouldn't it make more sense for ACR to shift 4 bits to the left, knowing that the highest value shouldn't be more than 4095? If they did do that, why would these 4 MSBs from the DNG still be there?
[a href=\"index.php?act=findpost&pid=172732\"][{POST_SNAPBACK}][/a]
Hmm. I'm having a tough time reconciling our two observations. On the one hand, as you say, if ACR shifts the 12-bit raw data to the MSB's internally in ACR, then it shouldn't know about your supra-white pixels' specific values. On the other hand, if it were mapping the data to the LSB's in ACR, then the spacing of gaps in the output file should be a part in 2^12 or 2^14 depending on the bit depth, rather than a part in 2^16 as observed.
-
It might be normal for DNG, but it is certainly not a good thing for the user. It might be advantageous to write a program that takes a DNG from a 12-bit source, and bit-shifts the 12 LSBs to the 12 MSBs, and multiplies the embedded whitepoint, and blackpoint, and any other levels-related value in the DNG by 16.
You are concentrating on bits; however, that's not how ACR is working. How many bits should be used for example of the 40D with ISO 100 or ISO 160?
Forget about bits and concentrate on pixel values on their own. The white level specifies the limit of pixel values for the processing. If you reduce the "exposure", i.e. the pixel values or change the WB, the contrast, etc. which leads to pixel value changes, such pixels, which have fallen outside the range will be "pulled back" into the range and thus processed.
Example: take a 40D shot with ISO 200, exposed to the right. ACR believes, that the level of clipping is 13600, and accordingly indicates lots of clipping. Reduce the exposure and the "clipped" pixels appear in their full glory.
-
If ACR were doing calculations with less precision on 12-bit data, I would presume that the gaps in the tiff output would be larger (ie exhibit more combing). I don't see how these results fit with the proposal that ACR populates the LSB's to do its calculations, that would naively force the output to have bigger gaps between populated levels where both 12-bit and 14-bit files are mapped to the same tonal range 0-32K.
BTW, if one does this same exercise with C1 LE, or DPP, one finds no gaps at all in the tiff output. I interpret this to mean that these converters are doing their internal math in floating point rather than the 16-bit unsigned integer that ACR uses.
Your last comment is very interesting.
I have developed a RAW file on ACR setting neutral parameters on all (except WB which I used 'as shoot' and colour space which had to be shosen some way (sRGB in this case). It is true that gaps appear, so I guess the maths on the demosaicing and development process are not done in floating point (otherwhise would be silly to round to 16+1 bit integer right before the final gamma correction...).
So if it is true that C1 and DPP fill all those gaps and it is due to the fact they work in floating point, is ACR much faster than C1 and DPP?
On the other side I am not an expert, but I think a very important part of the process is the colour profile conversion: when I develop images in DCRAW setting no output colour profile (-o 0 option) I can clearly distinguish Bayer interpolated from captured levels (seen as equally spaced strong peaks).
But when I develop with output conversion to sRGB the matrix operations over levels completely hide the peaks sequence.
Since the gamma value is deeply related to final colour space, I wonder if the filling of gaps in DPP and C1 is more related to some different process of the colour profiling rather than floating point vs integer operation.
Another point is the fact that having 16 (or 15+1)-bit integer data before gamma correction can be very convenient in terms of speed, since a gamma correction could be quickly implemented through a gamma[0..65535] precalculated integer array, much faster to apply than the: X^(1/2.2) power calculations.
I heard from Julia Borg (easily found in DPreview forums) that she had coded a completely floating point RAW developer (evolution from DCRAW I think) for getting the highest possible quality of data in a 100% floating point image workflow.
-
I suppose one scenario consistent with both our observations would be the following: ACR loads the RAW file into LSB's, consistent with John's observation, and then does the bayer interpolation. Then sets white and black points and rescales the data to span 2^16 levels (though filling only 2^12 or 2^14 of the possible values). If the conversion from camera color data to XYZ color space (or LAB, Prophoto, etc) is now performed, it will be done at 16-bit precision and since ACR does this via matrix multiplication, the resulting linear combinations of the three color channels will take on all 2^16 possible values, consistent with my observation. So some early calculations would be done at the bit depth of the camera, and later ones at 16-bit depth.
-
I took a 12-bit raw file, developed it in ACR, written to tiff from CS3. I then took the tiff file into IRIS and generated a list of the levels in the green channel. At the lower levels it looks like this (first number is the level from the range 0-32767, second one is the number of pixels with that level):
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=172649\")
Emil,
A very interesting post. BTW, Guillermo has a [a href=\"http://www.guillermoluijk.com/software/histogrammar/index.htm]Histogrammar Program[/url] that can show the gaps graphically at the lower end and how they fill in at the upper end of the range. It reads TIFFs directly.
Bill
-
I suppose one scenario consistent with both our observations would be the following: ACR loads the RAW file into LSB's, consistent with John's observation, and then does the bayer interpolation. Then sets white and black points and rescales the data to span 2^16 levels (though filling only 2^12 or 2^14 of the possible values). If the conversion from camera color data to XYZ color space (or LAB, Prophoto, etc) is now performed, it will be done at 16-bit precision and since ACR does this via matrix multiplication, the resulting linear combinations of the three color channels will take on all 2^16 possible values, consistent with my observation. So some early calculations would be done at the bit depth of the camera, and later ones at 16-bit depth.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=173746\")
Emil, I don't want to believe that the demosaicing and Bayer interpolation process is done in the native 12 or 14 bit range in ACR.
I cannot tell, but I can tell about how DCRAW works, which is not floating point but clearly is better than the 12-bit/14-bit approach:
1. DCRAW converts 12/14 bit samples into 16 bit (just a x4 or x2 integer multiplication).
2. Next it calculates black offset (when needed, some cameras don't have) and substract it
3. Next DCRAW is aware of the point at which every camera clips its RGB channels (Panopeeper can tell us a lot about this) and scales them so that the clip point on each channel reachs the maximun (65535). In the same operation (after all it's all about multiplications) it applies the white balance (individual multipliers on each channel)
All these steps are done in a very important function of DCRAW's code called scale_colors() (see below), which the only one I have looked at by the way.
4. Next comes the whole development process: Bayer demosaicing, highlight recovery if set, and colour profiling if set.
So unfortunately DCRAW is not floating point, but it is 16-bit all time.
This is a linear TIFF produced by DCRAW (BTW plotted used the program Billl refers to, find a tutorial here: [a href=\"http://www.guillermoluijk.com/tutorial/histogrammar/index_en.htm]HISTOGRAMMAR TUTORIAL[/url]):
1. THE RAW FILE
This is a real native RAW histogram, prior to demosaicing. All values are in the 0..4095 (i.e. 12-bit) range:
(http://img116.imageshack.us/img116/5449/bridgehisan0.gif)
We can see that not the whole 0..4095 range is actually used. This is because of a DC black offset value all cameras have (usually around 250 levels in my 350D). Some brands substract that value before saving the final RAW data,or simply don't produce it, no idea which is the true version.
2. THE DEMOSAICING PROCESS (RAW DEVELOPMENT)
For demosaicing previous values are scaled by a factor of 2^(16-12)=16 and an additional WB scaling. And from these scaled values, interpolated values (already in the 16-bit range) are calculated:
[span style=\'font-size:8pt;line-height:100%\'](NOTE: for simplicity this is the histogram of only the blue channel.[/span]
[span style=\'font-size:8pt;line-height:100%\']Two blue types were used to distinguish levels according to their origin)[/span]
(http://img340.imageshack.us/img340/5681/histo2ll8.gif)
3. GETTING INTO PHOTOSHOP
Our image is now on a real 16-bit range. Look now what happens to a real histogram when we load it into PS (ACR outputs the same effect), and save it back in 16-bit TIFF format:
[span style=\'font-size:7pt;line-height:100%\']Original[/span]
(http://www.guillermoluijk.com/tutorial/histogrammar/linearhis.gif)
[span style=\'font-size:7pt;line-height:100%\']After just Open and Save in PS[/span]
(http://www.guillermoluijk.com/tutorial/histogrammar/linearhisps.gif)
PS looses 1 bit of precision. The Original image produced by DCRAW is linear, that's why it has not gamma holes which will appear afterwards in PS, when converting to a non-linear colour space.
Regards.
PS: DCRAW's scale_colors() function:
void CLASS scale_colors()
{
unsigned bottom, right, row, col, x, y, c, sum[8];
int val, dblack;
double dsum[8], dmin, dmax;
float scale_mul[4];
if (user_mul[0])
memcpy (pre_mul, user_mul, sizeof pre_mul);
if (use_auto_wb || (use_camera_wb && cam_mul[0] == -1)) {
memset (dsum, 0, sizeof dsum);
bottom = MIN (greybox[1]+greybox[3], height);
right = MIN (greybox[0]+greybox[2], width);
for (row=greybox[1]; row < bottom; row += 8)
for (col=greybox[0]; col < right; col += 8) {
memset (sum, 0, sizeof sum);
for (y=row; y < row+8 && y < bottom; y++)
for (x=col; x < col+8 && x < right; x++)
FORC4 {
if (filters) {
c = FC(y,x);
val = BAYER(y,x);
} else
val = image[y*width+x][c];
if (val > maximum-25) goto skip_block;
if ((val -= black) < 0) val = 0;
sum[c] += val;
sum[c+4]++;
if (filters) break;
}
for (c=0; c < 8; c++) dsum[c] += sum[c];
skip_block:
continue;
}
FORC4 if (dsum[c]) pre_mul[c] = dsum[c+4] / dsum[c];
}
if (use_camera_wb && cam_mul[0] != -1) {
memset (sum, 0, sizeof sum);
for (row=0; row < 8; row++)
for (col=0; col < 8; col++) {
c = FC(row,col);
if ((val = white[row][col] - black) > 0)
sum[c] += val;
sum[c+4]++;
}
if (sum[0] && sum[1] && sum[2] && sum[3])
FORC4 pre_mul[c] = (float) sum[c+4] / sum[c];
else if (cam_mul[0] && cam_mul[2])
memcpy (pre_mul, cam_mul, sizeof pre_mul);
else
fprintf (stderr,_("%s: Cannot use camera white balance.\n"), ifname);
}
if (pre_mul[3] == 0) pre_mul[3] = colors < 4 ? pre_mul[1] : 1;
dblack = black;
if (threshold) wavelet_denoise();
maximum -= black;
for (dmin=DBL_MAX, dmax=c=0; c < 4; c++) {
if (dmin > pre_mul[c])
dmin = pre_mul[c];
if (dmax < pre_mul[c])
dmax = pre_mul[c];
}
if (!highlight) dmax = dmin;
FORC4 scale_mul[c] = (pre_mul[c] /= dmax) * 65535.0 / maximum;
if (verbose) {
fprintf (stderr,_("Scaling with black %d, multipliers"), dblack);
FORC4 fprintf (stderr, " %f", pre_mul[c]);
fputc ('\n', stderr);
}
for (row=0; row < iheight; row++)
for (col=0; col < iwidth; col++)
FORC4 {
val = image[row*iwidth+col][c];
if (!val) continue;
val -= black;
val *= scale_mul[c];
image[row*iwidth+col][c] = CLIP(val);
}
}
-
GLuijk, did you do a similar test with either the 5D or 1Ds series cameras?
Thanks.
-
GLuijk, did you do a similar test with either the 5D or 1Ds series cameras?
Thanks.
[a href=\"index.php?act=findpost&pid=174511\"][{POST_SNAPBACK}][/a]
Kind of with the 5D, but the image was not ideal for the test. However the 5D showed a bit less DR than the 40D, about 8.5 f-stops subjetively speaking.
-
I remember a dynamic range test that someone suggested in a thread on another forum a few years back. The test was to side light something with texture that was near white. (Terry cloth towel for example) Then starting at the camera exposure setting (meter attempting to make the white mid gray) bracket up and down is half stop steps until getting a file that was completely blown out and another with no info. Looking at this span of images in light room makes it relatively easy to count the number of images in the span from black to white. 16 images means 8 stops, etc.
This seems to be a more empirical approach than the one taken here which depends on several factors that may or may not be controllable.
David
I'm afraid you are attributing the DNG conversion characteristics, which are simply not there.
1. There is no difference in compressed vs. uncompressed DNG, except the method of storage.
2. 12bit raw data appears in the low-order 12 bits of the DNG data, and that is completely normal. The fact, that DNG keeps always either 8 or 12 bits means *nothing* relatnig to the quality of the stored data. You have to treat the stored pixel values as numbers without regard to the actual storage capacity (which 16 bits, except a few cases).
To properly interpret these numeric values, the WhiteLevel info has to be used. This is one of the numerous errors in the DNG specification: the sensor's bit depth is not apparent from the metadata, either WhiteLevel has to be rounded up, or the camera proprietory info needs to be used.
[a href=\"index.php?act=findpost&pid=172511\"][{POST_SNAPBACK}][/a]
-
starting at the camera exposure setting (meter attempting to make the white mid gray) bracket up and down is half stop steps until getting a file that was completely blown out and another with no info. Looking at this span of images in light room makes it relatively easy to count the number of images in the span from black to white. 16 images means 8 stops, etc.
I don't know what this has to do with DNG, but that's ok. However, the mentioned empirical method does noto work so clear-cut as you may think.
A smaller problem is, how much one can trust the camera to expose as expected with an acceptable tolerance. For example my Canon 20D can not be trusted.
The bigger problem is to determine the low end. What is "black" in a digital image? Pixel intensity zero? That does not work; pixel values close to zero are usually so noisy that they don't reveal anything but noise. In any selected area you can find pixels with very low and with higher (sometimes quite high) values.
Is "black" that, what appears close to black on the display? That depends on the raw processor and the respective adjustments.
Is "black" that, what can not be recognized as "intelligent" even with adjusting the intensity? The transition is floating.
Therefor some measurement of the acceptability is necessary. This can be for example the standard deviation between the pixels of a uniform area (ignoring the level of details). It can be based on the presence of fine details, like Jonathan suggests, quite ignoring the noise. Obviously there can be different measures, but "no info" is IMO not a useful category.
-
GLuijk, did you do a similar test with either the 5D or 1Ds series cameras?
Thanks.
[a href=\"index.php?act=findpost&pid=174511\"][{POST_SNAPBACK}][/a]
Thanks, was that with RAW or jpegs?
-
Thanks, was that with RAW or jpegs?
[a href=\"index.php?act=findpost&pid=174918\"][{POST_SNAPBACK}][/a]
I always use RAW. JPEG is a gamma corrected image, so it's difficult to use it to measure DR in the way I do my tests: I ask for a single shoot over a high dynamic range scene and study how noisy is the information found in each of the f-stos of the sensor's DR. To allocate the different regions of the image to the right f-stops would be tricky.
-
Thanks a lot for the info.
I am also wondering if you have conducted these tests on either the 1Ds3 or any of the MF backs?
Thanks!
-
Thanks a lot for the info.
I am also wondering if you have conducted these tests on either the 1Ds3 or any of the MF backs?
Thanks!
[a href=\"index.php?act=findpost&pid=175358\"][{POST_SNAPBACK}][/a]
No I haven't, sorry. Regarding the 1Ds3 I guess must be around 9 f-stops. To improve DR through a better sensor design is a slow process; improving one f-stop of DR means aprox. halving noise level in the shadows, so we won't see miracles in the market.
To really achieve better DR in DSLR cameras today you have to go to Fuji's Super CCD which is 'something more' than just a low noise sensor in the shadows since it captures in just one shot, 2 images of different exposure to improve DR. It easily reaches 11 f-stops of DR clearly beating all the Canons and Nikons. The 2 images of the Super CCD are 3.6EV apart so you can get an idea of the expansion in DR these cameras can provide with respect to a single-exposed image sensor.
-
No I haven't, sorry. Regarding the 1Ds3 I guess must be around 9 f-stops. To improve DR through a better sensor design is a slow process; improving one f-stop of DR means aprox. halving noise level in the shadows, so we won't see miracles in the market.
To really achieve better DR in DSLR cameras today you have to go to Fuji's Super CCD which is 'something more' than just a low noise sensor in the shadows since it captures in just one shot, 2 images of different exposure to improve DR. It easily reaches 11 f-stops of DR clearly beating all the Canons and Nikons. The 2 images of the Super CCD are 3.6EV apart so you can get an idea of the expansion in DR these cameras can provide with respect to a single-exposed image sensor.
[a href=\"index.php?act=findpost&pid=175376\"][{POST_SNAPBACK}][/a]
There's no free lunch there, though. What do you do with the photosite data that is very noisy when its less sensitive twin is clean? You discard it, that's what you do. You have to discard the clipped pixels, too. So, you've thrown away photons, and overall IQ, to get a peek at the extremes of DR.
There's nothing quite like having high quantum efficiency, and no read noise.
-
There's no free lunch there, though. What do you do with the photosite data that is very noisy when its less sensitive twin is clean? You discard it, that's what you do. You have to discard the clipped pixels, too. So, you've thrown away photons, and overall IQ, to get a peek at the extremes of DR.
There's nothing quite like having high quantum efficiency, and no read noise.
[a href=\"index.php?act=findpost&pid=175390\"][{POST_SNAPBACK}][/a]
But discarding these pixels doesn't result in a lower IQ for the collected information, but in less collected information, i.e. less final resolution in Mpx. That's the problem of the Super CCD, it needs 12Mphotosites to achieve what actually are just 6Mpx as the discarded info has to be interpolated.
The perfect camera does not exist, but shooting a Fuji knowing (almost) by certain your exposure will be fine even if you are not very careful, is something to think about. It's like a car with wheels which can never have a puncture. For some kind of photography is just great.
-
Guillermo,
an off-topic but important subject.
I guess you borrowed the Sony A700 from someone to make the DR test, right? That camera had firmware version 2 that time. I found a horrendeous issue with that (in that shot): at ISO 200 (and where else? I have only that image) it operates only with 3000 levels in 12bit mode. With firmware v3 it goes up to 3500 (still a crap).
-
Guillermo,
an off-topic but important subject.
I guess you borrowed the Sony A700 from someone to make the DR test, right? That camera had firmware version 2 that time. I found a horrendeous issue with that (in that shot): at ISO 200 (and where else? I have only that image) it operates only with 3000 levels in 12bit mode. With firmware v3 it goes up to 3500 (still a crap).
[a href=\"index.php?act=findpost&pid=176011\"][{POST_SNAPBACK}][/a]
I remember that we were discussing about the A700 RAW file having levels beyond 4095, but the histogram was plenty of holes. David Coffin told me such high end point in the histogram was due to 8-bit RAW decompression. They can go beyond 4095, but they will never produce more than 4095 different non-null values:
"Hi Guillermo, Now I see what's happening. It's in the sony_arw2_load_raw()function. The Sony DSLR-A700 supports two formats: packed with 12 bits per pixel, and compressed with 8 bits per pixel (a fixedcompression ratio achieved by sacrificing quality as needed). Decompressing the 8-bit data yields values from 0 to 8191. To maintain compatibility with the 12-bit packed mode, I doubled the latter. This allows the user to specify the same darkness and saturation values for both data formats." David Coffin explained."
My Canon 350D also reaches just 3000 levels in a deeply populated RAW histogram
-
Guillermo,
the above has nothing to do with what I referred to. In the meantime I found more shots from the firmware v1 and v2. Images with *all* ISOs have only 3000 levels, except 3200 and above, which have even less.
Then version 3 came, and Sony did not say a word, but things have changed; now there are 3500 levels. Still not stellar, but much better.
Tell the owner of the camera you used for the comparison that new firmware should be loaded. 3000 levels in a modern DSLR is a shame.
-
Btw, the 350D creates about 3850 levels. How did you arrive at 3000 levels?
-
Tell the owner of the camera you used for the comparison that new firmware should be loaded. 3000 levels in a modern DSLR is a shame.
[a href=\"index.php?act=findpost&pid=176062\"][{POST_SNAPBACK}][/a]
3000 unique levels is sufficient with the read noise levels at base ISO. Most 12-bit Canon DSLRs have barely more than 3000 in most (useful) ISOs.
In this particular case, of course, the issue may not be a scaling problem but a clipping problem, in which case the 3500 levels should be recommended.
-
3000 unique levels is sufficient with the read noise levels at base ISO
No, it is not enough. This is bound to posterisation.
Most 12-bit Canon DSLRs have barely more than 3000 in most (useful) ISOs
Maybe most of your Canon DSLRs. One of mines has 3970 levels, the other has over 15000. The very worse I know of is the 30D with only 3300 levels. The next one is the 5D with 3570; a far cry from 3000.
-
Btw, the 350D creates about 3850 levels. How did you arrive at 3000 levels?
My fault, the image under test was not fully exposed. I have taken a fully exposed ISO100 image (deep shadows to 3-channel blown highlights histogram), and got:
Filled levels:
R: 3844 (5,9% of available in 16 bits)
G: 3845 (5,9% of available in 16 bits)
B: 3845 (5,9% of available in 16 bits)
Dynamic range:
R: 3844, range [252..4095]
Don't pay attention to the RGB distinctions since my histogram program does not recognize yet the Bayer distribution, but the figures (~3850) match yours.
that's disappointing. Does it have a higher black level or simply doesn't reach 4095?
-
Are you telling me the 5D has less levels than the 350D? that's disappointing. Does it have a higher black level or simply doesn't reach 4095?
[a href=\"index.php?act=findpost&pid=176086\"][{POST_SNAPBACK}][/a]
Levels shmevels. The levels are wrong, anyway, because of noise.
Have I not clearly demonstrated that unless the number of levels drops so low that the read noise goes well below 1.4 of those levels, that the number of levels are irrelevant?
The 5D does not have state-of-the-art read noise levels at low ISOs. Not for Canon, anyway. The lowest read noise on the 5D is about 2.0 ADU; higher than the 40D (translated to 12 bits) and the 400D.
-
No, it is not enough. This is bound to posterisation.
That's only true if a RAW converter shortchanges low-level RAWs in precision. It is not the fault of the RAW data.
Maybe most of your Canon DSLRs. One of mines has 3970 levels, the other has over 15000. The very worse I know of is the 30D with only 3300 levels. The next one is the 5D with 3570; a far cry from 3000.
[a href=\"index.php?act=findpost&pid=176084\"][{POST_SNAPBACK}][/a]
A far cry? Log(3570/3000)/log(2) = 0.25 stops maximum, potential, of any difference (posterization difference in the deep shadows in the total absence of read noise). There is too much read noise in any Canon, even at base ISO, for this potential to be realized.
I have *NEVER* seen posterized RAW conversions, given enough calculation precision, from any camera, except slightly in the Pentax K10D in deep shadows at ISO 100.
You should really spend 10% of the time that you do grumbling about levels, looking at the destruction noise does to potential posterization. These are not 1982 raytraces we're looking at; we're looking at real captures dithered by noise. We need less noise; not more levels to more accurately record noise.
-
Are you telling me the 5D has less levels than the 350D? that's disappointing. Does it have a higher black level or simply doesn't reach 4095?
BL average 128, saturation: 3690
This low number of levels created the too good reputation of the 5D as a "low noise" camera. That's rubbish. The low noise is due to the lack of levels; there are only 12 levels for everything past the 8th EV, and this everything includes the useless noise as well.
DPR's DR analysis is based on the smoothness. I bet, with Jonathan's method, i.e. based on the analysis of retained details, the 5D would not look so good. The two methods should be used together.
-
BL average 128, saturation: 3690
This low number of levels created the too good reputation of the 5D as a "low noise" camera. That's rubbish. The low noise is due to the lack of levels; there are only 12 levels for everything past the 8th EV, and this everything includes the useless noise as well.
DPR's DR analysis is based on the smoothness. I bet, with Jonathan's method, i.e. based on the analysis of retained details, the 5D would not look so good. The two methods should be used together.
[a href=\"index.php?act=findpost&pid=176112\"][{POST_SNAPBACK}][/a]
I'm sure I mentioned this before, somewhere. Surely it's not just the number of levels in each pixel that counts, but the total number of pixels as well. The 5D has 50% more pixels than the 350D.
-
BL average 128, saturation: 3690
This low number of levels created the too good reputation of the 5D as a "low noise" camera. That's rubbish. The low noise is due to the lack of levels; there are only 12 levels for everything past the 8th EV, and this everything includes the useless noise as well.
OK I can see that in last DCRAW version, Dave prints now the black and also saturation points he uses to scale (5D RAW):
Scaling with darkness 128, saturation 3692, and multipliers 2.015625 1.000000 1.468750 1.000000
But I have to agree with John that in terms of EV dynamic range, the difference is not so notorious and we should look at other parameters such as noise.
After all, having HALF the levels just means losing the last f-stop of the DR.
You mean the low noise of the 5D is thanks to level aggregation?
-
After all, having HALF the levels just means losing the last f-stop of the DR.
[a href=\"index.php?act=findpost&pid=176155\"][{POST_SNAPBACK}][/a]
And that's only if there were no noise. Even in the absence of read noise, the DR can be limited by the maximum number of photons.
-
After all, having HALF the levels just means losing the last f-stop of the DR
What is "just" on this? Have not you noticed yet, that the advance in DR is in tenths of a stop?
Furthermore, the shadow range is not "grown up" yet. We need much more levels (but clean levels) to create better images. As of now, if you want to enhance for example the 9th stop, you have to work with 3-5 different levels; that's a joke.
You mean the low noise of the 5D is thanks to level aggregation?
I mean I wonder how the 5D's DR would look with Jonathans method.