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

HSL, HSV are defined relative to the RGB color space the image
to be in, which I think is what you mean by "non-absolute" color

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
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.

Exactly, babl only knows about absolute color spaces so far, and non-absolute ones are hard-wired using sRGB, 
which is wrong.

About the general topic, the point would be that babl's RGB format should have arbitrary chromaticities 
instead of fixed ones? Not sure about implications of that... Operations should be then able to request some 
data about the color space given, like coordinates of primaries, and use them instead of the traditional 
[0.0,1.0]³. Operations should still be able to know absolute values, and to request either a perceptual or a 
linear light color space with those chromaticities. If I am not completely off, how this should be done is 
unclear to me. Also, I am under the impression that it conflicts slightly with the "each operation ask for 
the color space it needs" idea.



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