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 [email protected] http://lists.freedesktop.org/mailman/listinfo/create
