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

[Elle Stone <ellestone ninedegreesbelow com>]

On 11/16/2014 05:18 PM, Øyvind Kolås wrote:
> On Sun, Nov 16, 2014 at 9:01 PM, Elle Stone
> <ellestone ninedegreesbelow com> wrote:
> > Do you understand that when I say that Multiply is a chromaticity-dependent
> > editing operation, I don't just mean the Multiply layer blend mode? that in
> > fact *all* editing operations that use multiplication or division are
> > chromaticity dependent, regardless of whether the colors are *in* gamut or
> > *out* of gamut with respect to the very small bounded sRGB color gamut?
> >
> > The exception to "all", of course, is when multiplying or dividing by black,
> > gray, or white.
>
> Yes I do understand that

OK, thanks! for confirming. I was afraid my phrasing might have obscured 
an important point.

> > 1. Do you agree or disagree that for *all* chromaticity dependentediting
> > operations, the *user* should be in control of which RGBchromaticities
> > are used to perform the operation?
>
> That is the point of adding more, and named, RGB families to babl.

> > 2. Do you agree or disagree that for chromaticity *in*depedent editing
> > operations (for example, and assuming linearized RGB: adding, scaling,
> > gaussian blur, etc), the same results (same XYZ values) are obtained
> > whether the operation is done in the user's chosen RGB working space or in
> > unbounded sRGB?
>
> I do;

So it appears that we agree on the following, yes?

1. The user's chosen RGB working space chromaticities should be used for 
performing all chromaticity dependent RGB editing operations.

2. For chromaticity independent RGB editing operations, the same XYZ 
values are obtained regardless of whether the operation is performed 
using the user's chosen RGB working space chromaticities or after 
converting the image to unbounded sRGB.

> > Somewhat switching gears, the revised babl roadmap
> > (https://git.gnome.org/browse/babl/tree/docs/roadmap.txt) says:
>
> The plan in roadmap hasn't really changed since mid-april[1],

I agree with you that the plan you outlined in April is pretty much the 
same plan that I think you are outlining now. In April you did agree 
that some RGB editing operations don't work in unbounded sRGB. You said 
that using "targetRGB" (ie the user's chosen RGB working space, UserRGB, 
"bar"RGB, etc) would be one solution and that another solution would be 
converting to CIELAB to do the operation.

Putting aside coding considerations that might affect other software 
that uses babl and GEGL, here's my understanding of your current plan 
for babl/GEGL/GIMP:

1. Upon opening an image, the image will be converted to unbounded sRGB.

2. For all chromaticity dependent RGB editing operations:
   * Either the image will be re-encoded using the user's chosen RGB 
working space chromaticities, and then the operation will be performed.
   * Or else the image will be converted to CIELAB and then the 
operation will be performed.

3. For all chromaticity *in*dependent RGB editing operations, the image 
will be converted to unbounded sRGB for processing.

4. When converting to XYZ/CIELAB/etc, the image will first be converted 
to unbounded sRGB.

5. The GEGL developers will specify on an "operation by operation" basis 
whether the operation requires being encoded using UserRGB/Y/etc, or 
unbounded sRGB/Y/etc, or CIELAB as a substitute for chromaticity 
dependent RGB processing, or etc.

As an important note, depending on the last operation that was done, the 
image might already be encoded using the GEGL-operation-specified 
format, in which case a conversion to that format is not needed.

Are the above five points (and note) an accurate summary of your current 
plan for babl/GEGL/GIMP?

I have a couple of followup questions, but there's no point in asking 
them if I don't have a clear understanding of what your current plan 
really is. I think we've both been rightly accused of talking right past 
each other.

> 1: the only change in plans since then (and that changed occured
> before roadmap.txt was started), was abandoning the plan to do
> conversions between bablRGB and userRGBs in babl using LCMS2; and
> instead do those conversions directly ourselves in babl; a change
> without impact on how babl will be used by GEGL (and GIMP).

Using babl instead of LCMS2 to do ICC profile matrix conversions makes 
perfect sense, being faster and potentially a lot more accurate 
(https://mail.gnome.org/archives/gimp-developer-list/2014-October/msg00093.html).

> /pippin

Elle