[Gimp-developer] GIMP needs a new color management person, take 2

[Elle Stone <ellestone ninedegreesbelow com>]

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