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

[Øyvind Kolås <pippin gimp org>]

I'll only reply to the question in the topic, repeating quite a bit of
the information I put in a write up two weeks ago:
http://gimp.1065349.n5.nabble.com/GIMP-GEGL-storage-precision-and-color-management-td34899.html

When operating in 8bit precision is that a GEGL powered GIMP assumes
that 8bit precision data is stored with sRGB gamma (this will probably
be changed to apply to 16bit integer as well), data with higher
bit-depths are stored with a linear gamma ramp in the layer buffers.

The working space of the layer modes currently used by GIMP are
implemented with sRGB gamma based compositing, thus for higher
bit-depth data - we must convert from linear to the sRGB working space
- perhaps go back to linear for some other operation, and in most
cases we convert back to 8bit sRGB for display (with proper color
management we'd go from higher bit-depth to the displays ICC profile
or similar). All these legacy 8bit layer modes are scheduled for
replacement with operations working in linear light (linear gamma) -
at that stage a lot of conversions back and forth (in floating point)
will be avoided.

Importing 8bit or 16bit images that do not contain sRGB data - should
result in precision promotion to probably 32bit floating point, where
the data can be well represented ... pending a _potential_ conversion
back to the source ICC profile. Note that babl's built in floating
point representations have unbounded gamuts thus can represent all of
sRGB / ProRGB / AdobeRGB and data with other 8bit profiles. Using the
sRGB for 8bit and 16bit integer precisions means that (web destined)
JPG and 8bit/16bit PNGs without associated profiles should be possible
to directly manipulate.

/Ø