Gamma, sRGB, profile conversion and shaddow blocking -

[tomczak]

An intellectual puzzle:

The attached image is the extreme 4% shadows wedge (eleven wedges with values between 0 and 10, in 8bit). Try tagging this image with sRGB and AdobeRGB profiles - and maybe some others (but don't convert any data, just attach ICC profiles). My experience is that, depending on the monitor profile, some darkest wedges will be blocked, but AdobeRGB version is blocked much more than the sRGB version. This is important as many people use AdobeRGB as their working space.

My suspicion is that it has to do with the Gamma curve for AdobeRGB and some other spaces being expressed as a simple power funcion (y=x^2.2) while sRGB uses a piecewise equation where, the lowest 4% shadows segment of the the curve is linear and has a higher slope than a 'textbook' gamma would have, thus lightening this portion of shadows.

What I don't understand is what exactly happens gamma-wise, mathematically, when the image colour space, using one gamma equation, gets translated to the monitor colour space, using somewhat different one? Why the shadows appear lighter if the 'lighter' gamma curve is the one that image uses, not the one that the monitor does?

Also, if one insists on using AdobeRGB as a standard working space, is there an easy way to prevent such visual blocking (visual, because it's just the display issue - the data is still there)?

Cheers!

[Robert Schleif]

Isn't AdobeRGB incapable of distinguishing blacks below 4% in 8 bit, but in 16 bit, wouldn't the location of this "black cliff" be so much darker than full white that it would be irrelevant for most situations? Shouldn't the same be true for each color channel? In converting from 16 bit to 8 bit, I believe that the bottom 8 bits are just ignored, but if not, it would be interesting to know more about how this part of the conversion actually is performed. Some information related to the issue can be found at
http://gene.bio.jhu.edu/gamma_and_perception.pdf.
The general topic 8 bit and 16 bit profiles illustrates the fact that PWP is not strong in the HDR area, and I keep hoping that Jonathan will become interested in HDR and then remedy this situation.

[tomczak]

Thanks Robert!

While I have similar understanding of sRGB vs. power function gamma as described in your article, I still don't quite understand the phenomenon.

- using 48 bits, 32bit video card and 16bit LUTs, still causes on-screen banding. The visually same shadow ramp image will extend from (0 0 0) to (2570 2570 2570) in 48 bit, and causes the same on-screen effect, even though now there is enough empty levels between patches for them to fall into when transformed. I'm not sure where the bottleneck 'sinking' extreme shadows is. It looks like it's the profile conversion, but I don't understand why.

- I imagined that since sRGB uses a steeper, linear 'gamma' for the deep shadow values in this range, using sRGB as a monitor profile would lighten up the ramp coded as AdobeRGB, but it doesn't. My understanding was that on-the-fly ICC conversion from the image colour space to the monitor colour space will have to use the gamma as defined by the target i.e. monitor profile, and thus lighten the the shadows when going from AdobeRGB to sRGB - it does the opposite.

The easiest way to see it is to open two versions of the ramp image, tag one with sRGB and the other with AdobeRGB (you may have to Copy the image and close the original to open the same file as as second image), and then keep switching the monitor profile and see what it does to the images. Another way is to use Change Colour Profile and convert from AdobeRGB to sRGB, which should simulate what the monitor profile does if set to sRGB, then compare the patches using Readout tool. AdobeRGB-->sRGB conversion darkens the patches.

[tomczak]

I just want to add that what made me interested in the issue was printing on Durst Lambda printer: images edited in AdobeRGB and then converted to the printer colour space had deep shadows visibly blocked when printed, while those converted from sRGB fared much better.

Can that be explained?

[jsachs]

When changing color spaces, were you just retagging the image or were you converting the data as well? What you are describing I would expect from retagging.

[tomczak]

I converted the data as well. The test image above is useful to demonstrate it: if it is opened then initially tagged with AdobeRGB, and then converted (data and tag) to sRGB (I also tried Durst Lambda instead of sRGB as a target space), the patches darken significantly. Using 16bit prevents some numerical blocking, but not significant darkening, which in print looked blocked.

While I don't understand what really happens, and why steeper gamma for sRGB shaddows doesn't prevent it, I start suspecting that the rendering intend is at fault.

If I understand it correctly, both sRGB and AdobeRGB are matrix-based profiles (they only define primaries, WP and Gamma, not the LUTs for various intents?) and use the Relative Colorimetric intend while converting between them, ignoring the user-selection and clipping the colours that are outside the target space. If this is true, perhaps the deep shadows in AdobeRGB stick out of or are v. close to the edge of sRGB space and get clipped/darkened as a result? Why it should happen when converting to Printer space, which is almost certainly Table based, I don't know.

I found a decent blurb on it:

http://www.earthboundlight.com/phototip ... ptual.html

[jsachs]

It sounds like the printer may be ignoring the profile?

[tomczak]

Could be, but even doing the conversions of the test image purely in PWP (e.g. AdobeRGB-->sRGB or AdobeRGB-->DurstLamda), the test image lightest patch (10 10 10) becomes something like (2 2 2), measured by Readout tool, and the rest correspondingly lower - no wonder they blocked on print. 16bit doesn't help because ultimately 8bit image is send to the printer, and these deep shadows will still wind up with too low values to be distinguished in print. If I don't convert the working space to the printer space myself, the lab will have to do that before printing and they probably do the same as I do, except I don't get to see it.

The problem was practical, as I couldn't get deep shadows to print when editing the image in AdobeRGB, no matter what I did, and the image depended on them. From perspective, I should have used sRGB as a working space or use curves just before the conversion to the printer space to boost deep shadows so that they fell into sufficiently high values for the printer to print them as distinct shades.

The mechanism of it remains a mystery to me still.

p.s. I would have probably noticed it sooner if I checked and highlighted the black or near-black areas (e.g. off-label, careful use of High Contrast or Mask/Colour Range). I still think that a universal clipping/near-clipping warning system that's easy to use (e.g. in Preview or in any window) would be quite useful: http://www.dl-c.com/board/viewtopic.php?f=4&t=449

[jsachs]

It makes sense to me that a value of 10 in AdobeRGB might convert to 2 in sRGB given the differences in their gamma curves. 10 in AdobeRGB is much darker than 10 in sRGB due to the linear section of at the beginning of the sRGB gamma curve. However, I would expect each of these to convert to roughly the same value when converted to the printer profile.