Some time back, I had a thread on sRGB exports into JPG from GIMP. Most of the time, it works ok.
Now I’ve done some work (all in ProPhotoRGB) which works great between Zerene Stacker and GIMP 2.10.10. However, when I convert to sRGB and export to JPG it’s not quite right.
Here’s the XCF and my JPG.
While I usually just print (and the XCF prints perfectly into TurboPrint), I’d still like to post more into a gallery.
Any guidance would be appreciated.
4/21/2019 EDIT:
Per the thread below, (1) I’ve adopted Elle Stone’s V4 sRGB profile and (2) forced the Chrome browser to sRGB.
For (1), here’s the relevant content:
Or you can save a copy of GIMP’s built-in sRGB profile to disk, eg like this: Create a new image in GIMP. Make sure it’s at “perceptual” precision (“Image/Precision”) and that the built-in profile is assigned. Then do “Image/Color Management/Save color profile to file” and save the profile to disk so you can assign the “on disk” profile before exporting the image to disk. Just make sure that the image really is at “perceptual” precision before assigning the profile from disk.
As @afre said, it may be just about color profile issues.
It could also be a bug that I just fixed a few days ago: if your work image was linear (like 32-bit float linear) and you were to export the profile together with the image, we were exporting as non-linear while attaching the linear profile. This resulted in washed-out colors. Now we convert the profile appropriately; unfortunately GIMP 2.10.10 has the bug.
You might wonder why this bug didn’t show earlier. I think the reason is that we used to not export the default sRGB profile (which is what most people used). So the problem would only have shown for people who explicitly chose a linear profile from disk. Since GIMP 2.10.10, GIMP is honoring the “export profile” option even when the profile is the default one. Unfortunately it was not converting it on export.
In the meantime, the workaround would be to temporarily convert to non-linear before exporting (then don’t forget to undo the conversion to restore your work image to expected linear precision).
I tried to figure out what GIMP now does from the commit message and conversation in #1070, but it’s not clear. In the latest git, how do I choose the gamma encoding of the saved image?
We are always exporting JPEG as 8-bit per channel non-linear. So if you are working on a 32-bit float linear work image for high bit depth precision, it will still be exported in the end to 8-bit (JPEG limitation). And on this lower precision, non-linear is better.
Unfortunately we were exporting profiles as-is (without echoing the linear → non-linear change). This was not a problem until now for images using default GIMP profile, since we were not actually exporting these profiles (the bug existed but only when using explicitly assigned profiles so it went a bit under our radar; unlike now where we got several reports in just a few days).
So let’s me make an example:
Say your work image is 32-bit float linear and you didn’t assign a profile (default linear profile of GIMP).
You export your image as JPEG with the profile.
GIMP exports an 8-bit sRGB image with the work profile, hence with a linear profile.
Result: your colors are washed out.
Workaround: before export (step 2 above), convert your image to sRGB in the Image > Precision menu (this will also convert the profile), then do the export, then undo the conversion.
P.S.: actually I will add an exception to the “always export as non-linear”. We should probably export as linear if your work image is also 8-bit linear. This exception most likely make sense as the image creator did an explicit choice and we should assume that one knows what one is doing.
This exception already existed in the PNG exporter. I will probably make the same in the JPEG one.
Does non-linear mean sRGB slope+gamma, sRGB-equivalent gamma (2.2, no slope), or something else?
It is, and while this GIMP-for-dummies behavior is good for the masses, the lack of transparency about what’s really happening is no good for those who use GIMP knowing what they do - for testing and educational purposes.
It would be nice if the logic was made visible, e.g. in the export dialog GIMP could expose the gamma encoding, offering a choice “From working profile” (default) and “Linear” (perhaps even a third option, “Custom”, with an accompanying slider or spinbox for the gamma value).
Thanks Jehan, appreciate you taking the time for a reply. I worked through the steps this morning, and it’s still not quite right. I could be missing something. So, as soon as I can, I’ll step through the entire workflow, step-by-step, and document it.
Does non-linear mean sRGB slope+gamma, sRGB-equivalent gamma (2.2, no slope), or something else?
sRGB is a specific case of non-linear, which is the common and default case. Basically non-linear uses the TRC of the profile. When it turns out the profile is sRGB (default), then non-linear implies sRGB.
the lack of transparency about what’s really happening is no good for those who use GIMP knowing what they do
I’m not sure how it could be more transparent. This is Free Software. Anyone can know exactly what is happening. It can hardly be more transparent.
Of course I understood that you meant “in the GUI”, but I don’t think that GIMP’s dialogs are the right place to teach people about color science.
e.g. in the export dialog GIMP could expose the gamma encoding,
I can’t answer on this. I am far from being the expert on this. Color science is not my area at all, especially since even though we use GIMP professionally, we don’t need to tweak gamma encoding manually when exporting. Feel free to open a feature request if you think this is needed and the devs who know best will be able to answer you. I am personally more in your “dummy/masses” category and content with it.
Though — maybe I am saying something stupid — but isn’t the gamma information set in the profile? If so, that means you can already set this information in GIMP. Why would you want to double the settings with the possibility to set contradictory information? This seems very messy.
But once again, I am not the color expert here. Maybe your proposition makes sense. Our bug tracker is open to everyone and this is where you should discuss new features, not here.
This has nothing to do with whether the software is open-sourced or not.
I explained how it could be more transparent in my previous post. To elaborate, GIMP is making changes the user is unaware of - I’m working on an image in a linear space, and GIMP quietly decides it will save using gamma encoding just because I’m saving to JPEG. Furthermore, I don’t even know whether this trickery applies to other 8-bit formats. Maybe one day someone will decide that saving at 32-bit precision should be done with linear gamma, or Rec. 2020 gamma, or you name it.
As you wrote, “the image creator did an explicit choice and we should assume that one knows what one is doing”, so GIMP is currently not following your paradigm.
Neither do I. The above is not teaching the user anything, it’s exposing an export option, no different to exposing the various TIFF compression schemes, or JPEG chroma subsampling options.
Many apps assume sRGB, so this is only an issue for the more technical users. However, I still believe it is necessary to slowly transition to a place where GIMP doesn’t assume all that much about what the user wants. A change would certainly unhinge beginners but their frustration would prompt them to ask questions and learn about colour management.
On the GUI side, just remember how GIMP transitioned from low depth non-linear to high depth linear processing. There are many little things that you could do to ease users into the new workflow. Too bad @Elle isn’t around anymore to comment…
There would be no change in default behavior. GIMP would still “lend a helping hand” by setting the gamma encoding combobox to “sRGB” when saving to JPEG. The only difference between that and what happens now is that you would get to see what GIMP is doing, and have the ability to override it with your own choice.
What I meant was that people would start fiddling with the settings without having the background knowledge. But that is okay because they will learn eventually, hopefully.
Jehan, I think I’ve been able to muddle out the correct steps for converting an image into sRGB. When I get more time, I’ll test out the workflow, because I’ve thought I had everything working, before, and then I’d get a really weird artifact.
For context, my use-case is I edit photograph raw images (Darktable or ASP) using ProPhotoRGB colorspace. I export into GIMP, and then either print or touch-up for sRGB web output. It’s the last step that introduces a lot of different choices that aren’t clear, and there aren’t help pages on everything.
category and content with it.