Adventures in Wide Space

[JML]

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.

DSC_0001B 400 AdvSharp 2.jpg (45.92 KiB) Viewed 8807 times

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

[Bob Walker]

Jim,

I have never run such an experiment, but your logic sounds exactly right to me, for what it's worth.

Bob Walker

[jsachs]

This is exactly why I don't recommend using super-wide color spaces - most colors are compressed into a small area and there are not enough bits to avoid posterization which is exactly what you are seeing. Chrome 2000 was designed to just capture the entire gamut of slide film. Unfortunately I have not seen any information on actual camera gamuts which one would expect to vary from sensor to sensor. The ideal color space would be one that has the camera primaries and the color space primaries. This would mean no wasted bits and no clipping. If anyone has seen this information published I can create a profile easily from the information.

[kevgermany]

I prefer to take the digital image, compress the dynamic range in transform/brightness, convert to a different colour space (lets say sRGB for web use), check the histogram after conversion for clipping. If there's no clipping, I'll then adjust the image as needed. Often a full range adjustment is needed.

[jsachs]

The problem with using too small a gamut is saturation clipping, not brightness clipping.

[mjdl]

Re: jsachs' remarks about camera color space characterization: is it possible to use the color response matrices for individual camera models published by www.dxomark.com to derive the camera primaries? Just a wild stab in the dark--I *really* don't know what I'm talking about here!

[tomczak]

Norman Koren describes why knowing the ICC profile for a camera doesn't describe its gamut (last section):

http://www.gamutvision.com/docs/camera_scanner.html

I don't quite understand it still: what sensor response data are exactly required to create a sensor-fitting colour space?

[tomczak]

Here is an interesting experiment on creating an optimized (not necessarily for the camera sensor gamut) working colour space, using variety of colour targets.

http://www.brucelindbloom.com/index.htm ... lator.html

Also, interesting description of the anatomy of various colour spaces:

http://www.brucelindbloom.com/WorkingSpaceInfo.html

May be of use.

[alain]

Hi

I think that the "correct" way is to convert from prophoto to sRGB in 16-bit (tiff) and then convert to 8-bit (jpeg), the color loss should be far less.