Re: [Gimp-developer] Color space conversions seems to change PCS as well

[Elle Stone <ellestone ninedegreesbelow com>]

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,
Elle