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

[Elle Stone <ellestone ninedegreesbelow com>]

On 11/17/2014 05:41 PM, Mikael Magnusson wrote:
> On Mon, Nov 17, 2014 at 10:03 PM, Elle Stone
> <ellestone ninedegreesbelow com> wrote:
> > On 11/17/2014 10:46 AM, Simon Budig wrote:

> > > I don't think that this is decided yet, I actually consider it unlikely
> > > at the moment. I think it might be more likely to have it sitting in
> > > memory as userRGB.But again, this is an implementation detail, where I
> > > assume that the floating point math is sufficiently precise to avoid
> > > visible rounding errors.
> >
> >
> > This is not just an implementation detail. The user has the right to control
> > what RGB working space is used when performing RGB edits on the user's own
> > RGB data.
>
> The above two things are implementation details as Simon said.

There is no reason to *store* the image using the sRGB chromaticities 
unless you also intend to *edit* the image using the sRGB 
chromaticities, or else if you intend to convert the image to unbounded 
sRGB and then to Y or else to XYZ and then maybe to CIELAB.

So yes, the question of how you *store* the user's RGB data really does 
matter. It's not just an implementation detail.

Unless maybe you think it's reasonable to randomly re-encode the user's 
RGB data using the sRGB chromaticities "just because you can".

> If you
> don't understand this, then please don't write long articles full of
> misinformation that get widely quoted.Your answers suggest you didn't
> even understand what he said.

I do understand what Simon said. And I'm waiting for Pippin to clarify 
whether *Pippin* intends that images will be converted to unbounded sRGB 
before performing chromaticity independent RGB editing operations.

If Pippin's answer is "yes, the image will be converted to unbounded 
sRGB for chromaticity independent RGB editing operations", I want to ask 
him why. There are many bad consequences of doing this. So if Pippin's 
answer is "yes", there must be some advantages that I don't see.

Pippin and Jon Nordby seem to be saying different things. Three times 
Nordby has said that the image won't be converted to sRGB except for the 
handful of editing operations that really can't be generalized. (As an 
aside, in these cases, I hope a UI warning will be provided so the user 
knows what's going on and can exercise the right to not use the affected 
operation.)

And three times Pippin has made statements that seem to directly 
contradict Jon Nordby.

> Your argument is like saying it matters
> if you store an integer in decimal or binary, and doing anything else
> than the user input is definitely wrong, because there is no longer
> any way to display it in this format.

Umm, could you untangle your analogy? Because all of sudden the integer 
encodings became undisplayable images.

I assure you that if you add integers encoded using binary, while 
thinking you are adding decimal numbers, you will almost certainly get 
results that diverge from what you expect, adding 0+1 being an obvious 
exception.

And if you composite colors thinking you are compositing in UserRGB, 
when really you are compositing in sRGB, likewise you are very likely to 
get results other than what you expected.

> Gegl stores pixels in memory in some format, it knows what format it
> used.

babl and GEGL do communicate with each other as to what format the data 
is in and what format is needed next. Are you trying to say something else?

> Gimp can display/edit pixels in some color space (specified by
> the user).

Well, this really is the question: according to Pippin, what color space 
chromaticities will be used for chromaticity independent RGB editing 
operations? UserRGB's or sRGB's?

> Gimp asks Gegl for pixels saying what colorspace it wants.

Well, sometimes GIMP specifies the babl format and sometimes GEGL 
specifies the babl format. The question is whether for RGB editing 
operations the format so specified will ever be unbounded sRGB. Each 
time Nordby seems to say no, Pippin seems to say yes.

> Gegl presents the pixels to Gimp.All is well. It doesn't matter how
> the pixels are stored.

Again, there is no reason to re-encode and *store* the pixels using the 
sRGB chromaticities *unless* there is an intention to *use* the 
re-encoded information for some purpose other than storing the pixels.

As GIMP is an image editor, presumably that purpose would be for 
*editing*, and the format the pixels are in for editing does matter a 
great deal.

Elle