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

[Elle Stone <l elle stone gmail com>]

On 8/30/12, Øyvind Kolås <pippin gimp org> wrote:
> 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.


But this is a ***very wrong*** assumption. Many people work with 8-bit
images that are NOT sRGB images and DON'T use the sRGB TRC (AppleRGB,
ColorMatch, LStar, etc).

And many, many more people work with 16-bit images that are NOT sRGB
images and DON'T use the sRGB TRC (ProPhoto, Beta, WideGamut, etc).


> 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.

In point of fact the extended scRGB does NOT cover all of the
ProPhotoRGB color space or the CIE 1931 color space. scRGB leaves out
a good chunk of the all-important greens.

Quoting from Wikipedia, which has a very nice picture that everyone
ought to go take a look at: http://en.wikipedia.org/wiki/ScRGB

"Negative numbers enables scRGB to encompass most of the CIE 1931
color space while maintaining simplicity and backward compatibility
with sRGB ***without the complexity of color management***. The cost
of maintaining compatibility with sRGB is that approximately 80% of
the scRGB color space consists of imaginary colors."

The point of scRGB is MicroSoft's and Hewlett-Packard's attempt to yet
again not deal with color management. But color management is part and
parcel of all high end image editors, and well-integrated with Linux.
So why on earth would any Linux image editor want to follow in the
MS/HP footsteps and use scRGB, with the attendant loss of ability to
represent all of the real world colors and the attendant requirement
of using very high bit depths to maintain image integrity?

If you stick with normal, well-accepted working spaces like
ProPhotoRGB and BetaRGB, you can edit using 16-bits without banding.
If you force image data into the scRGB color space, to maintain the
same degree of accuracy/lack of banding you will ***need*** to go to
32-bit/64-bit floating point, because of the way scRGB works. That is
the price you pay for having 80% of your working space occupied by
imaginary colors. That will place a huge and unnecessary overhead on
image editing with Gimp.

Right now the default babl/base/util.h DOES NOT WORK with any 16-bit
image that doesn't have the sRGB TRC. Please see this page for an
example using Gegl blurring:
http://ninedegreesbelow.com/temp/gimp29-gegl-blur-prophoto.html

My color conversion code is NOT involved in blurring, and to make
double sure, I replaced my lcms2 plug-in with the default Gimp lcms
plug-in. The Gegl blurring ONLY works with images that have the sRGB
TRC.

With increasing dismay, but still with warmest regards,
Elle Stone