[CREATE] Some questions about OpenRaster Format, Color and GEGL

[Øyvind Kolås]

On Mon, Jun 3, 2019 at 4:12 PM Jan-Peter Homann
<homann at colormanagement.de> wrote:

> 3) GEGL and Color
> Pippin, did I understood you at LGM correct, that GEGL is able to use different ICC-profiles for chunks/nodes in the GEGL tree ?
> If yes, is it correct, that OpenRaster would not be an appropriate file format for such cases?
> or, If yes, do you provide an extension the the OpenRaster format?
> If not, this was probably a missunderstanding from my side...
>
> If yes, the complexity of interactions between colormanagement and blending modes will increase massively. Photoshop still avoids this complexity by allowing only one profile per document. If any new image with a differnt colorspace (e.g. CMYK instead of RGB) or different profile (e.g. sRGB instead of AdobeRGB) will be added to an document, all image colors will concerted to actual document colorspace.

GEGL doesn't make use of OpenRaster, but there is nothing in the
design of OpenRaster that is contrary to internal color management
within the processing graph, PNG files (and OpenRaster extended with
for instance TIFF or JPG or CMYK) can each independently hold the ICC
information.

The bottom-most/background layer in a sense becomes or dictates the
document working space, since for compositing nodes the internal
working space is a floating point associated-alpha variant of the
pixel format accepted on the input pad, the data coming in on the
secondary/"aux" pad gets converted to match the other, and the data is
provided for further processing in the tree/graph in a space with
primaries/ICC profile "inherited" from the background layer.

In addition to this, GIMP goes further than GEGL in the compositing of
its layers, the operations implementing layer modes permit specifying
if they request data with no-TRC, the TRC from the ICC profile or a
TRC with the float value 0.5 as middle gray. This permits maintaining
the legacy results one gets with naive compositing of 8bit sRGB data
for some layers as well as in the same document having more correct
compositing without the gamma-related fringing doing it in sRGB would
result in.

This locally-in-graph handling of color space information also makes
it possible to have multiple documents with different color spaces, as
well as doing copy and paste between buffers with different
model/precision/color space.

/pippin

P.S.: I encourage color focused participants of LGM to ask for a
color-BoF for asking and getting answers to such questions as well as
color specific notes sharing between projects at LGM, we used to have
this in the past. Face to face communication is a lot more efficient
use of time than mailinglists for, among others, dyslectic non-native
english speakers - and in my experience color discussions seem
particularly badly suited for mailinglists often deterioating into
terminology related confusion, misunderstandings, and flames.