[Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?

[Elle Stone <l elle stone gmail com>]

Why does /babl/babl/util.h provide functions that transforms back and
forth between linear gamma TRC and the regular sRGB TRC? I'm sure
there is a reason, but the reason is not apparent to me.

Why does the /babl/babl/util.h code get executed from fast-float.c,
float.c, model-rgb.c, model-gray.c, and several other files, resulting
in endlessly performed conversions between linear and regular sRGB TRC
in the background of all image processing?

That conversion from linear gamma to the sRGB tone response curve and
back gets executed literally hundreds of thousands of time, every time
you do anything at all using Gimp.

For example, open a 300px by 200px image file - functions that call
the functions in util.h get executed over a million times (printf
statements to konsole terminal, with scrollback set to unlimited, save
as text file, open with kate, see how many lines).

Convert that small image to another color space, another million and a
half times functions that call the functions in util.h get executed.
Use curves, generate a thumbnail, do anything at all, more executions.

And yet replacing the code with code that says "value_in=value_out"
doesn't seem to change the way Gimp works at all, except for the
better:

*my lcms2 high bit depth color conversion code works
*16-bit tiffs open without the erroneous "gamma 2.2 correction" being applied
*the weird "gamma=0.45" gegl blurring error that I reported doesn't
happen when you blur a linear gamma high bit depth image.

I suspect several other weird gamma 2.2/0.45 errors also might be
related to the babl/babl/util.h functions.

The only possible rationale that I can see for constant conversions
back and forth between linear gamma and sRGB "almost gamma 2.2" TRC
would be if Gimp expects that ALL high bit depth images have an
embedded profile that has the sRGB TRC, and converts to linear gamma
for processing, then back to the sRGB TRC for some other reason that I
haven't been able to imagine.

But in point of fact, ProPhotoRGB has a gamma=1.8 TRC, lookup table
profiles can have very peculiar TRCs, ECI RGB and the LStar profiles
have the LStar TRC, AppleRGB has gamma=1.8 TRC, BetaRGB and many other
common working spaces, including "simplified" sRGB, have a true
gamma=2.2 TRC. Custom working spaces and camera input profiles can
have other diverse TRCs. Monitor profiles do *not* always have the
sRGB TRC. Some monitor profiles aren't even matrix profiles. This
diversity of TRCs is handled quite well by using LCMS to convert from
one color space to another.

Respectfully, with kindest regards, and also with ever-increasing curiosity,
Elle Stone

(If anyone wants to try my lcms2 high bit depth color conversion
plug-in, here's the download link, with instructions for compiling:
http://ninedegreesbelow.com/temp/gimp-lcms-6.html)