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
_______________________________________________
gimp-developer-list mailing list
List address: gimp-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list