Try Elle Stone's color corrected experimental version. See if that helps. CCing her in case.

On Sun, Jan 8, 2017 at 6:37 PM, Casey Connor

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.

If I set the monitor profile to various color profiles, the colors shift around, as expected.

If I set the monitor profile to sRGB, and then try all the various rendering intents, the colors never change, which surprises/confuses me.

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.

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?

Thanks for any help!

-c

_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

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

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

On 01/08/2017 09:13 PM, Casey Connor wrote:

Thanks again, Partha! As a recent convert to LCH, Elle's version looks pretty amazing. I'm a little nervous to mess with my gimp install, as a non-sysadmin expert, but if Elle has the time to respond maybe she can let me know if there'd be value in trying her version. (I get the impression from her page on the subject that 2.9.5 has all the same color management stuff in it that her version does.)

It's not at all crucial to my workflow that the rendering intent be obeyed, I was just curious what was going on, because I thought I understood it and the results seemed to imply that I didn't. I wasn't sure if this was a flaw in my thinking or gimp.

Hi Casey,

I sent an answer to your previous email regarding rendering intents to the gimp user's list (and to also directly to you and Partha). But it might not reach the list for awhile because I hadn't yet resubscribed to the GIMP users mailing list when I sent the email. So the post is in moderation "awaiting approval".

Anyway, if you only ever edit sRGB images, then default GIMP 2.9 will work just fine for your editing needs. The only exception would be if you want complete control over the TRC encoding for specific operations. For example, default GIMP doesn't yet provide for linearized RGB for Curves and Levels. Whereas in CCE, if you want to make a Curves or Levels adjustment using linear RGB, you can convert the image to a linear gamma ICC profile.

