GIMP dirsegards assigned color profile with GEGL Operation Tool
GNU Image Manipulation Program version 2.10.22 git-describe: GIMP_2_10_20-217-g0c8a7891
Note: bug reporters are expected to have verified the bug still exists either in the last stable version of GIMP or on updated development code (master branch).
Operating System: Linux 5.9.1-arch1-1 x86_64 GNU/Linux
Package: arch repo
Description of the bug
When running a GEGL Operation tool, the gegl operation doesn't get the actual assigned color space, but a simple built-in sRGB.
Is the bug reproducible? Always
Build and load the attached gegl operation, which simply shows the CIExyY values of all the pixels in the image.
Open the attached sample 3x3 image.
Run GEGL Operation tool and select
The stdout of the first three pixels reads
Input pixels x=0.653898, y=0.321709, Y=0.222488 Input pixels x=0.323680, y=0.580968, Y=0.716904 Input pixels x=0.138084, y=0.056409, Y=0.060608
this roughly corresponds to the proper value.
Go to Image-Color Management-Convert to color profile and convert it to another color profile - in this example ProPhoto RGB.
Run the GEGL Operation tool with Print Pixels again.
The stdout to be virtually identical to the point 4). (barring some rounding errors)
the stdout reads:
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
Which is dramatically different to what it is supposed to be. It almost corresponds to the theory that the RGB values gets converted to ProPhotoRGB at step 5), but then the GEGL Operation wrongly interprets them as sRGB, which would corresponded to the observed result quite well.
You can also add a
babl_introspect(space); right at the beginning of the
static void prepare function and the last few lines of the stdout when selecting the pixel operation mentions sRGB even when the image is converted to ProPhoto RGB.
This bug completely blocks any serious use of GIMP with professional extended working spaces other then sRGB.