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

[Elle Stone <ellestone ninedegreesbelow com>]

On 10/14/2014 08:50 AM, Simon Budig wrote:
> Elle Stone (ellestone ninedegreesbelow com) wrote:

> > 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.

Whether or not the roadmap calls for converting non-sRGB images to 
unbounded sRGB will determine what kind of code is written going forward.

In an ICC profile color-managed workflow, sRGB is just another RGB 
working space, requiring no special treatment.

The babl roadmap "sRGB as PCS/fooRGB" is a proposed solution to 
perceived problems. The problems for which "sRGB as PCS/fooRGB" might be 
a solution are things like:

*Reducing computing overhead for 8-bit sRGB image editing.
*Accomodating legacy sRGB XCF files.
*Accomodating legacy "sRGB only" file formats.

Solving legacy and 8-bit sRGB overhead problems does not require 
converting ICC profile color-managed images from fooRGB to unbounded sRGB.

> > 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

When the user opens a color-managed fooRGB image, for which *specific* 
editing operations will the image be converted to unbounded sRGB?

This isn't just an implementation detail. The answer to this question 
will determine the path for writing code going forward. To restate the 
question yet again:

Will all color-managed image editing be done using the user's chosen 
primaries, with absolutely no conversions to unbounded sRGB for image 
editing?

Or are the developers committing themselves to maintaining lists of 
which operations should be done using fooRGB primaries and which should 
be done using sRGB primaries?

With respect,
Elle Stone