[CREATE] Linear light workflow

[Boudewijn Rempt]

Well, for Krita, I'm not sure yet how this affects us -- and how it 
affects people who use ora to have a common file format between MyPaint 
and Krita and switch back and forth during painting. I need to dig in a 
bit and ask around.


On Wed, 28 Mar 2012, Andrew Chadwick wrote:

> 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
> _______________________________________________
> CREATE mailing list
> CREATE at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/create