Blocked shadows when dumbing down an image for the Web

[Charles2]

Blocked shadows when dumbing down an image for the Web

Looking for a procedure to dumb down an image for display on the Web.This is a situation of too much quality.
- The monitor is wide gamut, able to display nearly al AdobeRGB. Display of a 32-step grayscale image shows them all distinctly.
- I set the PWP working space to SMPTE-240M.

The setup works well for prints. The problem is making an sRGB file for the Web.

Change Color Profile tends to block shadows against the left edge of the histogram. The display on lesser monitors is ugly in the blocked shadows.

This happens regardless of the option chosen for rendering intent. The option in Change Color Profile to Preserve Identical Colors and Black Point Compensation is typical. Here's an example of before and after histograms:



A discernible rise through the shadows becomes a blocked crush against the left edge of the histogram. (The blown highlights represent sky that does not matter for this particular shot.)

Is there a way to convert shots that pose this problem?

[den]

...Perhaps one could could Extract the HSV-H and HSV-S channels of the sRGB image version and Combine them with the Extract-ed HSV-V channel of the SMPTE-240M image version...

[jsachs]

When you change the color profile, are you changing both profile and data or just the profile?

[Charles2]

When you change the color profile, are you changing both profile and data or just the profile?

Both, per the default of Change Color Profile.

[jsachs]

When you change both, the image appearance should not change on-screen much. Are you seeing a big visual difference on-screen when you change profiles and transform the image data?

[Charles2]

Are you seeing a big visual difference on-screen when you change profiles and transform the image data?

On the wide gamut monitor, not much (viewing the Adobe RGB image with the monitor set to display the Adobe color space and viewing the sRGB image with the monitor set to display the sRGB color space). The difference is on another monitor, IPS panel but not wide gamut.

[jsachs]

The shift you see in the histogram is caused by SMPTE-240M being a gamma 1.8 and sRGB being a gamma 2.2 color space and is normal. Maybe the brightness or contrast settings of the other monitor are causing the problem.

[tomczak]

Even when converting from some other gamma 2.2 colour space to sRGB, the deepest shadows may get blocked, owning to the linear section of sRGB gamma for the first ~4% of brightness (up to about pixel value of 10, in 8bit files).

http://www.dl-c.com/board/viewtopic.php ... srgb#p2591

I think that the last Jonathan's comment in the above thread made me understand what happens: when converting between colour profiles, the colour engines try to match the apparent brightness that a colour space will eventually render when applying its built-in gamma curve to an input pixel value: sRGB linear gamma section amplifies the deepest shadows more that a standard 2.2 gamma of other spaces would, so those shadows become compressed when converted to sRGB (since they will be brightened by the sRGB linear gamma section and, theoretically, look the same when displayed, as in the original colour space that doesn't amplify the input pixel values so much) and the values may get clipped as a result of the conversion.

Converting in 16bit or changing rendering intents won't help much, I think

One practical solution to it is to stretch shadows before converting to sRGB.

[tomczak]

I'm not 100% sure, but I thought that SMPTE 240M had also some custom, piece-wise gamma function in it, with a linear section at the beginning of it (albeit shorter and flatter than the linear section in sRGB), but both of them are effectively more similar to the gamma 2.2 than 1.8? Is that true?

Since the gammas are different shape, especially at the shadows where sRGB amplifies the input more than SMPTE, converting from SMPTE 240M to sRGB may cause the same effects as described above, I think.

Cheers!

[Charles2]

Thank you, Jonathan. I think you are correct that the other monitor had skewed brightness or contrast settings, like many computers hooked up to the Web. Hence the title of this thread.

It was a shock to read that the SMPTE-240M profile is built at a gamma of 1.8. True, for careful readers the white paper on Color Management implies that the SMPTE-240M gamma is that of a typical printing press. However, the paper also equates this color space with AdobeRGB -- which according to Adobe has a gamma of 2.2. http://www.adobe.com/digitalimag/pdfs/p ... lspace.pdf

Adobe argues that the working space should always have a gamma of 2.2.

The solution was therefore to download the AdobeRGB profile from the Adobe website and make it the working color space for PWP in place of SMPTE-240M. Per your statement about the effect of gammas, Change Color Profile from AdobeRGB to sRGB shifts the histogram much less toward the shadow end. Problem solved.