[CREATE] Linear light workflow

[Andrew Chadwick]

On 27/03/12 19:24, Øyvind Kolås wrote:
> I hope that these layer modes will in the end only be used
> when loading legacy XCF files and newer linear compositing will be
> used when creating new images from scratch (the 2.2 gamma layer modes
> could then be hidden.)
> 
> The need for having the legacy layer modes around will be required to
> continue producing the same composited result (the same applies to
> some of the odd HSV defined modes in GIMP.)

Sounds like the legacy-file approach is closer to the way GIMP is
planning to manage its own transition. Better than detecting legacy
layers and trying to treat them differently...

For *MyPaint*, we can use the same routines for both linear-light and
legacy during composition. We're lucky in that both pixel formats are
use the same bit representation: for legacy files we'd just omit
gamma-expansion on loading, pasting, and colour choice based on what
colours are visible on screen; and omit gamma-compression for saving,
display, and copying. Legacy mode does everything in
assumed-sRGB-approx, linear mode does everything right :) Short planning
notes and sample images up at
http://wiki.mypaint.info/Linear_light_composition .

For *OpenRaster*, I guess that means an attribute at the top level of
the stack.xml structure, i.e. <image/>, with the same intent and meaning
as the SVG 1.1 color-interpolation attr. Something like:

  <!-- minimal new-style openraster stack.
  <image color-interpolation="linearRGB" w="64" h="64">
    <stack .../>
  </image>

with precisely the same initial/default value ("sRGB") as in SVG 1.1,
but affecting the way all of the layers & stacks defined in the
OpenRaster doc should be composited to generate the on-screen image. How
the layers are actually stored internally is up to the app - for MyPaint
we'd make it dependent on the value read from color-interpolation and
probably treat "auto" as "linearRGB". Legacy files would default to sRGB
on opening, and would be saved as explicit sRGB, so we'd have the
desired backwards compatibility.

Does this idea seem sensible to everyone? I assume sRGB and linearRGB
are going to be the only needed values and we shouldn't try to extend
it, particularly if it's to go into baseline[1]. If there are no
objections I'll go ahead and make the spec and schema tweaks.


[1] Is defining this as a "standard extension" feasible while we're
still drafting? I'd like to manage things that way if poss. IMO it needs
to go into baseline at some point, but possibly not until the 1st
version-numbered release of the spec.

-- 
Andrew Chadwick