Problem when using XYZ LUT monitor profile with GIMP-2.10, GIMP-2.99

[gwgill (Graeme W. Gill)]

Hi Elle,
note that the swapped matrix is added to profiles that are intended to be XYZ cLUT profiles (colprof -ax option). Prior versions of ArgyllCMS didn’t add a matrix to such a profile, but certain software then refused to load the profiles at all, and it seemed better to let them load and diagnose the problem (that they don’t handle cLUT profiles) more positively by recognizing the swapped matrix channels. Currently there’s no option to generate a display profile with just the XYZ cLUT. You can create a display profile with just a Lab* cLUT though. You can create a profile with accurate XYZ cLUT and Matrix tags using the -aX option, but you probably won’t know from looking at the color which tags a CMM/Application is actually using.

Typically an application not handling cLUT profiles is because the authors haven’t implemented full ICCV2 support, i.e. haven’t implemented the cLUT execution code. (There is little excuse for this when lcms is freely available though, even if that means that the cLUT path is not as fast as the matrix path. GNU licensed software could also use Argyll’s imdi code, which has faster cLUT code in most cases when running on a general purpose CPU.)

[gwgill (Graeme W. Gill)]

@Elle

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?

ICC profiles don’t have any way of saying what “type” of color transform algorithm they use. They are just a bunch of tags that have to meet at least one minimum set, but there are many combinations that are legal and usable (and even more if you use ICCV4 or ICCMAX tags).

It’s up to the CMM to choose a priority of which tags to use, and how to fall back if tags are missing. I’m not sure that the ICC spec. defined any priority (I couldn’t find such a statement in a quick scan), but my assumption was that the priority would naturally be from most detailed to least detailed, i.e. that cLUT would have priority over Matrix by default, since if the user has gone to the trouble of creating a more detailed cLUT based profile, the implication is that they want to make use of it. (ArgyllCMS tools have the -o option to reverse priority). I think lcms uses the same priority order.

So I’d recommend GIMP handing the color conversion of profiles that contain cLUT tags over to lcms, rather than using the Matrix tags if they are present (i.e. invert their decision logic).

[Elle (Elle Stone)]

@gwgill -thanks so much! for casting light on this issue of what tags to use if matrix and LUT tags are both present.

I’m assuming that of course PhotoShop uses the LUT tags, but as I don’t have access to PhotoShop it’s better to ask than assume . So:

Does anyone know for sure whether PhotoShop uses the LUT tags in an XYZ LUT monitor profile made using ArgyllCMS (or DisplayCAL which uses ArgyllCMS)? To be absolutely sure you’d need an XYZ LUT monitor profile with the default matrix with the swapped channels.

In case you have access to PhotoShop, but don’t have such a monitor profile, here’s one to try:

nec-20171223-g22-t5200-R255-G239-B250-qm-cal-qh-ax.icc (531.3 KB)

It won’t matter that this profile was made for a monitor that’s not your own monitor, because the colors should look really, really wrong if PhotoShop is using the matrix instead of the LUT, for example red becomes green.

If PhotoShop is like it used to be, the only way to change the display monitor profile is through a Windows utility (used to be right-click on the screen, but I forget what to choose from the resulting menu), and then you have to restart PhotoShop.

[afre (Alan)]

I don’t have PS nor have I set up colour management on my laptop. I think Windows takes care of colour management.

It isn’t clear how Windows interacts with PS. Adobe’s help doc: Color settings in Photoshop

The doc doesn’t have images. For those, see: Photoshop Essential Color Settings

[gwgill (Graeme W. Gill)]

Hi Elle,

I’m assuming that of course PhotoShop uses the LUT tags, but as I don’t have access to PhotoShop it’s better to ask than assume . So:

I’m not sure what a current version of PhotoShop does, since I don’t have a copy.
The old version I do have (V5.5) uses the cLUT rather than matrix when both are
present when loading files, and also for its display profile. (i.e. the assumption about cLUT vs. Matrix tag priority is widespread.)

If PhotoShop is like it used to be, the only way to change the display monitor profile
is through a Windows utility (used to be right-click on the screen, but I forget what
to choose from the resulting menu), and then you have to restart PhotoShop.

