Hi Kai-Uwe,

sorry for the cold call :) Could you provide some input whether this change is the right thing to do?

I'm not too familiar with the current state of color management on a modern Linux Desktop, so I'm not sure whether this is something for Gwenview to fix or not and whether it is technically correct. In general I'd be in favour of anything which improves the situation for our users right now, but changes should also play nicely with any longer term vision.

If you are not able to comment currently, it would be great if you could recommend another reviewer who could help us here.

Thanks!
Henrik

Ultimately, Gwenview should allow the user to select:

Note that Gwenview currently is short on developers working on major features, most commits are minor things and bugfixes. We would be happy to review (i.e. consider, not accept right away) any patch adding more involved features applicable to Gwenview's target users, but keep in mind that this would also entail a tiny bit of responsibility (fixing bugs, ongoing maintenance) on the author's part.

@rkflx, I think @DrSlony gave good and logical reasons in the Summary as well as the bug report. My inclination is to land it.

@ngraham If you don't understand a patch, you cannot land it, which is a very basic and sensible rule to not break stuff. This is not about whether the reasoning sounds good, but about making sure it is actually good.

@DrSlony Please add a test plan (i.e. steps I can follow to compare before/after), so I can verify the intended changes as well as that it does not break other stuff.

I also have more ideas for who could review this. I will add those later, but this is not urgent as this patch is more material for master anyway (i.e. 18.04). Let me repeat: We are grateful for any patch, but at the same time it is our obligation not to regress for all those users who are happy and did not report a bug. Patience…

It took me an hour to fish out the old gear and retrieve the ICC, an equivalent of which I already posted almost two years ago:
https://bugs.kde.org/show_bug.cgi?id=359909#c0

Here is the ICC profile:

Set it as the monitor profile in a properly color-managed program such as RawTherapee or GIMP, then go through a few photos viewing them using the relative colorimetric rendering intent (which is what Gwenview should use by default) and the perceptual intent (which is what Gwenview currently uses).

Relative colorimetric:

Perceptual (all colors are squashed to fit in the gamut, this is not what you want for everyday viewing):

@rkflx Oh, I missed your ping. Sorry for the late reply.

ICC recommends the perceptual rendering intent for most situations, while viewing images. In recent years an effort was made to publish the blackpoint compensation algorithm and combine that with the relative colorimetric intent to form an alternative approach.

The perceptual rendering intent is by most users considered pretty free form of: do what you can at its best. Most of the cool stuff happens inside the ICC profiles involved.
In contrary the relative colorimetric intent with black point compensation say: stick to a special algorithm, which is reasonable and gives comparable results.

Personally I tend to the perceptual intent as a default:

• it keeps the room open for improvements
• it is the most often used default

(Perhaps Gwenview can use a system wide setting to alter the rendering intent by those users, who which so. But that might be out of scope for this patch review.)

1. It is unreasonable to force an intent which alters the appearance of the whole image in an image viewer. In-gamut colors should not suffer in an image viewer due to the monitor being unable to display a few out-of-gamut colors.
2. Matrix profiles don't support the perceptual intent. As for LUT profiles, DisplayCAL, the go-to profiling program for Linux, does not include perceptual mapping by default, the user must do that manually. Image viewers will therefore fall back to relative colorimetric. This is what happens in Gwenview and why more people haven't complained.
3. That leaves only those people who use LUT profiles and who do have perceptual mappings in their monitor profiles with the problem.
4. "ICC recommends the perceptual rendering intent for most situations" @behrmann please link to the source where the ICC recommends using the perceptual intent for viewing images displayed on screen. If such a recommendation exists, I would also like to read why they recommend it and how they justify distorting the appearance of the whole image as the optimal solution in an image viewer.
5. "it [perceptual] is the most often used default" is an odd claim. Most often used where? Printing - perhaps, difficult to say. Viewing? I don't think so. Not in GIMP, not in RawTherapee, not in Oyranos (I just installed it in a clean system and it defaulted to relative), not in Adobe Photoshop as far as I could find. Besides, Adobe's own docs have this to say about the default intents for printing (not viewing), "(Perceptual] is the standard rendering intent for the Japanese printing industry", and, "[Relative colorimetric] is the standard rendering intent for printing in North America and Europe."
6. Ideally, Gwenview should present the user with a choice of rendering intent and black point compensation, without needing a color management service installed, but that is outside the scope of this patch.

