Re: [Gimp-user] color management -- basic question
- From: Elle Stone <ellestone ninedegreesbelow com>
- To: Partha Bagchi <partha1b gmail com>, Casey Connor <gimp-user-list caseyconnor org>
- Cc: "gimp-user-list gnome org" <gimp-user-list gnome org>
- Subject: Re: [Gimp-user] color management -- basic question
- Date: Mon, 9 Jan 2017 12:00:19 -0500
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]