# Re: [Gimp-developer] [Gegl-developer] babl roadmap

• From: Simon Budig <simon budig de>
• To: gimp-developer-list gnome org
• Subject: Re: [Gimp-developer] [Gegl-developer] babl roadmap
• Date: Tue, 14 Oct 2014 14:50:49 +0200

```Elle Stone (ellestone ninedegreesbelow com) wrote:
```
```On 10/14/2014 07:52 AM, Øyvind Kolås wrote:
```
```On Tue, Oct 14, 2014 at 1:34 PM, Elle Stone
<ellestone ninedegreesbelow com> wrote:
```
```
```
```To convert images to and from unbounded linear gamma sRGB, you MUST pass
through XYZ. XYZ is the PCS.
```
```
I remind you that linear RGB spaces are a single matrix multiplication
away from other linear RGB spaces and XYZ.
```
```
Matrix conversions between RGB working spaces can be concantenated. That
concantenation goes through XYZ. It almost sounds like you want to obscure
this fundamental distinction between XYZ and unbounded linear gamma sRGB.
```
```
for conversions between RGB working spaces there is no fundamental
distinction between XYZ and unbounded linear gamma sRGB.

In mathematical terms both of these span up a three dimensional vector
space (describing color) and the only difference is that they use
different basis vectors.

You can *easily* describe conversions between different RGB primaries
with ulgsRGB as the connecting space (completely replacing XYZ). You
would get a different set of transformation matrices of course.

XYZ is something that has a special role for all of the non-RGB color
spaces Lab, xyY, Luv etc, as well as operations like chromatic
adaptation. Hence it makes sense to use it also as the connecting space
for the different RGB primaries.

```
```Are you planning on converting non-sRGB images to unbounded linear gamma
sRGB? Yes or no?
```
```
For pixel storage we will use whatever fits our needs, it does not make
sense at this point to specify this.

This might be a Lab-buffer with a cache in front of it that has the
pixels converted to sRGB. Or a Adobe-RGB-Buffer without a cache. Or
unbounded linear gamma sRGB. Or whatever.

The important thing is, that gegl/babl provides the means to access these
data in whatever format is needed by the operation that is happening. A
brightness-invert function might request the data in Lab, do the
inversion on the L channel and feed the results back as Lab to the
gegl/babl infrastructure, which will process it to provide the next
operation in the graph with the input format the next operation needs.

```
```If yes, are you intending that at least some editing will be done on the
image while it's encoded using sRGB primaries? Yes or no?
```
```
That totally depends on the editing-operation in question and is
orthogonal to the pixel memory storage format.

Bye,
Simon
--
simon budig de              http://simon.budig.de/
```