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:
I would recommend Rec.2020 over ACEScg because ACEScg uses an imaginary
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
gimp-developer-list mailing list
List address: firstname.lastname@example.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list