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
_______________________________________________
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
