RESOLVED: GIMP 2.9x export to sRGB doesn't match colorspace -- very puzzling


#1

PROBLEM STATEMENT:

GIMP export to sRGB doesn’t match up to the original colorspace. https://photos.app.goo.gl/H88CHi9JyD94n6yT9 Here’s a wedding bouquet, in three images. Only the JPG straight from the RAW processor (I use ASP3) matches the image correctly.

BACKGROUND:

My normal workflow is (1) processing RAW in ASP3, (2) export to TIFF ProPhotoRGB, (3) make last minute edits in GIMP, (4) print from GIMP using TurboPrint (Canon Pro100 or Epson P800). Works great. All the color profiles match up perfectly from a color registered monitor to the final print.

If I replace step (4) with export into JPG from GIMP, the colors shift. I’ve given a link above to three flower images, and only the one that isn’t touched by GIMP is correct.

My workstation is Ubuntu 16.04, GIMP is 2.9.9

Any ideas would be appreciated


(Mica) #2

First thing is to get the latest stable version, 2.10.2.


#3

So, 16.04 doesn’t have a 2.10 release (https://www.gimp.org/downloads/, https://www.omgubuntu.co.uk/2018/05/gimp-2-10-ubuntu-download). it’s an upgrade, which I’ve done many times. And even with the wonders of GNU/Linux, an upgrade is an afternoon of work.

Does 2.10.2 convert and export from a TIFF ProPhotoRGB into an sRGB JPG ?


#4

https://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html

Apparently, GIMP is hardwired for sRGB. For reference on 2.9x versus 2.10x:

If you really do want to edit in color spaces other than sRGB, my patched version of GIMP 2.9 (“GIMP-CCE”) allows you to edit in any well-behaved RGB working space. However, please be aware that default GIMP has quite a lot of functionality that I’ve removed from GIMP-CCE.


(Mica) #5

@Carmelo_DrRaw builds an AppImage that should run just fine on Ubuntu: https://github.com/aferrero2707/gimp-appimage/releases

Elle has stopped maintaining her CCE fork, as mainline gimp is now good enough for her.


#6

I’m not sure where to go from here, other than cross-my-fingers and push in to 2.10.x

I’ve been working in GIMP 2.9.x because it supports ProPhotoRGB and that has been important for printing (see this discussion, if you have questions): https://www.dpreview.com/forums/thread/3964337?page=8.


(Morgan Hardwood) #7

@KumsaJack one thing all 2.9.* builds have in common is that they are all

  1. development builds, unstable by definition,
  2. not recent.

2.10.2 is the latest stable build, released just 3 weeks ago:

Anyone who wants a stable experience should be using the latest stable build.


(Glenn Butcher) #8

The difference appears to be not color, but tone. I can take the “odefinedcolorspace” image and make it equivalent to the others with a simple “reverse gamma” power curve. I can’t look at the profiles’ TRCs, but I’d bet there’s a difference…


#9

Elle Stone weighed in on her insights, and examined the converted outputs (and also noted the odd gamma curve). She, also, encouraged testing in GIMP 2.10.

GIMP 2.10 made no difference. Which made no sense, so I decided to use a text editor and discovered that the converted image still had the ProPhotoRGB profile definition. I ran the export again, and disabled EXIF, XMP and IPTC.

It’s all good, now. The images load just fine for web use.

I’m guessing, from the dialog in this forum, that not many are printing, and if so, not using a ProPhotoRGB colorspace. I recommend https://www.dpreview.com/forums/thread/3964337?page=8 – I printed the test samples and was startled by the difference.

Thanks !


#10

That is weird. Might be a bug or something. EXIF, XMP and IPTC metadata should have no effect on the appearance of the JPG.


#11

Not going to disagree. What I can say, is that when I chose to leave those values blank in the export, no profile text was written into the image. Web architecture pretty much defaults to sRGB, so it’s a win, even if it’s a workaround.


(Mica) #12

I’m printing, although always in AdobeRBG, as it is natively supported by my printer.

Which printer are you using that can take advantage of ProPhoto?


(Morgan Hardwood) #13

@KumsaJack if you think you found a bug, it’s imperative that you file a detailed bug report with clear steps to reproduce in GIMP’s bug tracker: https://gitlab.gnome.org/GNOME/gimp/issues

There is not enough info in this thread to reproduce the problem.


#14

Agreed. I will open a ticket on the incident. The information is pretty detailed, and I was fortunate to work directly with Elle Stone on identifying the root cause.


#15

The funny thing is, as far as I know, ALL photo printers from the Canon Pro100 on up can take wide color profiles. It took me a while to line everything up. I use TurboPrint, and imported ProPhotoRGB into the drivers list of color profiles. My primary printer is an Epson P800. I defer to the earlier DPREVIEW topic if anyone is wondering whether or not it matters when printing, and the technical issues.


(Mica) #16

That thread is a mess and I wasn’t able to separate any signal from the noise.

I have an Espon P600. :slight_smile:


#17

The P600 is an awesome printer…AND you can go with 3rd party inks for lower cost (if you want to).

Try http://www.digitaldog.net/ for a better signal/noise ratio.