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

[Simon Budig <simon budig de>]

Hi Elle.

The following is my understanding, when pippin answers his answers have
more authority than mine.

Elle Stone (ellestone ninedegreesbelow com) wrote:
> Putting aside coding considerations that might affect other software that
> uses babl and GEGL, here's my understanding of your current plan for
> babl/GEGL/GIMP:

A slight preface here. I don't consider it important to focus on the
*storage* of the pixel data, as in the actual bulk memory for the pixel
data.

The important part is, that the data is available to the operations in
the format they request upon request. If that is in memory already
pre-converted or if that gets converted on the fly is an implementation
detail.

> 1. Upon opening an image, the image will be converted to unbounded sRGB.

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.

> 2. For all chromaticity dependent RGB editing operations:
>    * Either the image will be re-encoded using the user's chosen RGB working
> space chromaticities, and then the operation will be performed.
>    * Or else the image will be converted to CIELAB and then the operation
> will be performed.

Conceptually the image won't be converted as a whole. A
pixel-data-flow-graph will be set up that considers the region of
interest.

For all chromaticity dependent RGB editing operations the pixels will be
re-encoded in the format the operations requests. Which most likely will
be userRGB. And the re-encoding-step can be a NOP, if the previous node
in the operations tree already provides the requested format.

> 3. For all chromaticity *in*dependent RGB editing operations, the image will
> be converted to unbounded sRGB for processing.

For all chromaticity *in*dependent RGB editing operations the pixels will be
converted to the format the operations requests. Which most likely will
0e sRGB or XYZ. And the re-encoding-step can be a NOP, if the previous node
in the operations tree already provides the requested format.

(Sorry for repeating, but this is an important point: in a given image
context "userRGB" really is not conceptually different from sRGB or XYZ,
it gets slightly more complicated when two images with different
user chromaticies are to be combined.)

> 4. When converting to XYZ/CIELAB/etc, the image will first be converted to
> unbounded sRGB.

Not necessarily. If specific userRGB to XYZ/whatever transforms are
available to babl it will make use of them. This will likely be the case
for e.g. AdobeRGB.

> 5. The GEGL developers will specify on an "operation by operation" basis
> whether the operation requires being encoded using UserRGB/Y/etc, or
> unbounded sRGB/Y/etc, or CIELAB as a substitute for chromaticity dependent
> RGB processing, or etc.

It probably will be specified within the implementation. I.e. there
won't be a pre-existing separate document with a list for each
individual operation.

However there might be such a document generated from the implementation.

> As an important note, depending on the last operation that was done, the
> image might already be encoded using the GEGL-operation-specified format, in
> which case a conversion to that format is not needed.

Yes, but it is important to keep in mind that we don't sequentially
apply one operation after each other, with image-in-memory-steps
inbetween. We build a graph of connected operations, where the
connections between the nodes will be negotiating the resp. pixel
formats. *Then* the pixel data will be fed from the sources into the
graph, flow through the graph, have the operations operate on them,
potentially converting them to the negotiated pixel formats and finally
get sunk into the output (e.g. the node painting into the image view).

Bye,
        Simon

-- 
              simon budig de              http://simon.budig.de/