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

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

On Wed, Nov 19, 2014 at 9:28 PM, Elle Stone
<ellestone ninedegreesbelow com> wrote:
> > On Wed, Nov 19, 2014 at 7:31 PM, Elle Stone
> > <ellestone ninedegreesbelow com> wrote a lot of text that has been
> > trimmed away...
>
> Hmm.
>
> I worked hard to explain why even for chomaticitiy independent editing
> operations the RGB data shouldn't be converted to unbounded sRGB.
>
> You dismissed my efforts with "Elle Stone wrote a lot of text that has been
> trimmed away..."

I think it is too early to productively discuss implementation details
in GEGL, and therefore choose to focus on things that are *not*
implementation details.

Thankfully you no longer seem to disagree with the general direction
of the babl roadmap as can be seen in your reference to how the
architecture of babl/GEGL goes beyond traditional ICC RGB editing,
encompasses HDR.

There is much work to be done in babl – by someone; not neccesarily me
– before it is possible to experiment with different approaches. When
we can profile running code, see what the CPU is busy doing most of
the time and then spend time refactoring unneccesary conversions away.
I have even speculated and pointed out likely complications for some
of the chromaticity independent operations when *different* user:RGBs
are to be composited. To repeat an earlier remark on one of the other
points, there is no lists to maintain of which operations operate with
what representation – this is local to the ops. Each individual
operation within its own code specifies the data representation of
input and output data in its own implementation.

/pippin