Yep.

I’m not sure I’m going to persuade pippin. If not, then I’m tempted to remove
the swapped channel matrix tags from the XYZ cLUT profile as a default.
Maybe leave that in there under a different option.

– Graeme.

[Elle (Elle Stone)]

As an update, code has been added to babl that now allows users to use ArgyllCMS XYZ LUT profiles, and actually use the cLUTs instead of the matrix.

I don’t know how long it will take these changes will percolate down to various precompiled versions of babl/GEGL/GIMP. But if you compile babl/GEGL/GIMP-2.10/2.99 yourself from code pulled from git, and you update the babl code, the change is already made.

Many thanks to @gwgill for helping to clarify the issues and to babl developer Øyvind “pippin” Kolås for making the changes to the babl code.

[gwgill (Graeme W. Gill)]

So the next release of ArgyllCMS will change the colprof -ax for display profiles to just have the XYZ cLUT tags and no shaper/matrix tags. That way the application/CMM will be forced to use the cLUT or nothing. -aX is still there to create a Display XYZ cLUT with fallback shaper/matrix tags, and a new option -aY will create a Display XYZ cLUT with diagnostic channel swapped matrix tag.
(Beta test is in the usual place for people who can compile the source).

[Morgan_Hardwood]

Hi @gwgill
I wanted to know what version the next release will be and when the latest release was, so I went to the ArgyllCMS website, saw that the latest release was “Current Version 2.0.1”, but failed to find a release date. As ArgyllCMS doesn’t have a GitHub/GitLab page, could you please add the release dates to the versions?
Thank you

[Claes]

Hi @Morgan_Hardwood,
ArgyllCMS version 2.0.1 was put together on July 9, 2018,
if I am able to read the signs properly.

Have fun!
Claes in Lund, Sweden

[Elle (Elle Stone)]

Another note about how babl and GIMP does now and eventually will (or might - looking at the babl bug report linked to above, it’s stil unclear) handle monitor profiles. This note also includes matrix monitor profiles such as single-channel and three-channel shaper matrix profiles:

If you look in GIMP Preferences under Color Management, there are already two options for conversions to the monitor profile, and also the same options for conversions to the soft-proofing profile. The options are:

1. Precision / Color fidelity
2. Speed

Here’s a screenshot, where I’ve chosen “Precision / Color fidelity”:

If you use a matrix monitor profile, and you choose “Speed”, the babl matrix speed-ups are already being used. This code has been in place for awhile now. If you choose “Precision / Color fidelity”, then currently the babl matrix speed-ups are not used.

The relevant babl and GIMP code for XYZ LUT monitor profiles isn’t yet fully implemented even in git. But in the future, at least as currently planned:

• If the user has chosen an XYZ LUT monitor profile, and the user chooses “Speed” and also there is a shaper matrix in the XYZ LUT monitor profile, then the matrix is used all the time and the babl matrix performance speedups are enabled. As already notes, now there is code that detects the swapped channel matrix, and this matrix is not used.

• If the user has chosen an XYZ LUT monitor profile, and the user chooses “Precision / Color fidelity” and also there is a shaper matrix in the XYZ LUT monitor profile, then the matrix will still be used but only for generating quick previews, after which the cLUTs are used to generate a more accurate display of the image.

Given that @gwgill will be adding an option for making XYZ LUT monitor profiles that will allow not embedding any matrix at all, the new colprof options will have implications for users making such monitor profiles, and perhaps implications for the default behaviors of “gui” profile-making software such as DisplayCAL and software that’s part of gnome color management.

In other words, GIMP users need to think carefully about what options they use to make monitor profiles, regardless of whether they use the command line or use DisplayCAL or gnome color management software or whatever.

I’m hoping that once the full set of babl/GIMP code changes are actually implemented, people on this list can help test whether, how much, and under what circumstances operations in GIMP really are speeded up by choosing “Speed” vs “Precision/ Color fidelting” in GIMP Preferences.

Again, currently the babl speed-ups are only applied if you also choose “Relative colorimetric intent”.

[Morgan_Hardwood]

Hi @Claes

