Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL

[Elle Stone <ellestone ninedegreesbelow com>]

On 11/20/2014 05:17 AM, Øyvind Kolås wrote:
> On Thu, Nov 20, 2014 at 9:42 AM, Elle Stone
> <ellestone ninedegreesbelow com> wrote:
> > Using unbounded sRGB as a universal color space for image editing is a
> > really bad idea
>
> There has been no plan for using unbounded sRGB as a universal color
> space in GEGL, not since the introduction of a target-space in April
> in the plans, these days called userRGB in the discussion.

Yes, you are correct. In April we did agree that some editing operations 
might require being done in the target space, now called UserRGB.

Thankfully we have moved on to the question of whether *any* UserRGB 
editing ops should be done using sRGB chromaticities.

My article "Using unbounded sRGB as a universal color space for image 
editing is a really bad idea" isn't aimed specifically at GIMP. It's 
aimed at the notion of using a universal RGB working space.

Other software developers besides babl/GEGL/GIMP have contemplated using 
unbounded sRGB for all editing.

Some of the VFX people contemplated using ACES as a universal RGB 
working space. One look at multiplication and they gave that up.

Lightroom uses ProPhotoRGB as a universal RGB working space. Some of the 
free/libre raw processors also use ProPhotoRGB as a universal RGB 
working space. Adobe would like everyone to think ProPhotoRGB is the 
ultimate RGB working space for interpolated camera raw files, but that's 
just not true.

> The roadmap is a plan for how to achieve these things as smoothly and
> with as little unexpected work as possible. If someone has been
> working on the babl part of that roadmap and have a version of babl
> with the planned capabilities (I don't). It would be possible to use
> that new babl with current GEGL without the behavior of GEGL changing.
> Then the GEGL side of the work will start, first moving defintely
> chromaticity dependent ops to userRGB, as well as some chromaticity
> independent ops,

If babl formats for UserRGB are defined and made available to GEGL to 
use, then there is no rational reason for *any* GEGL/GIMP RGB editing 
operations to use sRGB chromaticities instead of UserRGB chromaticities. 
Just do a wholesale find and replace and be done with it. That way there 
are no unnecessary transforms to the sRGB chromaticities and there's no 
chance that the developers will decide "operation X" is chromaticity 
independent when really it's chromaticity dependent.

The only complication with "find and replace" is the handful of "can't 
be generalized" editing operations, plus whatever device-based code you 
want to keep around.

All such color-space-specific code needs to be labelled in the GIMP UI 
so the user doesn't use the op without understanding what they are 
getting into. Right now GIMP users can merrily use NTSC-based and sRGB 
device-based editing operations regardless of what color space they are 
really in, with no UI notification.

I tried to locate all such code to help make fixing the problem of 
color-space-specific code easier: 
http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html

> it is also likely that *some* operations/tasks
> continue using the PCS, which is also a linear RGB,

If you want to convert from UserRGB to XYZ to unbounded sRGB to XYZ to 
LAB, etc, because for whatever reason it might be more efficient to 
concantenate and store a UserRGB to sRGB transform than to generalize 
the code that converts from UserRGB to XYZ and on LAB, that's not going 
to cause any problems. But the distinction between device-based sRGB and 
ICC profile illuminant-adapted sRGB does need to be reflected in the 
babl code.

> the user of an
> application like GIMP would neither know or be affected – this is what
> we are stating will be an implementation detail.

The user will be affected if the devs mistakenly decide that a 
chromaticity dependent RGB op really is a chromaticity independent RGB 
op. And the devs will need to add new code that deals with complications 
caused by extraneous and unnecessary conversions to unbounded sRGB and back.

There's no reason to saddle the devs with trying to make this kind of 
coding distinction, when the CI and CD ops can both be done using 
UserRGB chromaticities.

> The roadmap as planned is a roadmap for babl, which includes some bits
> about changes in GEGL. The changes in GIMP, following things changing
> in babl and GEGL are, like the details of decisions we will be making
> in the GEGL stages, out of scope for planning how we add the needed
> capabilities to babl.

The babl functions that use Y to paint on a mask and to make grayscale 
masks really do need to be generalized to use UserRGB Y, or else there 
needs to be side by side functions. Otherwise GIMP layer masks will only 
be correct for sRGB images.

> /pippin

Elle