I just installed McGimp 2.10.6 in order to access the features of G’MIC, and I have a basic question about color management.
I exported a .jpg from Lightroom in the sRGB color space in order to work in GIMP. I then opened the .jpg in GIMP and was confronted with the message:
The image X.jpg has an embedded color profile sRGB IEC661966-2.1.
Convert the the image to the RGB working space? GIMP Built-in sRGB.
My impression is that sRBG is a uniform color space that should allow me to work different applications without color management issues. What are the consequences of converting to the GIMP built-in color space? Is this just a semantic issue or are there are actual changes to the colors in the file happening when I import in this way?
It would be nice if all profile vendors distributed the exact same version of the sRGB ICC profile. But they don’t:
GIMP’s built-in sRGB color space is a functional match to the ArgyllCMS “sRGB.icm”, which as far as I can tell is the real, true, original sRGB profile - see the Addendum to the above article.
As noted in the article (I wrote the article fwiw) there are actual changes between the various sRGB profiles. It’s not just semantics.
Try just assigning GIMP’s built-in sRGB profile - if you don’t see any color changes in your image, probably all is good. Otherwise there are issues to face and decisions to make.
Unfortunately assigning (or converting) to GIMP’s built-in sRGB profile currently means this built-in sRGB profile isn’t embedded when you export from GIMP, which can and does cause issues when opening the image with another application. See this bug report for workarounds and the current state of “when will GIMP finally embed GIMP’s built-in sRGB profile”:
It’s true, Gimp can convert to its own sRGB profile, but then doesn’t embed it. Which seems totally crazy to me. I can’t see why I would accept Gimp’s offer to convert my image from some other sRGB to its built-in sRGB profile, only to discard the vital new profile data.
My advice is: until Gimp embeds its profile, never let it convert from some other sRGB profile.
The good news is, as the other thread says, an image with embedded sRGB-elle-V4-srgbtrc.icc undergoes no changes when converted with perceptual intent to Gimp’s internal sRGB. And that profile is embedded in the saved image. This is true for 16-bit/channel/pixel integer images, and 32-bit floating-point images.
This is not true of sRGB.icc distributed with ImageMagick.
Just to clarify a point regarding perceptual intent, there aren’t any perceptual intent tables in a matrix ICC profile. All of my RGB profiles are matrix profiles, same is true for RawTherapee, darktable, PhotoFlow, and GIMP’s built-in sRGB profiles, and the ArgyllCMS “sRGB.icm” profile.
With matrix ICC profiles, when you ask for perceptual intent, you get relative colorimetric, which does clip, which does run the risk of perhaps clipping some “already at the limits of the source color gamut” colors even when the source color profile is supposed to also be sRGB.
Thanks @Elle for your work documenting this. It is a somewhat confusing issue. Let me ask a simple question first. (I have more.)
If I choose to open a file, keep the embedded profile, edit it in GIMP, then save it to disk for printing or web display, will the colors turn out correctly when displayed/printed? That is, why not just “keep” the embedded profile (as @snibgo suggests)? Are there any downsides to doing this?
I suppose this will not work for images created in GIMP, but since I only use it edit digital photos from raw converters, perhaps this is a good solution?
Hmm, there’s a great big gap between “what you see on the screen when editing using GIMP or any other image editor” and “what you get when making a print” - room for many issues that have nothing to do with the image editor, and depending on your monitor and the next person’s monitor, there are similar gaps between the image you post to the web and the image someone else sees.
Rephrasing as a question that’s just about using GIMP: Are results technically correct when editing images in RGB color spaces other than GIMP’s built-in sRGB color space?
The answer is that it depends. Specifically it depends on:
Which version of GIMP.
Whether the image’s ICC profile is a “pretty close version” of GIMP’s built-in sRGB profile, in which case just assign the built-in profile upon opening the image file with GIMP and then assign whatever “from disk” sRGB profile you want when you are ready to export back to disk.
The specific editing operation(s) you happen to use.
Whether the TRC of your profile is “in step” with GIMP’s internal code for switching from linear RGB to RGB encoded using the sRGB TRC.
Whether you are using the “Advanced Color Options” to “assume sRGB” or “convert” - which option you should choose depends on the operation and you’d have to know GIMP and GEGL code better than I do to know which choice is actually correct under what circumstances.
The phase of the moon and the day of the week (just kidding )
I don’t even try to keep up with these sorts of issues - the situation is very complex and in a constant state of change.
When I use GIMP I edit in GIMP’s built-in sRGB color space unless I’m helping to test GIMP-2.99, which has taken some important steps towards “any RGB”, which I think will also be ported to GIMP-2.10 once it’s working properly.
My apologies for not having more definitive things to say. GIMP has come a long, long way from being “an 8-bit sRGB only” image editor. The pieces are being put together that will be needed to fully support editing in any well-behaved RGB working space but it’s a slow process and there are many, many other coding tasks that also need attention.
Thank you, Elle, for the extremely detailed answer. I clearly have some reading on color management to do, however the impression I get is that not converting to sRBG is no free lunch.
So let me ask a few more things. First, for “quick and dirty” image editing, suppose I import a sRGB image (say from Lightroom or another raw developer), convert to the native GIMP space, and see no real changes in the image. In this case I gather the following procedure is correct.
Save the assigned (GIMP sRGB) profile to disk as myprofile.icc via “Image/Color Management/Save color profile to file.”
Use Image/Color Management/Convert to Color Profile on myprofile.icc to force GIMP to embed the file.
Save file the disk.
Will this force GIMP to embed the profile and give “technically correct” results?
You should interpret this questions as, “What are the best practices for color management assuming I am happy with the conversion to the native space?”
Second, which of the GIMP conversion options should I use for best results? There are four in the dialog box I see when I open an image.
Third, if I for some reason am not happy with the conversion to GIMP space, you say “there are issues to face and decisions to make.” What can be done in this case?
Finally, does editing 16-bit tiff files introduce any new complications in color management compared to 8-bit jpegs?
Thanks again for all the help and information.
edit: Let me add one more.
I am considering getting some photos printed (mostly as a test run for future printings to check color). Many labs I have looked at require sRGB files, but they do not say which sRGB. I am guessing sRGB IEC61966-2.1 as this is the Lightroom default and the sRGB specified by Nations Photo Lab.
So, how close is the GIMP space to sRGB IEC61966-2.1?
Most software reads and displays the “Profile Description” tag. For example, the ArgyllCMS “sRGB.icm” profile has this in the information tag:
sRGB IEC61966-2.1 (Equivalent to www.srgb.com 1998 HP profile)
An ICC profile is basically just a collection of tags carrying various bits of information. There is absolutely no way to tell from the contents of the Description tag what’s actually contained in the other ICC profile tags.
I’m guessing that your Lightroom-embedded sRGB profile is actually a profile supplied by your operating system. Last I checked, Adobe was no longer distributing any sRGB profiles - they used to, and it was a functional equivalent of the profile supplied by older versions of Windows, which in turn was a functional equivalent of the ArgyllCMS “sRGB.icm” profile.
The old sRGB profile that used to be distributed by Adobe might still be included in non-free software packaged for various Linux distributions, though you might need to find older packages.
I don’t know what sRGB profile is being distributed with newer versions of Windows or with Macs.
If you want an sRGB profile that has all the original sRGB tags - many of which have no effect whatsoever on the “function” of the profile - and you want to use a free/libre sRGB profile - then use the ArgyllCMS sRGB.icm profile.
GIMP’s built-in profile is functionally equivalent to the ArgyllCMS sRGB.icm, as are my sRGB profiles that have the sRGB TRC. By "functionally equivalent "I mean the primaries match and the TRC matches, except that my V4 profiles use a parametric version of the sRGB V2 “point” TRC. Darktable and PhotoFlow also provide functionally equivalent sRGB profiles, same primaries and TRC as that used by GIMP. RawTherapee used to provide a slightly different sRGB profile but I think the RT profile has been updated recently.
If two profiles are functionally equivalent, you can assign one in place of the other without doing an actual ICC profile conversion. Doing a conversion, especially on an 8-bit image, runs the risk of data loss. Never do an ICC profile conversion unless that’s what you actually want and need to do.
If you do really need to convert from one color space to another color space - say from AdobeRGB to sRGB or vice versa - it’s far better to start with an image that’s at 32f or at least 16i before doing the conversion.
Until that happy day when GIMP finally allows to embed the built-in sRGB profile, here’s how I handle the situation: If, for example, I export an sRGB file from darktable, it will be at 32f precision, so I could do an actual ICC profile conversion from the darktable sRGB profile to GIMP’s sRGB profile. But because the two profiles are functionally “the same profile”, there’s no reason to do an actual ICC profile conversion, all that’s really needed is to assign GIMP’s built-in sRGB profile - again the two profiles are functional equivalents. Then I edit the image, and when ready to export, I assign whatever “on disk” version of sRGB that seems appropriate, usually my own V2 sRGB profile for uploading to the web, or else the ArgyllCMS sRGB.icm profile - both are “free/libre” profiles. If I want to continue editing the XCF file, then after exporting I reassign the built-in sRGB profile.
How do you know if two profiles that both claim in their description tags to be “sRGB” profiles are actually functional equivalents? A quick and dirty check is just try assigning the new profile and seeing if the image still looks the same. This check depends on your monitor having a color gamut that includes the color gamut of your image and also is limited by the accuracy of your assessment of the image colors.
If you need to know 100% that the two profiles are functional equivalents, you have to examine the profiles using command line tools. Somewhere on pixls.us there is a long thread that lists a large number of commands and softwares for doing this.
The tags to check are the red, green, and blue primaries and the TRC tag. Checking the TRC tag is a bit difficult using exiftool, requires extracting the tag which I never figured out how to do, so one of the other tools is perhaps easier to use if you need to examine/compare the TRC.
There can be small discrepancies in the last digit or even two last digits in the red, green, and blue primaries tags, and you’d never see a visual difference in the actual image when assigning one or the other version of the sRGB profile. Same is true with small differences in the TRC tag.
Internally GIMP/GEGL/babl does all processing at 32-bit floating point precision. The only reason in GIMP to use lower precisions is to deal with “low RAM” situations. Speaking more generally, the major complication when converting an 8-bit image from one color space to another is data loss from working with low-precision images. The way to avoid this complication is keep the image precision at 32 bits or at least 16 bits until exporting the final image to disk.
As an aside, I think some print shops these days do allow sending 16-bit images, fwiw.
Thank you so much for clarifying those issues. Let me see if I understand regarding the practical side of this. You wrote,
Until that happy day when GIMP finally allows to embed the built-in sRGB profile, here’s how I handle the situation: If, for example, I export an sRGB file from darktable, it will be at 32f precision, so I could do an actual ICC profile conversion from the darktable sRGB profile to GIMP’s sRGB profile. But because the two profiles are functionally “the same profile”, there’s no reason to do an actual ICC profile conversion, all that’s really needed is to assign GIMP’s built-in sRGB profile - again the two profiles are functional equivalents. Then I edit the image, and when ready to export, I assign whatever “on disk” version of sRGB that seems appropriate, usually my own V2 sRGB profile for uploading to the web, or else the ArgyllCMS sRGB.icm profile - both are “free/libre” profiles. If I want to continue editing the XCF file, then after exporting I reassign the built-in sRGB profile.
So the correct recipe is:
Assign the GIMP profile to an existing file before opening it in GIMP, to avoid any conversion weirdness.
Open in GIMP, edit it, and save it.
At this point the GIMP profile is still assigned, so now assign a new one, say the ArgyllCMS one.
Since the GIMP profile is a functional match to the ArgyllCMS profile, which is apparently (hopefully?) a functional match to the sRGB IEC61966-2.1 profile used by Lightroom/my OS, this should produce “technically correct” results.
Do I have this right? And if I do, how do you recommend performing the assignment of the profiles in steps 1 and 3?
Assuming all the variously mentioned sRGB profiles are functional equivalents:
Personally I’d open the image with GIMP, and then use GIMP to assign GIMP’s built-in sRGB profile.
Personally I’d do this:
Finish editing the XCF file but keep it open.
When the editing is finished, assign the ArgyllCMS “sRGB.icm” (or whatever sRGB profile you prefer - you could even assign the Lightroom-supplied profile if you have a copy of it on disk) before exporting the image to disk.
Export the image to disk, at which point the newly-assigned version of sRGB will be embedded in the exported file.
Reassign GIMP’s built-in sRGB profile before saving the XCF file to disk and exiting GIMP.
Yes. I don’t have any way to check the actual profile that Lightroom is using on your computer, and for copyright reasons I don’t want you to upload it - but you can check for yourself with various command line tools.
But if Lightroom is using the Operating-System-Supplied sRGB profile, and if the Operating System Vendor hasn’t changed what they supply since the time of Windows XP, and if you are using Windows, then it is a functional match. I’m not just guessing here - when I wrote my article on “Will the real sRGB profile please stand up” I checked a whole lot of proprietary sRGB profiles that I didn’t include in the article, including a couple of Windows sRGB profiles from Windows 2000 and Windows XP (also Canon DPP, Bibble, etc). But I didn’t check any Mac profiles as I didn’t and don’t have any Mac computers.
Excellent! Thank you for sharing your knowledge and leading me through this. I will indeed check these profiles myself to ensure consistency, and because I am curious now.
One last question: what is the difference between “assigning” and “converting” an image to a .icc color profile? Specifically, when you say “Personally I’d open the image with GIMP, and then use GIMP to assign GIMP’s built-in sRGB profile,” does this mean you would click “Keep” instead of “Convert” on the “Convert to RGB working space?” screen that appears when you open an image in GIMP? And then manually assign the GIMP built-in profile?
You mentioned earlier that .icc conversions might lose data, while presumably this would not, so I want to be sure I understand the details of what’s happening.
edit: I think, after some detective work, that I understand the “convert” versus “assign” distinction better, so my reduces to whether the sequence of steps I outlined is correct.
I’ll leave the answer to @Elle, but I’ll say that the answer to this question was what broke the color management “encryption” for me. With This Secret, All Shall Be Revealed…
Even worse, it replicates, gimplessly. While the current win builds of RT are having some issues (here), like with the pipette, especially with Lab adjustments on cropped images, so here comes desaturation, for now.
For anyone who might not already have figured it out, this article goes over the difference between assign and convert:
The difference between “Convert” and “Assign”
In case anyone wants to follow along with the article - checking for oneself is a lot better than just reading - here’s the starting sRGB “color blocks” image, without an embedded ICC profile:
Yes, select “Keep”, and then assign. Better yet go into “Edit/Preferences/Color Management” and change the File Open Behavior to “Keep embedded profile”. See this article sections C and D for ways in which automatic conversions can lead to data loss - the article is about digiKam color management preferences but the information applies to all image editing software:
Yes, there are two ways to lose data, one just from performing the conversion at 8-bits, especially if more than one conversion is involved. The other way to lose data is from clipping. This article explains clipping with nice (imho) pictures - just looking at the pictures should suffice to get the gist:
What are ‘Clipped Colors’ from ICC Profile Conversions?
Forget it, @Elle, it was an analogue, living animal, coming back to the monitor, displaying the photo of that same biological bug.
Sorry for off-topic “jokes”, be well.
After wrestling with the whole color management thing in my hack software, I’m of the opinion now that the RGB primaries that characterize the color expressed in the image array are essential data to proper use of it, and software needs to explicitly help the user in knowing what it is. Just assuming sRGB for an image array will no longer be sufficient in the emerging world of high-gamut displays.
I’ve got to curtail hanging out at DPReview maybe, stop reading so many “why are my colors wonky?” posts…
)
