... if you translate 12-bit linear data to 8-bit 2.2-gamma-adjusted data, the linear values are very sparse relative to the gamma-adjusted ones, in the deepest shadows ... (grey column is 8-bit, white column is scaled to 4095 linear values):
I’m glad to see that the math (table) is now correct and corresponds to mine;
according to:
RGB_8bit_gamma-encoded = 255 x (RGB_12bit-linear / 4095)^(1/2.2)
Purpose was to illustrate that a 8-bit-gamma-encoded scale even can hold the deepest shadows of an 12-bit-linear scale. As a tradeoff, there are less levels dedicated to the highlights where it’s visually less important. It’s simply a skillful distribution, making the best of limited resources – under consideration of human vision (though gamma-encoding was never meant to comply to human vision; it was invented to compensate for the non-linear input/output relationship of CRTs).
If you’re really picky, you would now have to consider that sRGB does not represent a regular 2.2 gamma. The TRC tags in fact hold a curve which starts significantly less steep, then goes up to a ‘simplified gamma’ of 2.2 (the latter is what the custom profile function in PS indicates). The equation in detail can be found somewhere at Bruce Lindbloom’s and/or Gernot Hoffmann’s website.
Anyway, this will almost solve the problem which you now see with the ‘sparse’ linear scale.
... You can easily get at least 2, maybe 3 stops more DR from the 8-bit, if the source of data can provide it.
Breaking up the DR into zones is not the most useful way of looking at things, IMO. It is an easy way for people who are not good with math to repeat what they read, though.
Nope. It’s just the other way round.
A contrast ratio is a quite poor tool to describe DR. Because minor changes of the denominator drastically change the ratio. For example let’s take two monitors with different black points of 0.25 and 0.5 cd/m2. In one case you get 85 cd/m2 : 0.25 cd/m2 = 340 : 1. In the other case the result is 170 : 1. The same image on both monitors won’t look as different as the ratios seem to suggest. White luminance is much more important than such fluctuations around the black point.
Coming back to the input DR of cameras, Norman Koren’s procedure and table are completely valid: Calculate through the zones, do it right, and decide if you have enough levels per zone for a meaningful description with regard to perception. The Weber-Fechner law is a reasonable starting point, though it’s not valid in the shadows (there are less levels needed).
A 12 bit A-to-D converter is good for about 9 zones.
8-bit-gamma-encoded data can hold this barely.
However, output DR with monitors & prints is the limiting factor anyway.
How can my saying that 8-bit gamma-adjusted data can convey more DR than RAW can, be interpretted as "RAW arrogance"?
Peter wrote: “Face it, camera engineers know what they do (mostly).”.
John wrote: “Yes, they know that the camera will still sell if its JPEGs are not good representations of the sensor capture.”
Anyway, the whole question is not, if Raw is better. We’ve gone though this: it is, in terms of ultimate image quality. The challenge is to understand why JPG captures can be to some extend surprisingly reasonable, less worse than maybe expected. Or, what are the core strengths of Raw, and which JPG issues can be easily overcome with a little bit Photoshop wizardry…
And in this context, it might not be wrong to risk a look at different opinions:
/> Tom Niemann on his
rich website (‘So for my purposes I shoot sRGB JPEGs’).
/> Ken Rockwell’s
polarizing point of view.
/> Noel Carboni, whom former RG-members will certainly
remember.
/> Ron Bigelow, after writing a three-parts
article on his understanding of the Raw advantage, finally comes out with an example which I my eyes could rather be suited to show the opposite (see the purple flower).
/> Canon seems to be extremely proud on their Digic II processor and
picture styles.
/> And finally – he may apologize to be listed here - Michael Reichmann liked to review the
Powershot S3 Pro IS though it does not offer Raw recording.
Peter
--
