You all have created an amazing RGB image editor. But proper color management has always taken a back seat. GIMP users have requested better color management and CMYK support for a long time now. You could have taken full working color management code from Cinepaint or Krita years ago, but you didn't. Instead you tried to reinvent the color management wheel with unbounded sRGB as a universal RGB working space, which apparently nobody bothered to test to see if it actually worked (it doesn't:
http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html). Not too long ago one of the devs stated on IRC that GIMP 2.10 would use unbounded sRGB, leaving me with the impression that the several months of hard work that I spent documenting problems with unbounded sRGB as a universal working space were completely wasted.

The GIMP devs need to rid the babl/GEGL/GIMP code of all traces of "only sRGB" coding
(http://ninedegreesbelow.com/bug-reports/gimp-hard-coded-sRGB.html). But other software that uses GEGL needs babl to only use the sRGB primaries and TRC until someone finds the time to write new code to exist alongside the "sRGB only" babl code. So GIMP color management is taking a backseat to other software that uses babl/GEGL.

A long time ago I wrote code for the LCMS plugin that enables GIMP to do RGB/grayscale conversions, as a preliminary step towards figuring out how to do RGB/CMYK conversions (not saying I would have succeeded, good CMYK code probably needs to be written by someone who actually uses CMYK). But then the developers announced that the LCMS code was going to be moved to GEGL (still hasn't happened, thankfully) and I lost interest in working on the LCMS code. GIMP should not let GEGL handle color management as GEGL is used in other programs and GIMP would always have to compete with the color management needs of those other programs.

A Google summer of code student wrote fourier code for GEGL, and it can't be used because of GEGL license issues. This is just wrong. GIMP needs fourier code for proper lens blur (http://ninedegreesbelow.com/bug-reports/camera-fourier-gaussian-blurs-compared.html; Krita has proper lens blur; GIMP does not). GIMP shouldn't be hampered by GEGL licensing.

Right now for OpenEXR images, the image is opened, it's assumed to be a linear gamma sRGB image (really bad assumption), the sRGB TRC is applied, and the GIMP built-in sRGB profile is assigned (https://bugzilla.gnome.org/show_bug.cgi?id=316646). This is laughably wrong. Instead of removing the coding step that applies the sRGB TRC and giving the user a chance to *assign* the right ICC profile (I supplied a patch to do just that), the plan as discussed on IRC and in the bug report seems to be to extend the "auto sRGB TRC" assumption right into the LCMS plugin itself, which is a mind-boggling wrong thing to do.

My apologies for double-posting. I didn't mean this to be a reply to the thread on user options to choose linear vs perceptual RGB. So I'm posting again as a separate thread. Maybe it's against protocol, but I find I don't care much.

I use hacked versions of high bit depth GIMP for image editing - four of them, one for each color space that I use - and I'm very much enjoying finally being able to edit high bit depth images with masks and layers using free/libre software (other than having excellent color management, Cinepaint turned out to be a joke; Krita is aimed at digital artists and until recently flat-out wouldn't run on my system, but now runs just fine, thank you Krita devs!).

In my hacked versions of babl/GEGL/GIMP the babl flips are disabled, with LCH blend modes patched in
(http://ninedegreesbelow.com/photography/gimp-lch-blend-modes.html), and with all the hard-coded sRGB values replaced by the Y and XYZ values that are appropriate to my preferred RGB working spaces (http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html#wider-gamut-working-space-workarounds).

I wish that having proper GIMP RGB color management didn't mean hacking the code for each and every color space I want to use, but that's the current situation. I wish I had the coding skills to recode babl/GEGL/GIMP color management to give the user control over her RGB data and to not use hard-coded sRGB, but I don't. I wish the babl/GEGL/GIMP devs could be persuaded to use the babl flips to empower GIMP users than to limit what users are allowed to do with their own RGB data, but I don't have much hope for that happening. I wish I were rich and could hire developers to fork GIMP and do color management the right way, but I'm not.

I'm very glad to have had the chance to work with you all for the last couple of years. For various reasons I've decided to bow out from further active participation in GIMP development, though I still plan to make bug reports and submit the occasional patch. If anyone has a color management question that I might be able to help with, send me a private email (I'm unsubscribing from the list). And if anyone wants to fork GIMP, send me an email because I might want to lend a hand.

Best, Elle Stone

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