In D8763#181113, @DrSlony wrote:

1. It is unreasonable to force an intent which alters the appearance of the whole image in an image viewer. In-gamut colors should not suffer in an image viewer due to the monitor being unable to display a few out-of-gamut colors.

Out of gamut colors are not predictable in a general workflow like Gwenview is exposed to. As a image viewer, it has to handle a very wide range of imagery. Most of it will come from the internet and from digital cameras. The later are notoriously know to exceed the gamut of nearly all monitors. The amount of in-and out of gamut colors depends on the subject. Skin tones, clouds and so on will mostly be in. But flowers, fruits and other natural colors, many fashion colors, some make up and many plastic colors are often enough out of gamut. On the output side most monitors are smaller than sRGB.

2. Matrix profiles don't support the perceptual intent. As for LUT profiles, DisplayCAL, the go-to profiling program for Linux, does not include perceptual mapping by default, the user must do that manually. Image viewers will therefore fall back to relative colorimetric. This is what happens in Gwenview and why more people haven't complained.

So, Matrix profiles use relative colorimetric intent automatic, regardless of the intent specified in Gwenview.

3. That leaves only those people who use LUT profiles and who do have perceptual mappings in their monitor profiles with the problem.

You mix here a profiling question (LUT/matrix+shaper profiles for monitors) with a workflow question (rendering intent). That is not helpful for the decision of the patch.

4. "ICC recommends the perceptual rendering intent for most situations" @behrmann please link to the source where the ICC recommends using the perceptual intent for viewing images displayed on screen. If such a recommendation exists, I would also like to read why they recommend it and how they justify distorting the appearance of the whole image as the optimal solution in an image viewer.

"A.3.2 Perceptual Intent
The exact gamut mapping of the perceptual intent is vendor specific and involves compromises such as
trading off preservation of contrast in order to preserve detail throughout the tonal range. It is useful for
general reproduction of images, particularly pictorial or photographic-type images."

Where as the colorimetric intents are much more narrow in use:
"A.3.1.2 Media-Relative Colorimetric Intent
... It is useful for colors that have already been mapped to a medium with a smaller gamut than the reference medium
(and therefore need no further compression)."

http://www.color.org/ICC_Minor_Revision_for_Web.pdf

5. "it [perceptual] is the most often used default" is an odd claim. Most often used where? Printing - perhaps, difficult to say. Viewing? I don't think so. Not in GIMP, not in RawTherapee, not in Oyranos (I just installed it in a clean system and it defaulted to relative), not in Adobe Photoshop as far as I could find. Besides, Adobe's own docs have this to say about the default intents for printing (not viewing), "(Perceptual] is the standard rendering intent for the Japanese printing industry", and, "[Relative colorimetric] is the standard rendering intent for printing in North America and Europe."

At least Oyranos uses perceptual by default. However some of it's policies use different settings in previous releases.

Adobe, as a company, has a very special view. ( I usually read them with a grain of salt. ) Your citation above refers to printing material, which is a minority of imaging material.

FireFox gfx.color_management.rendering_intent defaults to zero/0, which means perceptual intent. Not sure about Chromebrowser or IE.

In D8763#180987, @DrSlony wrote:

Here is the ICC profile:

HSD173PUW1 #1 2016-10-19 19-21 D6500 2.2 F-S XYZLUT+MTX 100% 4.0.icc788 KBDownload

Set it as the monitor profile in a properly color-managed program such as RawTherapee or GIMP, then go through a few photos viewing them using the relative colorimetric rendering intent (which is what Gwenview should use by default) and the perceptual intent (which is what Gwenview currently uses).

Thanks for the test set. To me it looks like, there might be a problem in the profiler software and not in the viewer or CMM, for that matter.

@behrmann Thanks so much, your insights and perspective are really helpful.

Here's my plan going forward as time permits:

• Ask the original author of the lines regarding his intentions.
• Review the behaviour in different situations and compare what other apps with target users similar to Gwenview are doing.
• Read through all of the many comments on Phab and Bugzilla again.
• Take a decision.

You mix here a profiling question (LUT/matrix+shaper profiles for monitors) with a workflow question (rendering intent).

No, because Gwenview forces perceptual down my throat only because my monitor profile happens to support it. Bad design.

