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



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



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