Re: [Gimp-user] color management -- basic question

[Elle Stone <ellestone ninedegreesbelow com>]

On 01/08/2017 07:47 PM, Partha Bagchi wrote:
> Try Elle Stone's color corrected experimental version. See if that helps.
> CCing her in case.
Hi Casey,

My apologies, I'm not sure exactly what you are describing below, so 
I've asked a couple of questions to try to figure out what procedures 
you are using.
> On Sun, Jan 8, 2017 at 6:37 PM, Casey Connor <gimp-user-list caseyconnor org
> > wrote:
> > Hi -- basic color management question here; this is gimp 2.9.5 (commit
> > 00faf17965) on Linux.
> >
> > If I open a colorful image and assign a ProPhoto profile to it, the colors
> > get blown out, as expected.
In default GIMP, you really should not try to edit images that are in 
any color space other than sRGB (and specifically in the default GIMP 
built-in sRGB color space). This is because quite a few editing 
algorithms in default GIMP use either hard-coded sRGB primaries, or 
hard-coded sRGB TRC values, or both.
So if you want to edit ProPhotoRGB images, then yes, Partha's advice is 
good - use GIMP-CCE.
First question: What color space is the "colorful image" actually in 
before you assign a ProPhotoRGB ICC profile to the image?
> > If I set the monitor profile to various color profiles, the colors shift
> > around, as expected.
Second question: Trying out different monitor profiles is very 
educational 
(http://ninedegreesbelow.com/photography/color-management-experiments-1.html). 
But I'm curious as to what your specific reasons might be for trying 
various color profiles as your monitor profile - is this to verify that 
GIMP is actually using your chosen monitor profile?
> > If I set the monitor profile to sRGB, and then try all the various
> > rendering intents, the colors never change, which surprises/confuses me.
There are many versions of the sRGB ICC profile 
(http://ninedegreesbelow.com/photography/srgb-profile-comparison.html). 
Most of these versions are matrix profiles. Where did you get the sRGB 
profile that you are using as the monitor profile, and what's its exact 
file name?
The color.org website does have a downloadable LUT sRGB profile 
(actually two such profiles: http://www.color.org/srgbprofiles.xalter). 
But these profiles are for use in a specialized print-oriented workflow 
and should not be used as monitor profiles or for general purpose 
editing. I'd recommend that you never used these LUT sRGB profiles 
unless you know exactly what they are for and how to use them.
The reason I mention "matrix" vs "LUT" profiles is because unless one or 
both of the source and destination profiles is/are a LUT profile, there 
is no saturation or perceptual intent table in either profile 
(http://ninedegreesbelow.com/photography/icc-profile-conversion-intents.html). 
So if you request these intents, what you get is relative colorimetric 
instead.
And if the destination profile is a "display" profile, then in a V4 
workflow (which is what LCMS2 supplies - GIMP uses LCMS2 for ICC profile 
conversions), any request for an absolute colorimetric intent conversion 
is ignored, and you get relative colorimetric intent instead. Why? 
Because the V4 ICC specs assume is that your eyes are 100% adapted to 
the white point of the display. Monitor profiles are "display" profile, 
and in fact all RGB matrix working space profiles (sRGB, ProPhotoRGB, 
AdobeRGB, etc) are also classified as "display" profiles.
In GIMP 2.8, using perceptual vs relative colorimetric intent does make 
a difference for *some* monitor profiles. But this is because there is a 
bug in 2.8 that activates or doesn't activate using black point 
compensation, depending on whether you choose relative colorimetric or 
perceptual intent 
(http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html#black-point-compensation). 
But the sRGB matrix profile has a zero black point and so using (most 
versions of) sRGB as the monitor profile doesn't trigger this bug.
I say "most" versions of sRGB don't trigger this bug because color.org 
did at one point distribute a faulty sRGB matrix profile with a non-zero 
black point and TRC, specifically for use as a monitor profile. 
Fortunately they've removed this profile from their download page, and 
if you have a copy of it, the best thing you can do is simply not use 
it, ever, and especially not for editing.
Well, I stand corrected. Color.org has removed both of their older V2 
sRGB matrix profiles and put up "sRGB2014.icc" which has a non-zero 
black point coupled with a TRC that starts at zero. Go figure. I'm 
assuming that LCMS2 will use the TRC and ignore the conflicting black 
point  tag. But I haven't experimented to confirm. Don't use this profile.
If you need ICC profiles, I provide a suite of well-behaved ICC profiles 
here: https://github.com/ellelstone/elles_icc_profiles - click the 
"Clone or download" button to download the zip file, just ignore the 
code folder (unless you feel like compiling your own set of profiles), 
and look in the "profiles" folder to find the already made ICC profiles. 
This profile: "sRGB-elle-V4-srgbtrc.icc" is exactly equivalent to the 
GIMP built-in sRGB profile.
> > My expectation was that since gimp is interpreting the colors of the image
> > as being in the ProPhoto space, and I've told it that the monitor is in
> > sRGB, changing the rendering intent should change the displayed colors as
> > it shifts them to be in-gamut for sRGB.
Unless the monitor profile has a perceptual or saturation intent table, 
changing the rendering intent makes no difference. Again, almost 
certainly the sRGB profile you are using for your monitor profile is a 
matrix profile, hence no tables, hence when you ask for perceptual or 
saturation intent, what you get is relative colorimetric intent, which 
just clips the colors to the boundaries of the sRGB color gamut.
> > I understand (from the tooltip) that I shouldn't expect preceptual vs.
> > relative colorimetric to exhibit a difference, but shouldn't I see a change
> > with both saturation and absolute colorimetric?
No, because saturation intent requires a LUT profile with a saturation 
intent table, which a *matrix* sRGB color space profile doesn't have 
(not even all LUT profiles have a saturation intent table). And as noted 
above, in a V4 workflow a request for absolute colorimetric intent is 
ignored when the destination profile (the monitor profile in this case) 
is a "display" profile.
Best,
Elle