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
_______________________________________________
gegl-developer-list mailing list
List address: gegl-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
