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

[Elle Stone <ellestone ninedegreesbelow com>]

On 11/19/2014 04:47 PM, Øyvind Kolås wrote:
> 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.

Whether to *ever* use unbounded sRGB chromaticities to perform edits on 
UserRGB data is NOT AN IMPLEMENTATION DETAIL.

Unbounded sRGB is a mistake, pure and simple, *unless* the data is 
intended by the USER to be HDR sRGB data.

In case you don't understand this, HDR sRGB data is still *bounded* by 
the sRGB xy chromaticities. It's only unbounded along the Y axis. There 
are NO negative channel values in HDR sRGB data unless the *user* 
chooses to do something odd, in which case the *user* is responsible for 
fixing the results.

Converting a display-referred wider gamut image to unbounded sRGB 
doesn't magically produce HDR data. It just creates a mess that will 
require a bunch of onerous implementation details to straighten out.

There is *no* point in *ever* editing UserRGB data using sRGB 
chromaticities. You can call all the shenanigans that would be required 
to straighten out the resulting mess "implementation details" if you 
want. But it's still a mistake to edit UserRGB data using ANY 
chromaticities not of the user's choosing.

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

The ONLY part of the babl/GEGL architecture I've ever disagreed with is 
your desire to force UserRGB to be re-encoded using sRGB chromaticities.

Other than unbounded sRGB, what you've been trying to do is *brilliant*.

Even brilliant people sometimes have ideas that turn out to be not so great.

> There is much work to be done in babl – by someone; not neccesarily me
> – before it is possible to experiment with different approaches.

You don't need to experiment with vs not converting UserRGB to unbounded 
sRGB.

Converting UserRGB to chromaticities not of the user's choosing is a 
mistake. All it does is create unnecessary complications.

You shouldn't be trying to control what RGB working space the user is 
allowed to use to edit the user's own RGB data.

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

When the user wants to composite images together, the only thing you can 
*legitimately* do is let the *user* decide what RGB working space to use 
to composite the images.

If you try to *dictate* the RGB working space for compositing the user's 
images, you are making a great big fat HUGE mistake. In fact you are 
making *exactly* the same mistake as forcing editing of UserRGB data to 
be done using sRGB chromaticities, except in cases where the *user* 
really intends the data to be sRGB data.

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

If each developer decides on his own whether to use unbounded sRGB 
chromaticities for any given operation, together the developers are 
creating an ad hoc list. Playing with semantics to make it sound like 
"there is no list" is not helpful. It's just throwing chaff into the air.

Could you *please* abandon the entirely misguided notion of forcing 
UserRGB data to be edited using sRGB chromaticities or any other 
chromaticities not of the user's choosing?

>
> /pippin

Elle