Re: [Gimp-developer] Histograms in unbounded mode sRGB

[Elle Stone <ellestone ninedegreesbelow com>]

On 04/22/2014 02:25 PM, yahvuu wrote:
> Hi,
>
> Am 18.04.2014 22:10, schrieb Elle Stone:
> > 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).
>
> please allow me to make the case for using the color space of the respective
> export file format for histogram displays.
>
> You recently gave striking examples of how working with RGB _numbers_ can quickly
> become unwieldy from a user point of view. This probably applies as soon as the
> limitations of the traditional 8-bit sRGB processing are relaxed. There is
> nothing wrong with RGB color models, it is just that the numbers can become
> difficult to interpret for human beings.
>
> So, as a thought experiment, i'd like to get rid of any kind of RGB triples in the
> UI. To see where it hurts the most. This will be the places where RGB numbers are
> really needed. After all, GIMP is about colors, not numbers.
>
> Say, we get an adobeRGB camera image and the task is some touch-up and warping.
> The deliverables are 1) a JPG for the web and 2) a proPhotoRGB file for that mega
> stock company.
>
> I find that most of the editing can be performed without looking at a single RGB
> triple. Image transforms do not expose RGB numbers, neither do most of the filters.
> Even many of the tools in the Colors menu do not refer to RGB numbers. Of course,
> this is different for levels/curves. But by large, these tools are used on the 'value'
> channel, not on the distinct R,G,B channels. Here, working on the luminance channel
> instead would probably be an improvement.
>
> I find it is only on *export* when the RGB numbers become really important. Much like
> output-specific scaling and sharpening, each of the deliverables needs specific
> color treatment.
>
> Here, the histograms need to show the R,G,B channels of the specific output color
> space to allow assessment and correction of the conversion. Probably, this is also
> where the curves/levels tools should be working in the output color space. For
> example, how else could someone boost the midtones without adding clipping -- when
> maximum and minimum range of the curve do not refer to the actual range of the
> output file format? (not even talking of non-matching color primaries here)
>
> These color modifications that are specific to the output files are hot candidates for
> being stored in export pipelines, again analogous to scaling and sharpening operations.
>
> I'm less sure in how far this is an analogy to CMYK export -- is an equivalent to
> the 'press projection' needed here? Or is it sufficient to set the RGB color space
> of histogram/curves etc. to the currently active softproofing color space?
>
>
> best regards,
> yahvuu

You make excellent points about the need for better soft proofing tools, 
including access to channel information, histograms, and sample point 
data in the output color space.

On the one hand, I think you are right to assume that many people likely 
never look at sample points, histograms, channel data, and RGB values 
while editing. So for this group of people the colors they see on the 
screen is all that matters.

On the other hand, many people edit "by the numbers". Perhaps not as 
many people edit by the numbers as by sight only. But surely a large 
percentage of the high end users who are in the GIMP target audience do 
edit by the numbers as well as visually.

I use sample points, histograms, channel data, and the color picker and 
color selector constantly while editing, for example:

* To make sure I don't drive channel data out of gamut of the color 
space that I wish I were editing in.
* To calculate what color blending layer I might want to use to correct 
a color balance problem or to change the color balance in a particular way.
* To verify that a spot that should be neutral, really is neutral, and 
to correct the RGB invidual channel intensities if it isn't neutral.
* To see how much headroom an image might have.
* To check the "zones" distribution (it's awfully easy to get carried 
away adding contrast to an image).
* As a check on inadvertently introduced hue changes.

Seeing RGB values like 1.6 or -0.02 makes it literally impossible to use 
sample points, histograms, channel information and the color picker and 
color selector in the usual "by the numbers" type of fashion, because I 
don't intuitively know things like:

* What are the equivalent RGB values make reddest red for the color 
space that I really want to work in?
* How far negative can the blue or green channel go before it's out of 
gamut with respect to the color space that I really want to work in?
* How far positive can the red or green channel go before it's out of 
gamut with respect to the color space that I really want to work in?

When working in one's color space of choice, these crucial bits of 
numberical information are taken for granted, leaving only the other 
crucial problem of softproofing to the eventual output space.

But after a forced conversion to unbounded mode sRGB, everything is 
unfamiliar, unintuitive, unobvious. This isn't a case where one can 
expect the user to "learn how to deal with unbounded mode sRGB values" 
because that's simply not going to happen.

So yes, I agree with you 100% that better soft proofing tools are so 
very much needed. But people who edit by the numbers rather than just 
visually also need access to the real RGB values and the real histogram 
and the real channel data in the color space that they wish they were 
actually were editing in. The unbounded mode sRGB histogram, RGB values 
and channel data just won't help with the task of editing images that 
originate in wider gamut color spaces.

Best regards,
Elle