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

[Gez <listas ohweb com ar>]

El lun, 17-11-2014 a las 21:19 -0500, Michael Henning escribió:
> On Mon, Nov 17, 2014 at 8:48 PM, Gez <listas ohweb com ar> wrote:
> > If chromaticity independent RGB operations request for bablRGB or
> > userRGB doesn't seem a mere implementation detail. I think it's a valid
> > question to ask why requesting for bablRGB when the mechanism for
> > userRGB will be available.
> >
> >
> > Could you please address that question with a straight answer?
>
> It's very likely that the processing will happen in userRGB for
> performance reasons.
>
> Nobody wants to give you a straight answer because to be honest, we
> don't know for sure. We could change our mind at any point in the
> future, and you wouldn't know without reading the code. It doesn't
> matter what space they happen in because chromaticity independent
> operations, by definition, do not care which of the spaces we pass
> them. If we do find a compelling reason to have those operations
> happen in bablRGB (performance or numerical stability, for example),
> then we reserve the right to do those operations in bablRGB. And if we
> do, then nobody will ever know the difference, other than the whopping
> three people that will ever read that section of the gegl code.
>
> Now, please explain this to me with a straight answer: Why is it so
> insanely important to know what color space an operation happens in,
> in a situation where it *by definition* does not matter, that you are
> willing to waste hours of your time and hours of developers' time
> arguing about it?

Sure.
My main concern is performance. It doesn't seem likely that
flip-flopping between pixel formats can be more performant than just
tossing the user RGB to operations.
It's already necessary for chromaticity dependent operations, so why not
just using it for EVERY RGB operation?
There are benefits: The channel data is always in the range the users
expects, color pickers pick the data the user expects, and that requires
exactly zero conversions.

Please note that my question was related ONLY to what RGB operations
take and give. If you have a compelling reason to keep an extra
representation (bablRGB) as PCS for converting to other color models and
give me channels for my processing needs, great.
But is there a compelling reason to change RGB from the RGB users choose
to something else?

Gez.

P.s.: If you think this discussion is a waste of your time and my time,
feel free to skip an answer. I don't think it's a waste of time at all,
it's developer/user interaction regarding important aspects of the tool.
Do you really think that discussing this is counterproductive?