Re: Color space conversions seems to change PCS as well

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


> So if changing the rendering intent does make even a small difference

I tested that again and there's no difference at all between perceptual and relative colorimetric.
But I tried converting with saturation and absolute colorimetric and gimp stdouts that those conversions seem to be not implemented.

gimp_color_transform_new: error making dest format: ProPhoto RGB: absolute stauration not supported


gimp_color_transform_new: error making dest format: ProPhoto RGB: absolute colormetric not implemented

> In case it might be relevant, which version of babl/GEGL/GIMP are you 
$ gimp -v
GNU Image Manipulation Program version 2.10.22
git-describe: GIMP_2_10_20-217-g0c8a7891f7

gegl 0.4.26 (commit 3371550915bfe10e9e0add87caaf578464305542)
babl 0.1.82 (commit aab30293930236fab173a879f2d9aab95d45db5e)

All from the standard arch/extra repo.

$ uname -roms
Linux 5.9.1-arch1-1 x86_64 GNU/Linux

> Also, which sRGB and ProPhotoRGB ICC profiles are you using - who was the profile provider?

For ProPhotoRGB, it's the colord package from arch with freedesktop as upstream. For sRGB, it's the GIMP built-in

Now, you are right that there's one inconsistency, gimp color picker's xyY is not the same as to what is being pushed to the operation. I've got the same color picker result as you have.

I also reached out on the get issues for gimp and it might have been a known issue:

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