[Gimp-developer] Histograms in unbounded mode sRGB

[Elle Stone <ellestone ninedegreesbelow com>]

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