Great to see this!

Could not test that the setting makes a visual difference because none of my images changed appearance when I changed the intent

As I explained in the original issue in Bugzilla and in the issue I was asked to open here in Phabricator, to see the difference you need to use a monitor profile which supports perceptual mapping (not common) and an image whose colors lie outside your monitor's gamut (very common). I provided a sample ICC file with perceptual mapping tables in the original issues.

The label is currently "Color rendering". The technical and universal term is "Rendering intent".

The new config option works for me, but the "Advanced Config" dialog has a scrollbar, though there are no more items below. While resizing, the "Color rendering" part moves down.
Sorry, can't say anything regarding the color profiles.

@DrSlony Yes, I chose "Color rendering" deliberately, to make it sound a bit less technical and provide a hint about what it does. But if that's flat-out wrong, I can use "Rendering intent", though I'm not a huge fan of the term.

I'll try again later today with the ICC profile you provided in the other Phabricator revision.

@muhlenpfordt, sounds like an artifact of the layout hacks I needed to apply to get thenew option to appear in the correct lcoation. Gwenview's config code is really squirrely. I'll see if I can improve the situation.

I think this is one of those cases where appearing to be more user-friendly is in fact having the opposite effect. Everyone familiar with what this does is familiar with the correct term, while "color rendering" is vague at best.

OK, "Rendering intent" it is. I guess it's not so bad since this is hidden away in the Advanced page anyway.

Very good!

Thanks Nate, appreciate your patch. I'll try to find some time to review once you tested with the ICC profile and looked at the scrollbar. (Probably related: The config option shouldn't move when resizing the config dialog vertically.)

Just one comment for now: The new option will surely have some users scratch their head what this is all about, so maybe a short explanation in the docbook and/or "What's this" would be helpful ("What does this do?", "What's the difference between both options?").

This is gonna seem stupid... but how do I actually use this .icc profile?

OK, I figured out how to apply the profile using kcm_colord (installed from the colord-kde package) and I still can't see any difference between relative and perceptual for any of my photos (even using a version of Gwenview that hardcodes the relative profile, to rule out the possibility that my patch isn't working). Is this not the right way to apply a profile?

Not being a professional photographer or a color expert, I'm kind of flying blind here.

I am doing all of this in a VM, so maybe that's the issue?

Ideally, a program should let the user choose an ICC in one of two ways:

• Auto-detect the system profile
• Manually point to ICC file

Currently Gwenview only supports the first option.

Auto-detection is based on checking whether the _ICC_PROFILE X11 atom is set. You can use Argyll's dispwin (or argyll-dispwin) or DisplayCAL's displaycal-apply-profiles to set the atom to point to an ICC file, and to load the calibration curves contained in the ICC file into your graphic card's gamma table. Normally users wouldn't have to worry about that, since they would use DisplayCAL to create the ICC profile using their colorimeter, and DisplayCAL sets the atom and loads the calibration curves into the VCGT automatically.

Ah, yes... That's the old way of getting the profile. For krita, I moved to checking colord.

I'm told the X11 atom doesn't/won't work in Wayland, so polling colord would be good, and it's always good to have the fool-proof way of being able to point to the ICC file manually and explicitly.

Holy shamoley, I'm sort of amazed that you don't jump ship to macOS given the crazy state of profile handling here and how good it is there. We definitely need to do some work to improve this situation. I'll add it onto my long-term strategy list, because we'll need better profile handling to attract more professional artists.

I guess Gwenview should also move to colord. Something else for the priority list... That probably explains why using colord didn't work. I'll try the X11 approach tonight and see if that works.

You should be able to nick the colord code from Krita with lots of ease, since I made it into a separate little library :-)

Oh that would be lovely. Should we maybe put that library into a framework so it doesn't have to be duplicated?

@ngraham jumping ship is not in my nature - filing bug reports and enhancement requests to improve the situation is ;)

In D10076#196038, @DrSlony wrote:

@ngraham jumping ship is not in my nature - filing bug reports and enhancement requests to improve the situation is ;)

❤️

OK, so I did this:

$ dispwin -v ~/profile.icc 
About to open dispwin object on the display
About to set display to given calibration
Calibration set
About to destroy dispwin object

But then I get this:

$ displaycal-apply-profiles 

(displaycal-apply-profiles:8362): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",

(displaycal-apply-profiles:8362): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
================================================================================
Loading calibration curves of current display device profile...
/usr/bin
Argyll CMS 1.8.3
/usr/lib/python2.7/dist-packages/DisplayCAL/ICCProfile.py:443: Warning: There is no assigned profile for /org/freedesktop/ColorManager/devices/xrandr_VBOX_monitor_64358212_dev2_1001
--------------------------------------------------------------------------------
Command line:
  dispwin
    -v
    -d1
    -L

About to open dispwin object on the display
About to set display to given calibration
Calibration set
About to destroy dispwin object

