[CREATE] Linear light workflow

[Andrew Chadwick]

On 28 March 2012 18:09, Chris Lilley <chris at w3.org> wrote:
> On Wednesday, March 28, 2012, 6:08:36 PM, Boudewijn wrote:
>
> BR> Wouldn't it be easier to just define the working space with a
> BR> profile in openraster, and take it from there?
>
> That would be simpler, and more flexible - avoids boxing people in to only sRGB and linear-sRGB.

It's linearRGB, not linear-sRGB. Is that an intentional loophole, or
am I just imagining it? :D

Boxing in might not be a problem. We're technically only defining the
*compositing* space for display here. Choice of working space for
everything else is up to the app (not sure how much use that is,
however...)

The restrictive reading of what already have:
OpenRaster's draft spec already requires the primaries of sRGB when
compositing for display because it defines its Porter-Duff ops in
terms of SVGCompositing; the concrete bases for which are either
SVG1.2Tiny or SVG1.1. 1.2Tiny is sRGB only.  SVG1.1Full permits any
color space you like, but notes that "[...] in this specification,
color interpolation occurs in an RGB color space even if an ICC-based
color specification is provided (see ‘color-interpolation’)").
Therefore, convert to "sRGB linear" before compositing if the internal
colour space uses different primaries.

Liberal reading:
Suspect that Porter-Duff separable compositing ops can actually be
done sanely with linear tristimulus values in *any* RGB colour space
provided src and dst are . But uncertain (here my colour theory ends).
This would only get us so far because not all of the compositing ops
we could implement are separable, making white point matter. Probably.

-- 
Andrew Chadwick