GNOME Bugzilla – Bug 788428
At 32f, linear precision, converting to the monitor profile produces wrong results
Last modified: 2018-05-24 18:29:32 UTC
In "Preferences/Color Management" select a monitor profile from disk, and make sure Color Management is enabled. Also make sure "Try to use the system monitor profile" is *not* checked. Open an sRGB image, make sure the GIMP built-in sRGB profile is assigned, change the precision to "32-bit floating point/linear precision", and convert the image to the monitor profile that was selected in Preferences. The resulting image looks like it was given an approximately gamma=2.2 "correction" somewhere in the conversion process - in other words, the sRGB TRC was somehow misapplied during the conversion. I tested this with two actual monitor profiles selected from disk, and also with an sRGB profile from disk selected as the monitor profile. If the precision is "32f/gamma precision", the conversion to the monitor profile is done correctly. I didn't check lower bit depths. I also didn't check what happens when "Try to use the system monitor profile" is checked in Preferences. When converting to a monitor profile that isn't the monitor profile selected in Preferences, there is no problem. The same problem obtains for images that aren't in the GIMP built-in sRGB color space. For example, open an image in the AdobeRGB1998 color space, change the precision to "32f/linear", and convert to the monitor profile selected in Preferences. Converting an image to the user-selected monitor profile is not a common thing for a user to do (well, except for users who are using an sRGB profile from disk as their monitor profile), but still it should be possible to do correctly, regardless of the image precision. This bug predates the new babl icc code, and happens regardless of whether the new babl icc code is enabled or is disabled using GIMP_COLOR_TRANSFORM_DISABLE_BABL=yes export GIMP_COLOR_TRANSFORM_DISABLE_BABL
Nothing quickly comes to mind. Does it still happen today?
Hmm, yes, it does still happen, but I'm 99% sure it only happens if the user has *disabled* using the new babl icc code, that is, using these options when starting GIMP: GIMP_COLOR_TRANSFORM_DISABLE_BABL=yes export GIMP_COLOR_TRANSFORM_DISABLE_BABL Even with LUT monitor profiles, if the "disable using the new babl icc code" options are not used, the conversion still happens. Oh, wait, above is for matrix monitor profiles. For LAB LUT monitor profiles, the problem still exists even if the babl icc code is enabled. The image looks like it's been given a gamma correction. Oh, and converting to an XYZ LUT monitor profile produces the right tonality, but completely the wrong colors, indicating that the "matrix" profile tag was used instead of the actual XYZ LUTs. Would it help if I attach sample XYZ and LAB LUT monitor profiles?
Yes please, that would help.
Created attachment 366148 [details] All six types of monitor profiles that can be made using ArgyllCMS/DisplayCAL The tar.gz file contains six profiles, one for each type of monitor profile that can be made using ArgyllCMS/DisplayCAL. All the profiles have the same file name, except for the last couple of letters. The matrix profiles only seem to cause a problem with the babl icc code is not being used. The LUT profiles cause a problem even when the babl icc code is being used. Matrix profiles: Three-channel gamma matrix: nec-20171223-g22-t5200-R255-G239-B250-qm-cal-qh-ag.icc Single-channel gamma matrix: nec-20171223-g22-t5200-R255-G239-B250-qm-cal-qh-aG.icc Three-channel shaper matrix: nec-20171223-g22-t5200-R255-G239-B250-qm-cal-qh-as.icc Single-channel shaper matrix: nec-20171223-g22-t5200-R255-G239-B250-qm-cal-qh-aS.icc LUT profiles: LAB LUT: nec-20171223-g22-t5200-R255-G239-B250-qm-cal-qh-al.icc XYZ LUT: nec-20171223-g22-t5200-R255-G239-B250-qm-cal-qh-ax.icc
The relevant difference between babl and lcms2 is that given a profile that babl decodes, babl generates a babl_format of the color space from the profile and with the TRC of the image linearity: https://git.gnome.org/browse/gimp/tree/libgimpcolor/gimpcolorprofile.c#n1480 Whereas lcms2 is asked to generate a transform to the color space with the TRC of the profile, regardless of the image linearity: https://git.gnome.org/browse/gimp/tree/libgimpcolor/gimpcolortransform.c#n242 When the final conversion to the display color space is executed in one case the projection babl_format is right, in the other it is not and there is a gamma correction in excess: https://git.gnome.org/browse/gimp/tree/app/display/gimpdisplayshell-render.c#n261 So when converting the image to a different color profile it is necessary to keep coherent the linearity of the image and the color profile adjusting one or the other.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1204.