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
