Re: [Gimp-developer] New Image/Color Management option

[Elle Stone <ellestone ninedegreesbelow com>]

On 06/04/2016 05:37 PM, Øyvind Kolås wrote:
> On Sat, Jun 4, 2016 at 11:13 PM, Elle Stone
> <ellestone ninedegreesbelow com> wrote:
> > If GIMP is being developed for high end workflows as specified in the Vision
> > statement, then it's important to get input from people who actually use
> > high end workflows. Gez is exactly such a person. I think I qualify, though
> > I'm not a professional.
>
> High-end workflows doesn't have to mean that the user understands all
> details about things like color-management,

Practical, applied color management is not that complicated. Neither is 
understanding the basics of radiometrically correct editing.

A professional high end workflow by definition implies that the user 
understands the nature of the provided tools, what the tools can do and 
what the limitations are.

> some things can be handled
> automatically - note that this is not about making it impossible to do
> things; but harder to do the wrong thing.

As an experiment, I tried using default babl/GEGL/GIMP patched to use 
Rec.2020 Y and XYZ, but with the babl flips intact and using an ICC 
profile with the Rec20202 primaries and the sRGB TRC.

I had no way to know, short of looking in the code, which operations 
were being done on linearized RGB, and which on perceptually uniform RGB.

Well, sometimes it was obvious. For example GIMP by default uses 
perceptually uniform RGB for Curves and Levels, and this is 
radiometrically incorrect and produces all kinds of obvious gamma artifacts.

I know exactly when I want to use linear RGB and exactly when I want to 
use perceptually uniform RGB, as do other high end/professional users.

The babl flips take that critically important freedom of choice away 
from me.

> > I've had a small number of high end users including two bonified
> > professionals from very different fields look at both default GIMP and my
> > patched GIMP which has the babl flips disabled. Unanimously these people say
> > that there is no way they would use default GIMP because the babl flips
> > interfere with their workflow. Plus they need the option to work in wider
> > color spaces than sRGB. But they liked using my patched GIMP.
>
> > snip<
>
> > Let's be completely clear about this: These high end users and professionals
> > aren't praising  *my* coding ability or *my* vision for GIMP. I'm a terrible
> > coder and all I've done in my patched GIMP is disable the babl flips, add a
> > few extra LCH functionalities, and recently added "anyrgb".
>
> One of the important features of the "babl flips" is that they make
> gamma erros as they apply to scaling and blurring, and more go away
> see http://www.4p8.com/eric.brasseur/gamma.html GEGL code in general
> prefers using linear variants of the used RGB color-space for
> processing (and compositing).

One of the professionals who has used my patched GIMP (actually there 
were three professional that I know of, I don't usually ask people who 
send me emails what they do for a living, but sometimes they tell me 
anyway) has specifically noted that for scaling an image to a larger 
size, scaling perceptually uniform RGB can provide a smoother result. 
And the babl flips take this option away from users of default GIMP.

This points to a shortcoming in the "make all the decisions for the 
user" approach to coding: It assumes the devs know better than the users 
what is the right thing to do.

> One major short-coming of babl/GEGL
> color handling currently - as elle has pointed out, is for operations
> that multiply pixels values - like the multiply layer mode - most
> editing features in GIMP do not rely on multiplication of color
> components.

Well, actually many editing operations in GIMP are 
chromaticity-dependent, producing different results in different RGB 
working spaces, precisely because multiply itself is chromaticity-dependent.

For a list see Section B of this article:
http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html#chromaticities-matter.

For editing examples, see Section C of the same article.

For a more technical discussion, see these three articles:

