Wrong rendering intent when using monitor profile

[Beep6581]

Copied from http://www.mail-archive.com/geeqie-devel@lists.sourceforge.net/msg01816.html

Hello

There is quite a serious bug or lack of feature in Geeqie. One can use a
monitor profile, but the monitor profile uses the perceptual rendering intent
instead of relative colorimetric, if it supports both. The default option
should always be relative colorimetric, even if more rendering intents are
present in the profile. That is of utmost importance and more of a bug.
Secondary to that is adding an easily-accessible option to switch rendering
intents, more of a feature request.

This is my monitor profile which when used in Geeqie leads to very wrong
colors because the perceptual intent is used. When I use it in RawTherapee,
GIMP or XnViewMP I can select relative colorimetric, and then things are
good.
https://filebin.net/jh38xbpadwa0xmku/latest.icc

I hope this issue gets addressed soon, because until such a time I must
resort to other image viewers when I need color management.

Kind regards

cclark replied:

At around line 187 of color-man.c is:

    cc->transform = cmsCreateTransform(cc->profile_in,
                       (has_alpha) ? TYPE_RGBA_8 : TYPE_RGB_8,
                       cc->profile_out,
                       (has_alpha) ? TYPE_RGBA_8 : TYPE_RGB_8,
                       INTENT_PERCEPTUAL, 0);

INTENT_PERCEPTUAL is what lcms2 uses as default in its documentation.
If it were simply a matter of swapping that to INTENT_RELATIVE_COLORIMETRIC, it would be easy to put an option in the preferences tab.
In fact, if lcms2 has a "cmsIsIntentSupported" function, it would be possible to put a drop-down box of the available intents.

[Beep6581]

Relative colorimetric renders colors accurately as much as possible, unless they are out of gamut in which case they get clipped to the nearest in-gamut color. The result is that the majority of colors are pleasing and correct, with a little clipping of highly saturated tones in a few photos. That is what people want and are used to, and it should be the default.

Perceptual squashes the source gamut into the target gamut, making all colors wrong. Why would anyone want this? Well, when I process raw photos on my laptop which covers only 75% of the sRGB gamut, I adjust the hues using relative colorimetric rendering so that the colors I see are correct, but then I might switch to perceptual when adjusting the saturation or chroma if the photo has some highly saturated colors which it is important that I should not clip, for example a photo of a rose or hibiscus flower:
http://londonlight.org/i/2015-05-03%20macro%202.jpg
http://londonlight.org/i/2015-05-07_soderasens_7.jpg
I do this so that the source gamut fits in my monitor's small gamut which lets me adjust the chroma so that it is saturated but does not clip. While doing this adjustment the hue is wrong but that does not matter - not clipping the highly saturated colors is what's important at this point. Once I'm done with adjusting the saturation or chroma, I switch back from perceptual to relative colorimetric.

Download those two photos and view them in Geeqie using my monitor color profile (or your own monitor profile if you have one). They will look completely wrong when using perceptual but right when using relative colorimetric.

As you see, there is a need for perceptual, but it should not be the default intent.

[caclark]

Attached to this message is a patch file which I believe provides the required function. I think it important that someone who knows how this thing should work should check this before it goes into the master.

When Apply in the Preferences tab is clicked, the Render Intent is updated and the cache reset, but the image icon with the current focus is not updated - you will have to switch focus to another image and back again in that case.
render_intent.diff.txt

[Beep6581]

Hello, has this been merged yet?

[cdc100]

I'll add my voice to this, it would be great for geeqie to support rendering intents.

[Beep6581]

This issue #414 as well as pull request #423 were both closed with no explanation, and the master branch commit history shows that the merge was not done yet. Could you explain what's happening?

[caclark]

Sorry for the chaos.

If you are tracking geeqie-devel@lists.sourceforge.net you will see what
happened and, if necessary, how to get yourself back in sync.

[Beep6581]

Thank you for the merge 👍

[Beep6581]

Could someone please tell me which commit the fix was in?

[mowgli]

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Mo den 19. Dez 2016 um 21:48 schrieb Beep6581:

Could someone please tell me which commit the patch was committed in?

c991abd in merge-request 423. Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <Klaus@Ethgen.ch> Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -----BEGIN PGP SIGNATURE----- Comment: Charset: ISO-8859-1 iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhYSQ0ACgkQpnwKsYAZ 9qwZnAwAsM9hJXMc/iCLrGIu7riI546B2jSOabFWvWCB/uvVYQiHVHbmsVXJLi3I kQdSiqxRjQvzihXhMHFR0HJkE+Y+pAa52x8FT1enEOihCw+Wk2X8qA9DVU8OLGxc laa9R50dkwTpZzjQbVPhc2ydEv4Qx6CmGjWfINMp+zW1GmmvtjFoldZ5aylU/d8J BO66/OKbRRixoM1fHaagdZG2hSCOBtyMPVXO5yt5Zz8z6bUtS2sqiwLQyGRz7X0r B1Ps7N809OYOM0QHMT8H8eZUK7RpNGgDBfo8S6R0KS5iPczRxu3988wrlNYEw8Re VYD6g3mOxQpZrdEBes1GgPKOefMyDvioAi0LD/qov4wyuX0iGss6i7SQ2nSPKvJT Ly2s9rFOvX9HbuXF36410gQnP1NBZ3zlS271u8drfsgnY8SiEUkKBuAd/upguOp4 Ym2YLuoejiqSSwhr3i82VRBI7dt6aOjV5pJ76HgfOZDIjZMVrQilO8rFtlLIBj3X 78PfhqpP =Naqt -----END PGP SIGNATURE-----

[Beep6581]

Thank you @mowgli , I confirm that the rendering intent selection is working correctly, at least for the RC and P modes which are the only two I can test.