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 04:47 AM, Teo Mazars wrote:
> ----- Mail original -----

> > Similar issues are easy to demonstrate with Levels upper and lower
> > sliders, Gradients, Invert. These really need to be linear light
> > operations.
> >
> > Is there a list of the operations that don't currently use linear
> > light?
>
> Yes, grep for "R'" or "Y'" in the operation directory.

Thanks!

> 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


> I think gradient is a good simple example. How this operation should be implemented exactly?

We want people to be able to draw perceptually linear gradient right?

I completely agree with you that people should be able to draw a 
gradient in a perceptually uniform color space if they want to.

But any such gradient is not technically correct. Colors don't mix 
properly in the almost perceptually uniform regular sRGB color space.

So any color mixing in the regular sRGB color space is technically 
incorrect. For example, you get dark lines at the edges of soft brush 
strokes. The same thing happens with gradients, except the darkening 
artifact is spread out across the gradient and so doesn't look as 
obviously technically incorrect.

How do we achieve that, both from UI and GEGL point of view.

I have two proposed solutions:

Solution one:

*Drop* the insistence that all processing be done in a color space 
defined by the sRGB chromaticities and let people choose whatever RGB 
color space they want to work in.

Don't presume people are incapable of understanding and taking charge of 
their own color management decisions. Yes, many people will make 
mistakes. So what?

Also drop the whole "gamma-correction" business.

Code would be greatly simplified.

In this scenario you could choose to work in the regular sRGB if you 
want the technically incorrect gradients that everyone is used to. You 
could choose to work in a linear gamma version of sRGB if you want 
technically correct gradients. You could choose to work in linear gamma 
Rec 2020 or linear gamma ProPhoto or regular ProPhoto, etc.

The results you get would be technically correct or incorrect depending 
on whether you choose a linear gamma color space or not.

All RGB values would be represented in the user's chosen color space.

The UI wouldn't need to accomodate things like +1.6 or -0.2 just to 
represent a shade of red in some color space other than sRGB.

There wouldn't need to be any hacks to make histograms or color picker 
or color selector work.

Values greater than 1.0 would always mean intensity rather than "redder 
than sRGB red" or "greener than sRGB green".

There would be no RGB values less than 0 unless Subtract is unclipped 
and the user chose to use Subtract. The result would be under the user's 
control.


Solution two:

Keep the insistence on the sRGB-TRC and keep the code that "gamma" 
corrects the sRGB-TRC.

Better yet, change that "gamma" correction code to work with true 
gamma=2.2 (mathematically simpler code) or else to work with the truly 
perceptually uniform lstar TRC.

But *drop* the insistence on the sRGB chromaticities. Let the user 
choose their RGB working space but tell them it needs to have either the 
sRGB-TRC (or gamma=2.2 or lstar as appropriate to the code), and explain 
the consequences of the choice.

Make ALL "Gamma" precision operations happen using the perceptually 
uniform TRC (*nothing* is "gamma" corrected) and make ALL "Linear" 
precision operations happen using the linear gamma TRC (*everything* is 
"gamma" corrected).

The advantage is that:

All RGB values would be represented in the user's chosen color space.

The UI wouldn't need to accomodate things like +1.6 or -0.2 just to 
represent a shade of red in some color space other than sRGB.

There wouldn't need to be any hacks to make histograms or color picker 
or color selector work.

Values greater than 1.0 would always mean higher intensity rather than 
"redder than sRGB red" or "greener than sRGB green".

The user can easily switch from linear to perceptual processing and back 
again.


Elle