Re: [Gimp-developer] Attempt to summarize the discussion of my examples of what doesn't work in unbounded sRGB

[Elle Stone <ellestone ninedegreesbelow com>]

On 04/21/2014 06:05 AM, Elle Stone wrote:
> On 04/21/2014 04:47 AM, Teo Mazars wrote:
> > But... are you really saying that Gradient should be implemented using
> > a non-perceptual color space?
>
> Yes, to be technically correct.
>
> See http://ninedegreesbelow.com/gimpgit/gimp-srgb/gradients/gradients.png

Making the code draw gradients *in the unbounded mode sRGB color space* 
rather than the RGB color space of the artist's choice means:

1. A gradient drawn from sRGB red to sRGB green is drawn technically 
incorrectly but also looks the way many people are used to seeing the 
gradient look.

2. A gradient drawn from Rec. 2020 red to Rec. 2020 green is drawn 
technically incorrectly and also the result is something no one in their 
right mind would want the gradient to look like (barring corner case 
artistic intentions). This is because "perceptual" gradients just don't 
work in unbounded mode sRGB if the artist wants to use colors that are 
outside the sRGB color gamut.

More generally speaking, if all RGB editing operations *must* use the 
sRGB chromaticities, with no user choice, then most and probably *all* 
RGB operations should be done in linear light:

1. If the UI *does* give the user the choice to pick "perceptual", but 
the code insists on the sRGB *chromaticities*, then the "perceptual" 
choice is useful *only* to users who want to work exclusively in the 
sRGB color space.

2. A user who opens a wider gamut image won't be able to take advantage 
of the choice to use "perceptual". This is because for many RGB editing 
operations, if the image is converted to unbounded mode sRGB then 
results using "perceptual" are not just *technically* wrong, but also 
visually, obviously, horribly wrong and strange.


Elle