The intention of my post was not to ask when v2.0.1 was released, but to raise the issue that this information is missing from the website. A date in the header, “Last updated 2018/7/9”, typically applies to when the text on the page was last edited, not when a specific release listed further down on the page was tagged. The problem could be easily solved by adding a date under the version line.

There are other issues too, for example no explanation on how to report a bug (ctrl+f for “bug” and “report”), so one must resort to email.

All of these issues could be resolved by using a web-based source-code and issue-tracking system like GitLab, GitHub, etc. (both of which support email, but also so much more).

[gwgill (Graeme W. Gill)]

The intention of my post was not to ask when v2.0.1 was released, but to raise the issue that this information is missing from the website.

It will be released when it is released. There is no schedule, so there is no date to be missing from the website. Beta source is available for download. Sometimes I will make beta binaries available for those not in a position to compile their own, but this is ad-hock.

There are other issues too, for example no explanation on how to report a bug (ctrl+f for “bug” and “report”), so one must resort to email.

The website makes it clear that bugs should be reported to the ArgyllCMS mailing list or directly to me.

All of these issues could be resolved by using a web-based source-code and issue-tracking system like GitLab, GitHub, etc. (both of which support email, but also so much more).

ArgyllCMS is a personal project, and the number of bug reports is small enough that I don’t think that maintaining a formal bug tracking system would improve my life.
[ If it were a multi-person project, then public version control and bug tracking would be much more desirable. ]

[darix]

@gwgill

ArgyllCMS is a personal project, and the number of bug reports is small enough that I don’t think that maintaining a formal bug tracking system would improve my life.
[ If it were a multi-person project, then public version control and bug tracking would be much more desirable. ]

You are wrong here IMHO. Visibility for the user is also an important part. Be it end user or people like me who package the software. Being on e.g. github/gitlab also reduces the hurdle for contribution (be it code or bug reporting), as many people might have an account there already, or in the case of gitlab can reuse existing accounts.

As a side note: would you accept patches for meson as a build system for argyllcms?

[gwgill (Graeme W. Gill)]

As a side note: would you accept patches for meson as a build system for argyllcms?

No. I’d prefer to spend time working on new features and new projects rather than re-working a build system with which I happy enough. Given I use it 100 times as much as anyone else, that’s what counts. (In any case meson doesn’t work the way I prefer, since it doesn’t permit in-source builds. Depending on a large project like Python is not thrilling either - a thing I have striven for in ArgyllCMS is for it to be self contained, and not a project that is dependency hell.)
[ Of course you are free to create your own build scripts (and maintain them) for your own situation, if you so desire. ]

[Morgan_Hardwood]

Hi @gwgill

@gwgill

It will be released when it is released. There is no schedule, so there is no date to be missing from the website.

Sure, but I did not ask for a future release date. I pointed out that there is no date given for the latest release (and no release history with dates, which also comes in useful when you’re writing articles, when you’re a package maintainer for various distributions, etc.).

@gwgill

The website makes it clear that bugs should be reported to the ArgyllCMS mailing list or directly to me.

The website is a wall of text, and ctrl+f for “bug” and “report” turned up nothing useful, so I disagree that it makes that clear.

I agree with @darix

You are of course free to handle the project as you wish, but there are benefits to using a git/bug tracker even if it’s a one-man thing. In fact let me list a few off the top of my head and in no particular order:

• It exposes hundreds of thousands of existing GitHub/Lab programmers to your project without the hurdle of requiring to register for a new account. It encourages contribution.
• Clear release history with dates.
• Clear visibility of what changes from version to version, branch to branch, commit to commit.
• No overhead for you, assuming you already use git.
• You can still use GitLab/Hub via email if you prefer that.
• Clear list of bugs open and closed, your thoughts on them, and their resolution or workaround.
• Insight into the humans behind the project, their willingness to accept patches, their anti-patterns, etc.
• Not forcing others to use a mailing list to get insight into the above.

I hope that makes it worth considering.

[darix]

@gwgill

