Those conversion factors are attempting to get a D65 Y from D65 RGB. So, we currently do a conversion like this, using unadapted values: D65 Y = 0.212656 * D65 Red + 0.715158 * D65 Green + 0.072186 * D65 Blue And you want us to do this, using the adapted values: Y = 0.222491 * D65 Red + 0.716888 * D65 Green + 0.060621 * D65 Blue Isn't the second (adapted) transform going to give us a D50 Y instead of a D65 Y? On Sat, Sep 21, 2013 at 8:21 PM, Elle Stone <l.elle.stone@xxxxxxxxx> wrote: > On 9/21/13, Michael Henning <drawoc@xxxxxxxxxxxxxxxxxx> wrote: >> Both babl's RGB format and Y format are currently defined with a white >> point of D65. Because of this, I believe the code's current luminance >> values are correct. >> > > The whitepoint of an ICC profile might have a D65 white point without > a chad tag, if it's a V2 profile. Or it might have a D50 white point > with a chad (chromatic adaptation) tag if it's a V4 profile. Either > way, the XYZ values are the adapted values, NOT the unadapted values. > In other words "D65" as the white point for the V2 profiles doesn't > mean "use the unadapted primaries", which means the unadapted "Y" > values are wrong. So are the unadapted X and Z values. > >> Out of curiosity, how did you determine the Y values from the code in >> gegl/operations/external/lcms-from-profile.c ? > > I put in a couple additional lines of code in the gegl file telling > lcms to save the profile to disk. Then I recompiled gegl, retrieved > the profile, and used iccToXml to examine the primaries. It's a bog > standard sRGB V4 lcms-generated profile. If you would like to look at > it, it's attached to this email. > > > If you're somehow >> dumping the icc profile and analyzing it, then it would make sense >> that those are relative to D50 because icc mandates D50. >> > > That's kinda the point. If a person opens an sRGB image file with > Gimp, that image's profile has the adapted primaries, not the > unadapted primaries. > >> In other words, I think that the whitepoints are all currently >> correct, because the constants in code are for converting between two >> color spaces with D65, and the icc profile is relative to D50. >> > > But that means the code is assuming a very odd color space, not the > same sRGB as is used by the vast majority of all the sRGB images ever > created. This includes all images to which Gimp assigns the built-in > sRGB profile created by lcms. V2 or V4, lcms1 or lcms2, the sRGB > primaries are the adapted primaries, which means the adapted R,G, and > B "Y" values. > > So how can it be right that the babl/gegl/gimp code uses unadapted > primaries for image processing, while operating on images that are > created using the adapted primaries? If you assign an sRGB profile > with unadapted primaries to an sRGB image that was created with a > proper sRGB image, that image will have a false blue color cast. And > if you use the unadapted Y values for Luminance desaturating in a > linear gamma color space, the resulting image will be slightly wrong. > >> (As a side note, I believe some of the grayscale conversions are >> currently very broken for other reasons. They operate in a gamma >> space, but use constants that are meant for linear color spaces. > > It's true that Luminance conversions to black and white in a nonlinear > color space makes much more wrong results than merely using the > unadapted Y values. But the Y values for the Luminance desaturate > code, for example, are still wrong. They should be the adapted values. > > Elle _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
