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

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


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.

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?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]