No. I’d prefer to spend time working on new features and new projects rather than re-working a build system with which I happy enough. Given I use it 100 times as much as anyone else, that’s what counts. (In any case meson doesn’t work the way I prefer, since it doesn’t permit in-source builds. Depending on a large project like Python is not thrilling either - a thing I have striven for in ArgyllCMS is for it to be self contained, and not a project that is dependency hell.)
[ Of course you are free to create your own build scripts (and maintain them) for your own situation, if you so desire. ]

And you are probably the only one still using that build system which makes contributing to it hard. I picked meson because it can handle windows/mac/linux/bsd in one build system. my POC only does linux for now but it builds part of it already. and for the dependencies … it is relatively lightweight. basically just python and ninja (though this might be optional).

The reason why I started hacking on the build system in first place that Jam did claim not to find some of the libraries which were installed though. with meson I could just query pkgconfig and be done.

[Elle (Elle Stone)]

@gwgill

The website makes it clear that bugs should be reported to the ArgyllCMS mailing list or directly to me.

@Morgan_Hardwood

The website is a wall of text, and ctrl+f for “bug” and “report” turned up nothing useful, so I disagree that it makes that clear.

That “wall of text”:

• very clearly documents how to install and use the many incredibly useful and amazing ArgyllCMS utilities.

• is chockfull of useful information about profiling devices and about ICC profiles in general.

• puts professional level monitor and printer-paper profiling in the hands of people who would never be able to afford buying into the various proprietary softwares, in the process providing tools that are as good as and often considerably better than proprietary counterparts.

ICC profile color management is tricky and difficult to get right. ArgyllCMS is the only free/libre color management software that has been consistently reliable over the years I’ve been using Linux.

The ArgyllCMS “wall of text” website, the ArgyllCMS forums, and using the ArgyllCMS utilities have taught me a lot about ICC profile color management over the years since I switched to Linux, in turn allowing me to contribute to debugging other free/libre color-managed software including GIMP. And there have been, and there continue to be, many such bugs in free/libre image editing softwares.

If you check various mailing lists, forums, and bug trackers going back in time, you will quickly see that Graham Gill has consistently given freely of his time and effort to improve image editing software and everyone’s understanding of color management. In fact he’s done so in this very thread .

Take away ArgyllCMS and Linux color management will be much the worse.

Graham Gill is just one person. Demanding that he stop what he’s been doing and change the way the project is handled to make things easier for packagers, that just seems a bit much.

If someone else wants to take on the responsibility of making consistent builds with tags and stuff for distributing ArgyllCMS to various versions of Linux and to Windows and Mac, that might be nice.

Regarding ArgyllCMS bug reports, any bugs in newly released versions of ArgyllCMS get noticed by members of the ArgyllCMS forum, and then get immediately fixed.

My apologies to Graham Gill if I’ve spoken out of turn here.

[darix]

Nobody questions that it has all those useful information. But it could be more accessible and some informations are missing or not as easily found.

[Morgan_Hardwood]

@Elle

That “wall of text”: (…)

I agree with all of the positive points.

@Elle

Demanding that he stop what he’s been doing and change the way the project is handled to make things easier for packagers

What’s the point of this straw man? I didn’t demand anything. I pointed out that a release date is missing.

@Morgan_Hardwood

Hi @gwgill
I wanted to know what version the next release will be and when the latest release was, so I went to the ArgyllCMS website, saw that the latest release was “Current Version 2.0.1”, but failed to find a release date. As ArgyllCMS doesn’t have a GitHub/GitLab page, could you please add the release dates to the versions?
Thank you

I could send a patch to add the release date beneath the release version, only the website’s code doesn’t seem to be hosted anywhere - another argument for change.

DisplayCAL’s website is also a wall of text, though it doesn’t suffer from difficulty in finding relevant information. Ctrl+f for “bug”, for “report”, for “issue”, or for the latest version, and the relevant and clear information appears immediately.

Can things be improved? They can.

[Elle (Elle Stone)]

@Morgan_Hardwood

Demanding that he stop what he’s been doing and change the way the project is handled to make things easier for packagers

What’s the point of this straw man? I didn’t demand anything. I pointed out that a release date is missing.

Hmm, my apologies, probably I should have put a quote from @darix in there when I switched topics . And perhaps “demand” was too strong a word to use. Maybe “strongly urge” would have been a better choice of words?