> 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. 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. Regards, Téo _______________________________________________ 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
