[CREATE] OpenRaster specification: updates to support masking

[Andrew Chadwick]

On 28 January 2014 09:33, Boudewijn Rempt <boud at valdyas.org> wrote:
> On Monday 27 January 2014 Jan 19:32:57 Andrew Chadwick wrote:
> Hm... I can't say I'm very enamoured of a construct like
>
>  <layer composite-op="svg:normal svg:src-atop" ... />

Yeah. It's just a thought, to try and achieve some limited backwards
compatibility. I'll confess I don't much like properties in XML
dialects that you have to parse to any degree beyond looking up values
in a table or conversion to a single basic type.

I'm happy to go ahead with separate @blend and @composite, as in the
proposal. I just wanted to bat around the idea of expressing it via
@composite-op. I suppose though if you want to attempt to be backwards
compatible, you'd write a composite-op if the blend+composite mode of
the layer can be expressed as one of the old "svg:" names.

(TBH I sort of hate the svg: prefixes, primarily because SVG1.1
doesn't do interesting blending and never did, and
http://www.w3.org/TR/SVG12/ and its modules have kinda languished
since 2005 and been superseded by efforts like Compositing-1. The
OpenRaster spec seems to have been written off an earlier draft, which
we had to supplement anyway for colour/luminosity/hue/saturation
modes, so those "svg:" prefixes seem to refer to an SVG that never was
quite official. Time to make a clean break, I think; the Compositing-1
spec just seems fuller and better to me.)

> That said, I'm going to have to spend some serious time on krita to actually make krita compatible with all the possible permutations of the original proposal. Maybe we'll have time in Leipzig to go through it?

That would be good - I'll certainly make time.

It's worth noting that there are probably only a small number of the
compositing modes that make sense for a painting app:

 - source-over for general work
 - destination-in for making masks where you draw the void
 - destination-out for making masks where you trim off the unwanted
edges (unusual, but it's more efficient to render ☺)
 - source-atop for making coloured textures over the tops of things

Of the others, {destination, copy, clear} are pointless for getting
things done. As for source-{in, out} for making masks, sure they can
be used, but using their destination-{in, out} equivalents over the
top in an isolated <stack/> makes for a simpler stacking structure
when you find yourself wanting a group of layers you want to mask as a
whole.

I can't really think of an use for xor in any artistic workflow, and
lighten (plus) looks like it really wants to be a blend mode, though
the Porter-Duff paper says it's handy for crossfades.

> On the topic of openraster, I want to bring something up that was discussed before, but I don't remember the resolution:
>
> I'd like to add a png of the rendered image to the zip file. For Qt, I created a qimagio plugin that can show ora files, but it actually uses all of Krita to render the file -- and that is both dangerous and takes a lot of time.

Isn't that the idea behind mergedimage.png?
http://www.freedesktop.org/wiki/Specifications/OpenRaster/Draft/FileLayout/

We could bump it up to a MUST, but that might need a new spec version.

-- 
Andrew Chadwick