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

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.


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.


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