Adventures in Wide Space
Posted: May 19th, 2009, 10:14 am
I have found and It has often been reported on various forums that recent Nikon DSLRs set to sRGB tend to blow the red channel on the camera histogram when photographing red or yellow flowers or fall foliage using what is otherwise a normal exposure — say a sunny/16 exposure in appropriate lighting conditions. Reducing in-camera exposure to the point where the red channel backs off the wall results in an overall dark image.
Part of the reds problem is gamut clipping where the camera is capturing a wider range of reds than fits into sRGB. If the image is shot in raw and rendered into a wide space such as Pro Photo, the red channel retreats considerably and is no longer clipped.
Some time back, this led me to explore wide gamut spaces. My understanding is that Light Room uses Pro Photo as its default space. Quite a few luminaries on the Internet say they edit in ProPhoto. So ProPhoto is a candidate for working with gamut problems. Pro Photo is a very wide space and most everyone that uses it does so with 16-bit representation. However, monitors are mostly 8-bit and even the ones that internally are more than 8-bit may not be using a full 8-bit data path from the PC to the screen display. Most printers are 8-bit. So for most of us, our Pro Photo ends up in 8-bit and being displayed/printed in a space much smaller than ProPhoto.
The concern I have had is that when a ProPhoto image is converted down to 8-bits and a much smaller space, either to a monitor or to a printer, the 8-bit boundaries are still in the same place as when the image was in 16-bit and the intermediate values are lost. The most common colors are scrunched into the center of ProPhoto, so the 8-bit boundaries do not yield a fine granularity for most of the colors in my images. The distance between the colors is known as delta-E in color science.
To test the hypothesis, I ran an experiment with the following Mountain Ash image which was shot with sunny/16 and has a red channel that climbs the wall in sRGB but falls well back in ProPhoto and in Chrome 2000 D65.
The experiment:
Render the raw image into ProPhoto, convert it to jpeg at 100%. Run the Count Colors function with the PWP Color Space set to ProPhoto. The result was 417,081 distinct colors.
Then render the same raw image into sRGB, convert it to jpeg at 100%. Run the Count Colors function with the PWP Color Space set to sRGB. The result was 1,064,715 distinct colors or over twice as many distinct colors by rendering the image through sRGB as running it through ProPhoto.
My explanation for the reduced color count is that most of the colors in the image are within sRGB. Rendering the image into ProPhoto compresses most of the colors to the center of the wide space. ProPhoto is not only wide, but a considerable amount of the coding space is used up representing non-existing colors. So an 8-bit representation only picks out most of the colors in the image at a rather wide spacing.
For this and other reasons, I use Chrome 2000 D65 when I want to work with gamut clipping.
Some color loss in both scenarios will occur due to converting to jpeg and tiff should show more colors, but I think the conclusion would be the same. I used jpeg because PWP does not count colors in a tiff due to (I assume) memory constraints.
I wonder if anyone has run a similar experiment using a program that will count distinct colors in a tiff and what the results were or if they have a different explanation for the color discrepancy.
Jim
Part of the reds problem is gamut clipping where the camera is capturing a wider range of reds than fits into sRGB. If the image is shot in raw and rendered into a wide space such as Pro Photo, the red channel retreats considerably and is no longer clipped.
Some time back, this led me to explore wide gamut spaces. My understanding is that Light Room uses Pro Photo as its default space. Quite a few luminaries on the Internet say they edit in ProPhoto. So ProPhoto is a candidate for working with gamut problems. Pro Photo is a very wide space and most everyone that uses it does so with 16-bit representation. However, monitors are mostly 8-bit and even the ones that internally are more than 8-bit may not be using a full 8-bit data path from the PC to the screen display. Most printers are 8-bit. So for most of us, our Pro Photo ends up in 8-bit and being displayed/printed in a space much smaller than ProPhoto.
The concern I have had is that when a ProPhoto image is converted down to 8-bits and a much smaller space, either to a monitor or to a printer, the 8-bit boundaries are still in the same place as when the image was in 16-bit and the intermediate values are lost. The most common colors are scrunched into the center of ProPhoto, so the 8-bit boundaries do not yield a fine granularity for most of the colors in my images. The distance between the colors is known as delta-E in color science.
To test the hypothesis, I ran an experiment with the following Mountain Ash image which was shot with sunny/16 and has a red channel that climbs the wall in sRGB but falls well back in ProPhoto and in Chrome 2000 D65.
The experiment:
Render the raw image into ProPhoto, convert it to jpeg at 100%. Run the Count Colors function with the PWP Color Space set to ProPhoto. The result was 417,081 distinct colors.
Then render the same raw image into sRGB, convert it to jpeg at 100%. Run the Count Colors function with the PWP Color Space set to sRGB. The result was 1,064,715 distinct colors or over twice as many distinct colors by rendering the image through sRGB as running it through ProPhoto.
My explanation for the reduced color count is that most of the colors in the image are within sRGB. Rendering the image into ProPhoto compresses most of the colors to the center of the wide space. ProPhoto is not only wide, but a considerable amount of the coding space is used up representing non-existing colors. So an 8-bit representation only picks out most of the colors in the image at a rather wide spacing.
For this and other reasons, I use Chrome 2000 D65 when I want to work with gamut clipping.
Some color loss in both scenarios will occur due to converting to jpeg and tiff should show more colors, but I think the conclusion would be the same. I used jpeg because PWP does not count colors in a tiff due to (I assume) memory constraints.
I wonder if anyone has run a similar experiment using a program that will count distinct colors in a tiff and what the results were or if they have a different explanation for the color discrepancy.
Jim