Multiplying out of gamut colors in the unbounded sRGB color space 
produces meaningless results 
(http://ninedegreesbelow.com/photography/unbounded-srgb-multiply-produces-meaningless-results.html)

Color correction fails in unbounded sRGB 
(http://ninedegreesbelow.com/photography/unbounded-srgb-color-correction-fails.html)

About RGB Colourspace Models Performance 
(http://colour-science.org/posts/about-rgb-colourspace-models-performance/)

And this thread: https://www.freelists.org/post/argyllcms/White-Point,45

> At the moment things are a mix of constraints of 8bit like GIMP-2.8
> had and how closely workflows from 2.8 are reproducible in the
> development version, some features and menu options in GIMP-2.9 are
> not desirable as a finished streamlined GEGL based editing experience.

This is exactly what Gez was saying: there are constraints on GIMP 2.10 
for legacy/backward-compatibility reasons.

> After GIMP-2.10 and GIMP-3.0 get released; I hope we can see a
> significant trimming down of the UI for instance the precision menu in
> GIMP, defaulting to 32bit floating point with linear TRC (maybe with
> precision over-ridable per layer - to save memory) in addition to

It would be excellent to have default 32f *linear* *gamma* processing 
(no babl flips to perceptually uniform RGB behind the user's back and 
without their consent), preferably coupled with a "per layer/layer 
group" user option to choose a perceptually uniform TRC. Otherwise the 
user needs the option to convert to a profile with a user-chosen TRC, 
and of course the user needs this option anyway, and again with *no* 
*babl* *flips*.

If the babl flips are flipping the RGB channels back and forth between 
linear and perceptually uniform RGB without the *user* being able to 
control the encoding, this is a design decision that precludes using 
high bit depth GIMP for high end/professional workflows.


> other improvements that might break more GIMP-2.8 era assumptions and
> constraints. This is also when experimenting with filters embedded in
> the layer stack similar to adjustment layers/effect layers and more is
> on the roadmap.
>
> Elles simplified babl/GEGL with removed the TRC to/from linear
> conversions or as she calls it "babl flips" will make GIMP produce
> wrong results for scaling, blurring and more - *unless* the user has
> specifically chosen to edit in a linear RGB space; only then will
> scaling or blurring and other resampling produce correct results.

Exactly and by design. The user needs control over their RGB data.

> Another issue not dealt with by Elles approach to patching babl/GEGL
> is juggling multiple immutable different RGB formats in one process.
> GIMP can open multiple images with different ICC profiles - and we
> want users to be able to predictably view and copy/paste between
> multiple images with different profiles. How this is dealt with isn't
> certain - some ideas have gone into a babl roadmap, but the needs are
> summed up in this email.

Well, let's see how this might be handled:

First the user picks the color space for compositing the image layers 
together.

Then the user drags the layers over from other image layer stacks, and 
if the source and destination layer stacks are in different ICC profile 
color spaces, a conversion is done during the drag and drop operation 
(which Mitch already added code to make happen).

Problem solved.

Oh, if "predicatably view" means "always get the same result from all 
compositing operations", then the developer must command and enforce 
that the user can only composite in a working space that the developer 
has a priori chosen, precisely because multiply is a 
chromaticity-dependent editing operation that affects a multitude of 
editing operations and blend modes.

High end work flows absolutely require that the user be in control of 
the compositing color space.

If the consensus among the devs (the devs that control the overall 
course of GIMP development) is that GIMP is for "don't know and don't 
want to know" users, then please revise the Vision statement 
accordingly, and feel free to keep those babl flips.

Revising the Vision statement would clarify the nature of the project on 
which we are all working as a team, and perhaps some of us would choose 
to not continue participating in GIMP development. I believe this is one 
of the points that Gez was making when he said:

> And if things keep going in this direction, GIMP will end up losing the
> handful of people actually using it seriously and caring about it.
>
> Instead of focusing on imagers devs seem to be focusing on eventual
> users who only use the tool once a month for scaling some photos and
> remove red eyes or making banners for online forums.
>
> If that's the audience you care about, please amend the product vision
> so people like me can move on, since there is no future for us with
> GIMP. Eventual users and clueless people can learn. It only takes
> education.
> Aiming low with features like this only makes us, the real audience,
> want to run in the opposite direction.

Best,
Elle