But if you edit in RGB working spaces other than sRGB, it's better to use CCE
(http://ninedegreesbelow.com/photography/patched-gimp-compared-to-default-gimp.html) because of the hard-coded sRGB parameters in default GIMP 2.9.

Just keep in mind that CCE has a fair number of quirks and gotchas, for example in CCE the LCH operations, Luminance conversions to black and white, proper linear gamma down-scaling, and so forth only work as expected when the image is in a linear gamma RGB working space. Also CCE doesn't provide any decompose/compose operations, default GIMP supports importing many more file types than CCE, exchanging XCF files between default GIMP and CCE is tricky, and so forth.

I absolutely agree with you that LCH is amazing, and now that it's available, I can't imagine ever trying to edit without LCH. Default GIMP and CCE both provide the LCH blend modes. In addition CCE provides LCH color pickers and an LCH Hue-Chroma tool. So if even if you only ever edit sRGB images, you might find CCE worth using until these capabilities are added to default GIMP 2.9.

To avoid issues with installing two versions of GIMP on the same computer (which requires using prefixes and compiling from source), you can use a CCE AppImage, which are made by the author of the PhotoFlow raw processor and are available for download from here: https://pixls.us/files/

Best,
Elle

On 01/09/2017 04:41 PM, Casey Connor wrote:

The only reason I was playing with the output profile and monitor profiles was mainly to test my understanding of it, not because I was developing a particular workflow.

The "colorful image" I was using was one of the test images here: http://joco.name/2014/03/02/all-rgb-colors-in-one-image/ I used one of the 4096x4096 8-bit-per-channel images, which I scaled to 1024x1024 -- I just wanted an image to play with that I could be sure would show me a shift when/if it happened -- in other words, it's just a test image and I just assigned a randomly-chosen larger-than-sRGB gamut to it so I could see how the rendering intents looked -- so it has no associated color space, afaik, it's just "all the values" (or was, until I scaled it down.)

Thanks! for the link - those are some seriously cool and beautiful images. The only "all colors" images I knew of is Bruce Lindbloom's image here, and it's strictly utilitarian: http://brucelindbloom.com/index.html?RGB16Million.html (as an aside, there is much useful color management information on Bruce Lindbloom's website).

It seems to me that the kind of experimenting you are doing is the best way to acquire a hands-on understanding of color management.

I now understand that with the generic sRGB profile I was using I shouldn't expect the rendering intents to look any different from each other.

Longer-term, I was interested to work in wider color spaces for the sake of photography. I'd just be exporting to Wide Gamut (or whatever larger space) and opening that up in gimp. The hope was to possibly retain some more detail, soft-proof to check what's out-of-gamut, experiment, and otherwise possibly get better results with certain transformations in Gimp.

I recommend using Rec2020 or ACEScg as your "go to" wide gamut color space (but not when using default GIMP, for reasons already mentioned) - ACEScg is used by people making images for cinema, Rec2020 is the up-and-coming standard for monitors, and both of these spaces are good all-around editing color spaces.

If you edit in wide gamut color spaces, it's important to keep in mind the color gamut of your monitor profile, as your monitor simply can't show you colors that are out of gamut with respect to your monitor profile (and unless your monitor profile is accurate, the colors you see aren't a reliable guide to editing).

When I work with interpolated raw files, I use Rec2020 for initial editing (specifically a linear gamma version of Rec2020, "Rec2020-elle-V4-g10.icc"). But I also try very hard to make sure that the colors I produce while editing will fit into the sRGB color gamut for display on the web.

When affordable Rec.2020 monitors finally reach the consumer desktop (and if browsers ever are properly color-managed), editing and soft proofing will both be a lot easier.

From what you said it sounds like the CCE is the version to use if I'm going to go through with that plan, since it amends certain tools to not assume sRGB under the hood, but maybe the default version of gimp would still be useful just to get a feel for what's out-of-gamut, and I could still use g'mic tools if they work in Lab/Lch/etc, right?

Currently g'mic also is hard-coded to use the sRGB Y and XYZ values for calculating things like Luminance and for converting to LAB/LCH/etc. I did a bit of testing, and as far as I can tell there is something not quite right about the g'mic conversions to LAB even for sRGB images. So yes, g'mic has some really nice transforms. And no, those transforms can't be counted on to be accurate. Useful, yes. But not accurate.

(Also, I hope to profile my monitor soon.)

Profiling your monitor is a good thing to do. If your monitor is relatively new and has a good sRGB preset, then what you see right now is probably a pretty good guide to what your images actually look like. But not all monitors come with good sRGB presets.

If you use ArgyllCMS to profile your monitor, you have the option to make a LUT profile for exploring out of gamut colors. But I would recommend also making a matrix profile and using the matrix profile for normal image editing. If you have questions about making monitor profiles, the ArgyllCMS mailing list is a good place to start.

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?

From color.org, I think, judging by metadata? Not actually sure where it came from -- sRGB_IEC61966-2-1_black_scaled.icc

Yes, that is one of the older color.org sRGB profiles. You might want to put that profile somewhere where you'll never accidentally use it.

But yeah, nothing carefully-chosen, whatever it is -- I did read up a bit on the variety of sRGB profiles (thanks again to your site) and I know that I shouldn't trust or use or speak to any of them before checking ninedegreesbelow.com. :-)

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.

I'm sorta curious why GIMP's built-in sRGB profile rarely appears in menu lists of available profiles -- e.g. the monitor profile choice, or the soft-proofing profile choices? I only see it when converting an image to a new color profile, and that makes me wonder if I'm still misunderstanding something fundamental about profile types.

Unfortunately currently LCMS soft proofing algorithms have very many "gotchas" and limitations: https://bugzilla.gnome.org/show_bug.cgi?id=772266

So currently trying to soft proof to the built-in GIMP sRGB profile is a waste of time as LCMS soft proofing will report that all the colors are in gamut.

The PhotoFlow GIMP plug-in can be used to soft proof images, but I'm not sure if the soft proofing code has been ported to the stable branch of PhotoFlow. PhotoFlow soft proofing explicitly contains code that works around the LCMS soft proofing limitations.

I absolutely agree with you that LCH is amazing, and now that it's available, I can't imagine ever trying to edit without LCH. Default GIMP and CCE both provide the LCH blend modes. In addition CCE provides LCH color pickers and an LCH Hue-Chroma tool. So if even if you only ever edit sRGB images, you might find CCE worth using until these capabilities are added to default GIMP 2.9.

Yeah, those overlay modes are great (and thanks once again to your website for cluing me in to them).

I think you might mean "layer blend modes"? - "overlay" is the name of a particular blend mode, but it's not one of the LCH blend modes.

Are your LCH tools in the roadmap for 2.9 or 2.10?

https://bugzilla.gnome.org/show_bug.cgi?id=749902 https://bugzilla.gnome.org/show_bug.cgi?id=753163

Keep in mind that someone has to do the coding and there are many, many, many parts of GIMP that need attention before 2.10 is released.

That'd be super. I was about to file a FR for Lch mode in the native gimp levels dialog... is that already planned?

Well, what you can do is duplicate the layer, use GIMP's "Colors/Levels" or "Colors/Curves" or "Colors/Exposure" and set the layer blend mode to "Lightness", which will leave the Hue and Chroma of the original layer unaltered.

(I've been
using g'mic's colors->curves in Lch mode and it works great to boost shadows without altering colors.)

Again, if you like what you see when you use g'mic, that's wonderful. But please don't assume that what you see is "correct by the numbers". You'd have to do some testing to confirm, and again g'mic is hard-coded to use sRGB Y and XYZ values and the sRGB TRC.

Best, Elle

http://ninedegreesbelow.com
Color management and free/libre photography

On 01/10/2017 05:44 PM, Casey Connor wrote:

I had planned to use
Argyll/displaycal, and make a matrix profile per your suggestions. I think I read on your site that a LUT version would also be handy also for using occasional perceptual rendering intent to get a feel for all the detail in an image?

Yes, but depending on your monitor, normally it's better to not use the LUT profile for actual editing. And if you do use the LUT profile when editing, use relative colorimetric intent to convert to the monitor profile. Use perceptual intent for exploration, but not for editing, unless you know exactly what you are doing and why.

Truthfully I've only used my LUT monitor profile a couple of times to explore what might be hiding in the portions of an image that are clipped by a relative colorimetric conversion - in one image I was very surprised to see a whole lot of unexpected detail in areas that looked like there wasn't any detail at all.

So currently trying to soft proof to the built-in GIMP sRGB profile is a waste of time as LCMS soft proofing will report that all the colors are in gamut.

Hmmm... so if I have a wide-gamut image and set soft-proofing profile to sRGB-elle-V4-srgbtrc.icc, soft proofing works -- that's because your version of gimp's sRGB is amended in the necessary ways to make it so?

Soft proofing to sRGB-elle-V4-srgbtrc.icc (which is the exact same profile as the GIMP built-in sRGB profile) also doesn't work. The problem is in LCMS, not in the profiles. All software that uses LCMS and supports high bit depth and floating point editing is affected, and all the more so if the source color space has a linear gamma TRC. Follow the links in the GIMP bug report for more information: https://bugzilla.gnome.org/show_bug.cgi?id=772266

Best, Elle

On 01/11/2017 02:00 PM, Casey Connor wrote:

Ok, thanks -- I was just confused because you said "LCMS soft proofing will report that all the colors are in gamut" but when I soft proofed to that profile it showed lots of colors that are out of gamut... this link makes me
think it's just more complicated than that, so I won't worry about it.

No, my apologies, you are right, you will see out of gamut colors indicated in the test situation you describe. I was trying too hard to not cover a lot of cases in detail. To try to summarize the relevant details:

1. If you are editing at integer precision (8-bit integer, 16-bit integer, etc)

2. and the TRC of the source image ICC profile is reasonably close to being perceptually uniform

3a. and the image color gamut completely encompasses the soft proofing profile color gamut, or else 3b. if the soft proofing profile doesn't support unbounded ICC profile conversions,

* then the gamut check will be reasonably accurate.

So for example let's say you assign "Rec2020-elle-V4-labl.trc" to one of those very nice "all colors" images, and you've chosen "sRGB-elle-V4-srgbtrc.icc" as the soft proofing profile. The gamut checks will be accurate.

Now assign Rec2020-elle-V4-srgbtrc.icc to the source image. The gamut checks will still be very, very close to accurate.

Now assign Rec2020-elle-V4-g18.icc to the source image. The gamut checks won't be quite as accurate. Gamma=1.8 is the standard TRC for ProPhotoRGB color space.

Now assign Rec2020-elle-V4-g10.icc to the source image. The gamut checks will be completely inaccurate.

The appearance of the image will keep changing as you assign the different profiles - in fact getting lighter and lighter as the TRC gets closer to gamma=1.0. But the thing to pay attention to is the gamut checks. It helps to have the gamut check color set to magenta so the gamut check areas stand out from the image colors.

Assuming conditions 1 and 3a or 3b, then most accurate gamut check is when the TRC is the labl trc, but the sRGB trc is also pretty accurate. Both of these TRCs are close to gamma=2.2, and profiles such as AdobeRGB1998 (which has the gamma=2.2 TRC) will also show an accurate gamut check.

If you change the precision to high bit depth floating point precision, and/or if the source color gamut doesn't entirely encompass the soft proofing profile color gamut, and/or if the soft proofing profile supports unbounded ICC profile conversions, then a whole other set of LCMS soft proofing issues comes into play. For example, assign sRGB-elle-V4-srgbtrc.icc to the "all colors" test image. Change the precision to 32-bit floating point. Do "Colors/Saturation" and set the slider to 2. Now almost all the colors are exceedingly out of gamut with respect to the sRGB color space. And yet the gamut checks will have disappeared.

As an added complication, what you see partly depends on what version of LCMS2 is installed, but I'm not sure if the first relevant change came before or after LCMS 2.7, which is the minimum version of LCMS2 that will work when compiling GIMP 2.9.

Best, Elle

On 01/12/2017 01:12 PM, Elle Stone wrote:

No, my apologies, you are right, you will see out of gamut colors indicated in the test situation you describe. I was trying too hard to not cover a lot of cases in detail. To try to summarize the relevant details:

No, drat, I still got some of the details wrong. I'll correct them in a later email.

Best,
Elle

On 01/12/2017 01:12 PM, Elle Stone wrote:

On 01/11/2017 02:00 PM, Casey Connor wrote:

Ok, thanks -- I was just confused because you said "LCMS soft proofing will report that all the colors are in gamut" but when I soft proofed to that profile it showed lots of colors that are out of gamut... this link makes me
think it's just more complicated than that, so I won't worry about it.

No, my apologies, you are right, you will see out of gamut colors indicated in the test situation you describe. I was trying too hard to not cover a lot of cases in detail. To try to summarize the relevant details:

1. If you are editing at integer precision (8-bit integer, 16-bit integer, etc)

2. and the TRC of the source image ICC profile is reasonably close to being perceptually uniform

3a. and the image color gamut completely encompasses the soft proofing profile color gamut, or else 3b. if the soft proofing profile doesn't support unbounded ICC profile conversions,

* then the gamut check will be reasonably accurate.

Above is true.

Below is wrong:

So for example let's say you assign "Rec2020-elle-V4-labl.trc" to one of those very nice "all colors" images, and you've chosen "sRGB-elle-V4-srgbtrc.icc" as the soft proofing profile. The gamut checks will be accurate.

Now assign Rec2020-elle-V4-srgbtrc.icc to the source image. The gamut checks will still be very, very close to accurate.

Now assign Rec2020-elle-V4-g18.icc to the source image. The gamut checks won't be quite as accurate. Gamma=1.8 is the standard TRC for ProPhotoRGB color space.

Now assign Rec2020-elle-V4-g10.icc to the source image. The gamut checks will be completely inaccurate.

The appearance of the image will keep changing as you assign the different profiles - in fact getting lighter and lighter as the TRC gets closer to gamma=1.0. But the thing to pay attention to is the gamut checks. It helps to have the gamut check color set to magenta so the gamut check areas stand out from the image colors.

Assuming conditions 1 and 3a or 3b, then most accurate gamut check is when the TRC is the labl trc, but the sRGB trc is also pretty accurate. Both of these TRCs are close to gamma=2.2, and profiles such as AdobeRGB1998 (which has the gamma=2.2 TRC) will also show an accurate gamut check.

Below is true:

If you change the precision to high bit depth floating point precision, and/or if the source color gamut doesn't entirely encompass the soft proofing profile color gamut, and/or if the soft proofing profile supports unbounded ICC profile conversions, then a whole other set of LCMS soft proofing issues comes into play. For example, assign sRGB-elle-V4-srgbtrc.icc to the "all colors" test image. Change the precision to 32-bit floating point. Do "Colors/Saturation" and set the slider to 2. Now almost all the colors are exceedingly out of gamut with respect to the sRGB color space. And yet the gamut checks will have disappeared.

As an added complication, what you see partly depends on what version of LCMS2 is installed, but I'm not sure if the first relevant change came before or after LCMS 2.7, which is the minimum version of LCMS2 that will work when compiling GIMP 2.9.

And my apologies for the confusion!

Elle