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

[Elle Stone <ellestone ninedegreesbelow com>]

On 10/15/2014 08:30 AM, Øyvind Kolås wrote:
> On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone
> > When the user opens a color-managed fooRGB image, for which *specific*
> > editing operations will the image be converted to unbounded sRGB?

> If the user is putting a text-layer, which has been rendered using
> cairo and is in 8bit sRGB premultiplied alpha. The compositing of this
> with preceding data in the layer stack the babl-format of the output
> buffer of the over/normal compositing operation, as well as the data
> fetched from both buffer inputs - would likely be RaGaBaA float - if
> the two linear inputs differ.

I'm not sure why your text-layer stack example is relevant to my very 
direct and still unanswered question.

But using GIMP 2.9, I put a text-layer over a color layer, first in a 
very large linear gamma (camera-based) color space, and then in a linear 
gamma color space with the sRGB primaries.

In both color spaces, the text-rendering looked the same, even when 
magnified to 400%. Of course I used color management with a proper 
monitor profile, at 32-bit floating point precision.

Is it possible that your color management settings are awry?

Is it possible that the babl conversions between linear and perceptually 
uniform RGB are somehow messing up compositing text-layers over color 
layers? I used a modified version of babl/GEGL/GIMP in which the babl 
conversion between linear and perceptually uniform RGB are disabled.

If you are saying that 8-bit images only work with the existing babl 
code if the images are also sRGB images, then perhaps a babl bug report 
is in order. Out there in the real world, some people do edit 8-bit 
AdobeRGB1998 images, even some people who are currently using 8-bit GIMP.

If you are saying that 8-bit "premultiplied alpha" RGB data only works 
with sRGB images, again that would also seem to be a reason for filing a 
bug report against the babl code. Or at least it's a reason to warn 
people in the UI that 8-bit RGB data only works properly for sRGB images.

> At all points we know the CIE Lab or XYZ coordinates of all involved
> pixels

You don't "know" the XYZ coordinates until you actually convert from 
fooRGB to XYZ. Likewise with CIELAB. So it's not clear what the above 
sentence really means.

>  – and we aim to do as few conversions as possible
As few conversions as possible sounds like an excellent maxim for 
writing image editing software.

Whether you want to go through unbounded sRGB to get to XYZ, CIELAB, 
etc, for purposes of editing in a reference color space, is entirely 
irrelevant to RGB editing operations.

But here's a maxim for *RGB* image editing:

For RGB editing operations, don't ever, ever, ever convert color-managed 
fooRGB to unbounded sRGB.

> (never
> converting the actual data to either bablRGB or XYZ,
Does "bablRGB" mean fooRGB data that's been converted to unbounded sRGB?

> even temporarily
> - unless requested.)
Who does the requesting? The artist? Nope, the developers who write the 
code decide which color space the image data gets converted to. This 
brings us back to the main quesion:

For which specific RGB editing operations do you plan to convert the 
image from fooRGB to unbounded sRGB before performing the operation(s)?

With respect,
Elle Stone