[Gimp-developer] Histograms in unbounded mode sRGB



A long while back the topic came up on IRC about how to deal with histograms when an image has been converted from a wider gamut color space to unbounded mode sRGB. I tried to come up with a possible solution and failed.

I do have some sample data. You can download a test image from here:
http://ninedegreesbelow.com/gimpgit/gimp-srgb/color-blocks-in-regular-srgb.xcf

The test image is a series of six color blocks in each of five different color spaces, all converted to the unbounded mode regular sRGB color space at 32-bit floating point. The color blocks are labelled so you can tell which set of blocks is which.

The image has the most saturated possible red, green, yellow, blue, and magenta colors for the sRGB, Adobe RGB (1998), Rec. 2020, WideGamutRGB, and ProPhotoRGB color spaces.

These most saturated colors represent more or less outer boundaries of the possible range of colors found in LDR images.

There are more intense real greens and cyans than are included in the color blocks. ProPhotoRGB's greenest green and bluest blue are actually imaginary rather than real colors.

To provide an idea of the range of RGB values after converting to unbounded mode sRGB:

In the unbounded mode regular sRGB color space:

ProPhotoRGB cyan is -13.37 in the red channel.
WideGamutRGB magenta is -3.77 in the green channel.
ProPhotoRGB yellow is -2.09 in the blue channel.

ProPhotoRGB red is +1.36 in the red channel.
WideGamutRGB green is +1.12 in the green channel.
WideGamutRGB blue is +1.09 in the blue channel.

In the unbounded mode linear gamma sRGB color space:

ProPhotoRGB red is +2.03 in the red channel.
WideGamutRGB green is +1.29 in the green channel.
WideGamutRGB blue is +1.16 in the blue channel.


If a user opens, for example, a ProPhotoRGB image, I think it is unrealistic to expect that the user will understand what values like -13.37 and + 1.36 mean in the image histogram (or what these values mean in the Color Picker or Color Selector).

I think the only reasonable solution is to keep the WideGamutRGB chromaticities available for use as an editing/compositing color space, and use that color space to display histogram information (and also to display Color Picker and Color Selector information).

Dynamically normalizing the information to "just fit" all the RGB values between 0.0 and 1.0 in the histogram display means that, for example:

Before any editing is done, the histogram range will have a maximum value of 1.0.

If the user adds saturation, some RGB values will increase, and the normalized range will dynamically expand to still have a maximum value of 1.0.

And if the user lowers saturation in an image, some RGB values will decrease and the range of RGB values will dynamically contract to still have a maximum value of 1.0.

Thus the "information" aspect of the histogram would be severely comprised. In fact normalizing the histogram RGB values would make the histogram useless. It would convey shape and relative intensity as expressed in the unbounded sRGB color space (very different from the corresponding information in the source color space) with no indication of absolute intensity of color.

So it seems logical and also much more user-friendly to always construct the image histogram information in a compositing/editing color space based on the source color space chromaticities.

Similar considerations would apply to histograms that are displayed in the Levels and Curves dialogs.

Elle




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]