Is that okay?

For correct color management, the calibration curves must be loaded into the VCGT and the color-managed programs must find and use the ICC profile. If either is missing, or are incompatible, colors won't be correct.

I let DisplayCal install the ICC + calibration curves for me, and DisplayCal uses this command:

argyll-dispwin -v -d1 -c -I /usr/share/color/icc/monitor.icc

I'm not too familiar with doing this through CLI, but based on the documentation* it seems that the -I (install) option is responsible for setting the X11 atom. Running dispwin without -I only loads the calibration curves from the ICC file into the VCGT, so while your whole screen will look different, it does not mean that the X11 atom has been set, and if the atom has not been set then programs which support color-management will not find the ICC file and so will not show correct colors (unless they allow the user to point to the ICC file manually - that's why I asked for this feature) .

• https://www.argyllcms.com/doc/dispwin.html

OK, the -I argument seemed to do something:

$ dispwin -v -I ~/profile.icc 
About to open dispwin object on the display
About to install '/home/dev2/profile.icc' as display's default profile
Installed '/home/dev2/profile.icc' and made it the default
About to destroy dispwin object

But then displaycal-apply-profiles still says " Warning: There is no assigned profile for /org/freedesktop/ColorManager/devices/xrandr_VBOX_monitor_64358212_dev2_1001", which seems worrying:

$ displaycal-apply-profiles 

(displaycal-apply-profiles:8759): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",

(displaycal-apply-profiles:8759): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
================================================================================
Loading calibration curves of current display device profile...
/usr/bin
Argyll CMS 1.8.3
/usr/lib/python2.7/dist-packages/DisplayCAL/ICCProfile.py:443: Warning: There is no assigned profile for /org/freedesktop/ColorManager/devices/xrandr_VBOX_monitor_64358212_dev2_1001
--------------------------------------------------------------------------------
Command line:
  dispwin
    -v
    -d1
    -L

About to open dispwin object on the display
About to set display to given calibration
Calibration set
About to destroy dispwin object

Could be because you omitted -d1.
Why not just use DisplayCAL?

Looks good!

In D10076#197598, @rkflx wrote:

No major issues found after testing and looking at the code, just some niggles.

Do you think it would be more user-friendly if the changes were applied immediately after confirming the config dialog? Currently you have to Reload the image or pan around.

Yes, ideally the new rendering intent would immediately take effect upon changing the setting, but I looked into it a bit and was not able to come up with a solution that was within my skills and understanding of Gwenview's codebase. If you want to block the patch on getting that in, I'd appreciate a helping hand. Otherwise, what do you say to landing it without support for instantly applying a new rendering intent, and work on implementing that in another patch? Thanks Henrik!

Some final notes:

1. Gwenview's "Configure" panel, and this issue topic, say "(ICC) rendering intent". To be clear, its specifically the monitor rendering intent. An image can have an input, working and output profile/space, so it's better to be clear about this, even though in Gwenview's case there is not much room for confusion since it's just an image viewer.
2. "Scale all colors equally to fit them within the active color profile's color gamut" Yes, but: a. s/active color profile's/active monitor profile's/ b. This will only work if the monitor profile is a LUT-type profile with perceptual intent gamut mapping included. Matrix profiles, or LUT profiles without perceptual mappings, will not scale the colors - they will function the same way as "relative colorimetric" does, i.e. using those profiles, nothing will change when changing this intent setting. I suggest you mention this, it's not obvious.
3. "Squash colors" - that's true because it's vague. What this intent does, and I think it's more clear to phrase it this way, is that it shows out-of-gamut colors using their nearest in-gamut representations - in-gamut colors are not altered while out-of-gamut colors are clipped. i.e. (simplified) if you have an image of a red gradient which stretches from some imaginary value 0 (min) to 100 (max), and the monitor physically cannot show reds redder than 93, the image on screen when using the relative colorimetric intent will show accurate reds from 0-93, and all pixels redder than 93 will look like 93.

That's great information, @DrSlony, but it's also way too long and technical to put inside the config window (it would become a wall of text and people would skip over it). I'd really like to avoid making the inline explanatory text labels much longer than they are now. Would you be able to craft two more appropriate text strings that can each fit within about 110 characters and incorporates the details you feel are important? Thanks!

Thanks so much Henrik! I really wasn't expecting you to do the work; I had every intention of doing it later, honest! But I do appreciate the follow-up patch. It's always good to learn from the master!

In D10076#197959, @ngraham wrote:

Thanks so much Henrik! I really wasn't expecting you to do the work; I had every intention of doing it later, honest! But I do appreciate the follow-up patch. It's always good to learn from the master!

No worries. First I spent some time researching and then I even started writing some tips for you. But in the end I thought "What the heck, let's just add a commit message and publish the Diff, so I can finally commit something myself instead of only doing review after review".