Re: [Gimp-developer] Missing from the roadmap

[Elle Stone <ellestone ninedegreesbelow com>]

On 01/12/2016 01:26 AM, Sven Claussner wrote:
> - What exactly means 'supporting gamma-encodings other than the sRGB
> TRC' for intense GIMP users (artists and scientists)?

On the one hand, one goal for high bit depth GIMP is to make it easy for 
users to produce radiometrically correct editing results without having 
to know a lot (or anything) about color management, color science, and 
the mathematics of editing algorithms.

This important goal has been implemented pretty well (a handful of 
editing operations still use perceptually uniform RGB when they should 
use linearized RGB, and vice versa).

On the other hand, intense GIMP users - that is GIMP users who do have a 
working understanding of color management, color science, and the 
mathematics of editing algorithms - need control over their RGB working 
space primaries and TRC.

Control over the TRC:

The following bug report: 
https://bugzilla.gnome.org/show_bug.cgi?id=758001 provides a partial 
list of reasons why some users will want complete control over the TRC 
that's used to encode their RGB data. This bug report requests a GIMP 
GUI option to completely disable the babl code that linearizes the sRGB TRC.

A user option to disable the babl flips would go a long way towards 
making GIMP 2.10/3.0 much more friendly to intense users, and could 
probably be implemented more easily than providing full support for 
arbitrary user-chosen TRCs.

Control over the RGB primaries:

sRGB has a very small color gamut. Full support for arbitrary 
user-chosen RGB working spaces for babl/GEGL/GIMP might not happen very 
quickly, rather might take several years.

In the meantime, having at least one hard-coded wider gamut RGB working 
space made available through the GIMP UI would go a long way towards 
making GIMP 2.10/3.0 more friendly to intense users. Rec.2020 or ACEScg 
would both be excellent choices. Both of these color spaces are widely 
used by people working with VFX/CGI/Film, and both seem to produce 
better editing results than the print-based/Adobe-centric ProPhotoRGB:

http://colour-science.org/posts/about-rgb-colourspace-models-performance/
https://www.freelists.org/post/argyllcms/White-Point,45.

I would recommend Rec.2020 over ACEScg because ACEScg uses an imaginary 
primary.

Hard-coded RGB working spaces for GIMP would be nice to have:

Even if high bit depth GIMP already provided support for arbitrary 
user-chosen RGB working spaces, a selection of hard-coded built-in RGB 
working spaces is a solution to a problem that I believe Pippin 
mentioned awhile back: There are an awful lot of poorly-made RGB working 
space ICC profiles floating around out there. Providing users with a 
small selection of well-chosen and properly made built-in RGB working 
spaces seems to me to be a good thing to do. So providing at least one 
wider gamut RGB working space for GIMP 2.10/3.0 wouldn't be wasted 
coding effort.

Elle