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. Though HSL, HSV and babl's naive CMY(K) are not relevant here since these are non-absolute color spaces. Also, I am not quite sure about seeing it as sRGB centric: 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. In other words, we could easily say the same thing replacing "linear sRGB" by "XYZ" or even "CIELab". 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. All that to say that technically babl is not stuck with sRGB chromaticities, 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. 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
