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

El lun, 17-11-2014 a las 23:41 +0100, Mikael Magnusson escribió:

The above two things are implementation details as Simon said. 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. 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.

Gegl stores pixels in memory in some format, it knows what format it
used. Gimp can display/edit pixels in some color space (specified by
the user). Gimp asks Gegl for pixels saying what colorspace it wants.
Gegl presents the pixels to Gimp. All is well. It doesn't matter how
the pixels are stored.

I think I have at this point a reasonable grasp of what's the plan here
and that unbounded sRGB is intended a just one representation of the
many possible with babl (and that its primary function is to be used as
a PCS)-

I also understand that chromaticity dependent operations will use

However, and this is what Elle is asking and nobody seems to understand,
the question is if bablRGB is still going to be used as the RGB space
for all the chromaticity independent operations and if that's a yes,
then WHY.
Is it just to spare one single matrix transform in case the buffer is
not available in userRGB?

And yes, jonnor said something that seems to contradict pippin if that's
the case: in the future RGB operations that now ask for bablRGB should
ask for userRGB instead.

That of course doesn't take bablRGB out of the picture (it would still
would be used as PCS), but means specifically that operations won't be
fed anymore with unbounded sRGB but user defined RGB.

When Elle says "converting to unbounded sRGB", she's referring to what
babl will do when an operation requests for bablRGB.
(We know it's not a forced conversion at the beginning of the pipe, and
the GEGL tree can keep different representations for the buffer).

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?


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