GNOME.org
 

Re: [Gimp-developer] Some blend modes break in unbounded mode sRGB

On 04/13/2014 09:30 AM, Elle Stone wrote:

On 04/13/2014 07:54 AM, Teo Mazars wrote:

Hello,


In the strongly color-managed world of BABL and GEGL, the only *RGB*
color space/working is *s*RGB, either the linear gamma/light sRGB or
the
more perceptually uniform regular sRGB with its not quite gamma=2.2
TRC.

And then there is:

sRGB converted to CIELAB.
sRGB converted to HSL.
sRGB converted to HSV.
sRGB converted to CMY(K).
sRGB converted to Gray.
sRGB converted to YCbCr.
sRGB converted to some other model of color space, such as XYZ or
CIELUV, for which code might be written at some point in the future.

The key point is that the chromaticities of the *RGB* color space,
that
might be converted to some other *model* of color space, are *always*
the *s*RGB chromaticities.


I am not the expert but this is how I understand the thing too.
Thanks! Teo, it's nice to know that my understanding isn't completely off the wall. 



Though
HSL, HSV and babl's naive CMY(K) are not relevant here since these are
non-absolute color spaces.
HSL, HSV are defined relative to the RGB color space the image happens to be in, which I think is what you mean by "non-absolute" color spaces.
So if you use LCMS to convert from an RGB color space to HSL or HSV, then the resulting HSL/HSV values depend entirely on the source RGB color space. Changing the source color space changes the resulting HSL/HSV colors. I don't think there's any LCMS code for naive CMY where C=1-R, M=1-G, etc, but if there were, it also would produce different results depending on the source RGB color space.
However, if you use the BABL code to convert to HSL, HSV, etc, the resulting values are only correct if the image has the sRGB chromaticities. The same is true for converting to Gray, YCbCr, etc. 


Also, I am not quite sure about seeing it as sRGB centric:



In other words,
we could easily say the same thing replacing "linear sRGB" by "XYZ" or
even "CIELab".
As an important aside, CIELAB is an *adjunct* to RGB editing, a very important and useful adjunct, but not a wholesale replacement for *any* RGB operation. Any image editor that, for example, limits tonality changes to manipulating the CIELAB L* curve is crippled as an RGB image editor. 



The problem would be then that most GEGL operations ask
for either linear or regular "sRGB", and thus may expect the
chromaticities to be those of sRGB.
From what I've seen and based on testing, the BABL/GEGL/GIMP operations that depends on the regular sRGB almost gamma=2.2 *tone reproduction curve* -- apart from any dependence on the sRGB chromaticities -- will work perfectly with, for example data that has the ProPhotoRGB chromaticities and the sRGB tone reproduction curve ("TRC"). Those portions of the code are completely dependent on the sRGB TRC (or else the "gamma corrections" won't work correctly). But they are not dependent on the sRGB chromaticities.
The portions of the code that depend on the sRGB *chromaticities* have to do with calculating Luminance (converting to gray using Luminance, some of the noise reduction algorithms) and with converting from sRGB to other color spaces such as CIELAB, HSV, HSL. 


even though
conversions are done internally through linear sRGB, the fact that
this is an invertible linear transformation of the XYZ color space
makes it mathematically equivalent in terms of gamut.




All that to say that technically babl is not stuck with sRGB
chromaticities,
Technically BABL may not be stuck with sRGB chromaticities, but it uses them in an awful lot of code. 


but that some GEGL's operations expect them. Also, as
a side note and as far as I know, there is no gamut mapping algorithm
currently in babl nor GEGL.
Gamut mapping would be useful for soft proofing, but I'm not sure what the relevance is in the current context.
The problem with converting all images to use the sRGB chromaticities instead of the source color space chromaticities is as follows:
*Many editing operations work just fine regardless of the color space chromaticities. *Many other operations fail completely, and/or don't work as well, resulting in arbitrary color changes when the color space chromaticities are arbitrarily changed from the source color space to the sRGB color space.
It's the chromaticities change that causes problems, not the TRC. The TRC can be modified and gamma corrected. 

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