It is useful for general reproduction of images, particularly pictorial or photographic-type images.

It is useful, but in general not in an image viewer. It is useful when adjusting tones (i.e. in an image editor) using a monitor which cannot reproduce all the colors in the image. Then one may want to use perceptual to know that one's not pushing colors out of gamut, even though while tweaking all the colors are altered in order to fit the gamut of the image into that which the monitor can reproduce. To put it in different words, when an image has aesthetically pleasing colors to begin with and these colors are displayed correctly, then the image is still aesthetically pleasing - the deep blue sky above the beach and the red bikini are still deep blue and red on my screen, respectively. However, when using perceptual, it may alter all tones (i.e. decreases saturation, or increases lightness, or alters hues) to fit the image gamut into the monitor's gamut, then the deep blue sky is no longer deep blue but desaturated-blue, and the bikini I know to be red is no longer red but pink-red, and the image is no longer aesthetically pleasing, just potentially technically useful. An image viewer should show images unaltered where possible to keep them aesthetically pleasing. An image editor should go beyond that and be technically more useful, when used correctly, i.e. allow one to work with colors one's monitor might not be able to reproduce.

When viewing images in an image viewer using a monitor profile, all in-gamut colors should be exactly as they are. A given tone of red which is in the image and which my monitor can reproduce should be displayed as exactly that tone of red. It should not be shown as light-red or pink or any other variation (there are various ways of compressing one gamut within another) only because the image gamut had to be compressed in order to fit into my monitor's gamut.

In conclusion, the fast and easy fix is for Gwenview to change INTENT_PERCEPTUAL to INTENT_RELATIVE_COLORIMETRIC, while the ideal solution is for it to have a combobox which allows one to change the potentially used rendering intent.

@rempt Hi Boud, greetings from Gwenview land. I know you are busy, but it would be great if you could help us out with a question we have regarding an old commit of yours to Gwenview from 5 years ago: In d5635328f33c you introduce some colour correction and in particular INTENT_PERCEPTUAL, cmsFLAGS_BLACKPOINTCOMPENSATION.

Could you tell us why you went for "perceptual" as a default and not "relative", as this Diff claims to be more appropriate for a simple image viewer like Gwenview?

Thanks and keep up the good work on Krita ;)

I think the only reason I used Perceptual is because that's also the default in Krita, and always has been. I think Cyrille decided upon that. If that's wrong, I'm open to changing that in Krita as well...

Added:

In Krita it's configurable. It should be configurable in gwenview as well, but if it is just changed, I have one concern: an image would look different in gwenview and in Krita, and I'm sure we're going to get bug reports about that.

Since the sticking point seems like it would be resolved if this was configurable, I'll see if I can whip up a patch today or tomorrow that makes it configurable, and then we can end this destructive conflict, and bring order to the galaxy!

That would be fantastic!

@rempt Thanks for taking the time to comment. You make a good point which we should keep in mind.

@ngraham Sure, give it a try. Let's just hope we don't open an even bigger can of worms with this colour profile topic ;)

It's no accident this exists:
https://xkcd.com/1882/
;)

See D10076.

Finally got a chance to look deeper into the topic, so I'd like to summarize and conclude regarding what default to choose.

I did quite some reading and tested a lot of applications. To me it seems that "Perceptual" is the most used default in FLOSS apps and often recommended in photography contexts. On the other hand, some sources question this practice and Photoshop defaults to "Relative" (but may have different motives for that). Apparently the best way depends on context (i.e. image content, output media, support in ICC profile) and it's hard to choose a default.

Given what Kai-Uwe and Boud said and also how I feel about the topic after reading through all comments again, for now I recommend to leave the default as-is. If we get more bugreports after exposing it in the UI, we can reconsider (keeping in mind happy users normally don't speak up).

@DrSlony Would you mind setting the status of your Diff to "Abandoned"? (This is only so that it does not clutter the reviewer's task queues anymore, of course we'll continue to work on your feature request in D10076.)

Now that it's user-selectable with this patch, the default matters much less, but FWIW I reached the same conclusion as you.

In D8763#197594, @ngraham wrote:

Now that it's user-selectable with this patch, the default matters much less, but FWIW I reached the same conclusion as you.

Yup. It was more of a document-the-current-thoughts-for-the future kind of comment ;)