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

[Øyvind Kolås <pippin gimp org>]

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 – The babl roadmap being incomplete/leaving
room for interpretation is on purpose – what is stated there is the
minimum roadmap bringing us towards a situation where such details
makes sense to decide upon. Some operations we might change to not be
chromaticity dependent in this way (for instance using CIE Lab or Lch)
but for most of them the change will be using a babl-format specifiers
like "target:RGBA" and "target:R'G'B'" instead of un-prefixed format
specifiers like now, which in the future will be synonyms for
"sRGB:RGBA" etc.

> 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],
revisions to the file has been integrating various bits lost in the
mailinglist threads. The last revisions was to add what has been
stated before in gimp-developer about single-precision floating point
and accumulated rounding errors – since the issue was brought up here.

> "Once a format has been resolved using babl_format(babl, "bar:RGBA float")
> the returned pointer would refer to the babl context that looked up "bar"'s
> definition of bar. This . . . allows rigging up a situation where the user
> has control over the RGB space used for chromaticity dependent operations."
>
> In light of the revised roadmap and the above list of chromaticity dependent
> editing operations, I have two more questions. Again, I'm trying to
> establish common ground for communication, or at least clarify where we
> disagree.
>
> 1. Do you agree or disagree that for *all* chromaticity dependent editing
> operations, the *user* should be in control of which RGB chromaticities are
> used to perform the operation?

That is the point of adding more, and named, RGB families to babl.

Chromaticity dependent operations are the operations where we would
use userRGB instead of bablRGB – effectively it being the way for the
developer to say that for this operation the users chosen format
should be used. using user:Y user:Y' user:R'G'B' and user:RGB would be
different ways the op developer can request pixel formats based on
this user choice; when the op developer knows it should (or should
not) be linear of perceptual data. But also note that while in GIMPs
use of babl/GEGL, there might only be one such user family of pixel
formats controllable in one location of the UI, in the general flow
based computing model of GEGL one might expect a single configured
processing graph to have multiple userRGBs for photos coming from
different sources.

> 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; and if there wasn't any chromaticity dependent operations – a
single "RGB family" like bablRGB would be sufficient – You convinced
us to abandon that plan in april. If a GEGL graph contains multiple
different userRGBs source buffers, chromaticity independent
compositing operations compositing two buffers with different RGB
chromaticities need to be converted to the same linear RGB. Initially
this will be bablRGB; later – depending on profiling and time for
doing it – we might end up making such compositing produce output in
the same RGB family as the input buffer and convert the aux buffer to
the same.

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).

/pippin