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

["Ed ." <ej_zg hotmail com>]

Elle,

If you don't understand the difference between a design detail, and an 
implementation detail, you need to either a) go away and get to understand 
that difference; or b) stop commenting. I am neutral as to which you choose.

Ed

-----Original Message----- 
From: Elle Stone
Sent: Monday, November 17, 2014 11:52 PM
To: Mikael Magnusson
Cc: gimp-user-list gnome org ; gimp-developer-list gnome org
Subject: Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL

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

_______________________________________________
gimp-developer-list mailing list
List address:    gimp-developer-list gnome org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list