Re: Color space conversions seems to change PCS as well

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


On 10/23/20 6:17 AM, JonnyRobbie via gimp-developer-list wrote:
When first opened, the image is in Built-in sRGB and the top row is pure rgb, that is 255,0,0; 0,255,0; 0,0,255. And when running my small gegl operation, I get this stdout in CIExyY color space:

Input pixels  x=0.653898, y=0.321709, Y=0.222488

The xyY values that GIMP *does* produce - and GEGL/babl from the command line *should* produce - for sRGB "reddest red" are these:

x=0.648438 y=0.330867 Y=0.222488

So something seems wrong either in your code or in how GEGL/babl handles your input, even before you make the conversion from sRGB to ProPhotoRGB.

Which seems roughly correct (though not exactly comforming to the sRGB standard, which should be 0.64, 0.33, 0.2126 for the Red - that is also weird).

In GIMP the sRGB color space (with its D65 illuminant) has been Bradford-adapted to D50 to produce the sRGB ICC profile, which is why there is a small difference between the sRGB color space values and the sRGB ICC profile values.

As an aside, if/when babl/GEGL/GIMP ever extends ICC profile support to include iccMAX (which allows illuminants other than D50s), and/or provides support for OCIO color management in addition to ICC profile color management, then babl/GEGL/GIMP will have the ability to also work using D65 sRGB values. But these future possibilities aren't relevant to the results you are currently getting.

Then I convert the image to ProPhoto RGB (for example) color space. Now the "pure" sRGB colors are no longer represented as pure values - but that is to be expected - that is how color spaces work. So far so good.
The problem comes when I try to peep at the xyY values using my operation:

Input pixels  x=0.576892, y=0.363497, Y=0.144828
Input pixels  x=0.356573, y=0.513024, Y=0.668290
Input pixels  x=0.175974, y=0.085000, Y=0.083105

Those seem to differ as well, which is wrong as CIExyY color space is a profile connection space and the values there should be objective values not burdened by any device profile/working space.

Yes, as you note the xyY values should be the same before and after a color space conversion between well-behaved RGB matrix working spaces, assuming the source/destination illuminants match, which in current GIMP/GEGL/babl code should always be the case.

I was able to use GIMP to approximate your above results by following these steps:

  1. For an sRGB image, fill with sRGB's reddest red.
  2. Convert the image to ProPhotoRGB.
3. *Assign* the built-in sRGB color space to the newly-converted image, which changes the color from bright red to middle dullish orange.

After following these steps, here are the resulting xyY values from sampling the image color using GIMP color picker tool (the eye-dropper in the toolbox, not the eye-dropper in the FG/BG tool):

x=0.553973, y=0.386853, Y=0.189302

which values are close to what you are getting - for comparison, here are your values again:

Input pixels  x=0.576892, y=0.363497, Y=0.144828

So it looks like maybe, possibly:

* There is some error - either in your code or in GEGL/babl code or maybe both, or possibly even in the particular ICC profiles you might be using - that's producing somewhat wrong xyY values in the first place.

* Then there is some other error that's inserting an "assign" where there should be a "convert".

(Rendering intents seem to have no significant change)

Yes, in the case you are describing and b/where ecause GIMP nominally uses V4 ICC profile management (babl has taken over some of the ICC profile conversion tasks), using different rendering intents should make no difference at all to the results because:

* Both the source and destination profiles are (should be) well-behaved ICC RGB matrix working spaces, hence only using relative colorimetric intent regardless of any specified intent.

* The source and destination profiles have matching D50 white points and 0,0,0 black points, so using or not using black point compensation should make no difference at all.

So if changing the rendering intent does make even a small difference, that suggests yet another problem, possibly in the GEGL/babl code, possibly even with one of the ICC profiles involved in the color space conversion.

In case it might be relevant, which version of babl/GEGL/GIMP are you using, on which operating system? Also, which sRGB and ProPhotoRGB ICC profiles are you using - who was the profile provider?

Best regards,
gimp-developer-list mailing list
List address:    gimp-developer-list@xxxxxxxxx
List membership:
List archives:

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux