Yes. Or rather I mean XYZ LUT monitor profile with any embedded matrix, but only the swapped matrix makes the problem immediately obvious. I read through the ArgyllCMS colprof documentation on making “-ax” type profiles several times, and didn’t see any way to simply not embed a matrix profile at all, but maybe I didn’t read closely enough. Is there such an option? All I see is the default option to embed with a swapped matrix that uses sRGB primaries, and a second option to embed a shaper matrix profile that actually describes the monitor.
OK, so DisplayCAL embeds the “actually describes the monitor shaper matrix” by default in the XYZ LUT monitor profile when made by DisplayCAL? This would mean that GIMP users using “by default” DisplayCAL-made XYZ LUT monitor profiles might not even know that in GIMP they really aren’t using the monitor profile they thought they were using.
Hmm, some background information: babl now has code that provides ICC profile color space transforms without using LCMS. The rationale is that babl can do these color space transforms considerably faster than LCMS. Personally I haven’t been able to confirm or disconfirm “faster”, but some people have reported that it really is faster.
But currently babl is only set up to handle the specific use case of a monitor profile that is a matrix profile, and apparently also only if the user requests Relative Colorimetric intent.
For LAB LUT monitor profiles (which don’t have any embedded matrix profile), babl automatically hands the requested profile conversion to the monitor over to LCMS, or rather to GIMP, which hands the transform over to LCMS.
For XYZ LUT monitor profiles with embedded matrix profiles, and if relative colorimetric intent is chosen (which most people ideally should be using most of the time), then babl uses the embedded matrix profile by default. Hence the problem.
Well, on the one hand, Pippin’s point seems to be that if a matrix profile is embedded in what is ostensibly an XYZ LUT profile, how is software even supposed to know whether to use the LUT tables or the matrix? I didn’t look very hard (it’s a very long document), but I didn’t see any provision in the ICC V4 specs for embedding a matrix in an n-channel ICC profile, and I don’t recall ever seeing mention of such a thing in my past perusals of the ICC specs.
On the other hand, it seems obvious that if a user selects a monitor profile with LUT tables, use the LUT tables. LCMS doesn’t have this problem of course, and LCMS used to handle all GIMP color space transforms.
In all fairness not all software ignores the matrix - last I checked Chrome used the matrix and produced swapped colors.
Regarding “Doing the right thing” I agree with you 100%. To me, this is a bug. Worse, it’s a regression from something that used to work before. Fortunately there’s a workaround but users shouldn’t have to start GIMP from the command line using an environmental variable just to get GIMP to use the actual profile the user chose in “Preferences/Color Management”.