[CREATE] OpenRaster specification

[Andrew Chadwick]

[Replied via the list, with Daniel's agreement - AC]

On 4 February 2014 16:36, Daniel Sabo <danielsabo at gmail.com> wrote:
> I've read your emails about updating the spec in the past and I
> haven't bothered replying because it felt like the new .ora was
> targeting something other than me. But you keep asking for feedback so
> why not.

Thanks for the feedback, Daniel. This is good stuff!

> I don't see the purpose of separating blend and composite. Most of the
> SVG blends are useless for raster graphics and separating them will
> create a couple hundred possible code paths. Two branches per pixel is
> not reasonable from an optimization standpoint.

Valid points re. code paths and optimal code, having hacked at it
myself. Though I assume you meant "Compositing-1 (Porter-Duff)
compositing operators are [mostly] useless for raster graphics" here.
The blend modes defined in the same place are precisely what we use
right now - and they're pretty useful photoshop-esque things. Please
correct me if that's an incorrect interpretation ☺

To be honest, the separation could be dropped. Initially I was
thinking that two things might have made separate blending and
compositing modes necessary:

1. Automatic group isolation according to the Compositing-1 spec
might've needed it. Would they have different effects if applied to a
group?
In practice, use of *either* a non-"normal" blend mode *or* a
non-"source-over" compositing operator on a group changes automatic
ones from non-isolated to isolated (same thing with opacity, though
you can emulate that by multiplying opacities if all else is
unchanged).

2. Texturing might've required the ATOP Porter-Duff mode on a layer as
well as what Compositing-1 calls a blend mode. Having played with it
now, it's a little unclear to me how texture effects would be used by
artists anyway, so that doesn't appear to require them to be separate
layer attributes.

So I guess separate blending and compositing modes are not really necessary.


I think right now we need:

* At least support for the Porter-Duff IN and/or OUT compositing
operators, to allow masking;
  - (and at most, support for *all* the Compositing-1/Porter-Duff
compositing operators...)
  - BUT we probably don't need them to be specified in a separate
OpenRaster stack.xml attribute. They could be specified where blend
modes are, as SVG Compositing 1.2 does[1].

* A way of allowing nested sub-stacks to be assigned modes (currently
they cannot), and have opacities (currently not permitted). This is
necessary to write a application's "layer with an effect mode and a
mask" as, e.g.

  <stack composite-op="svg:color" name="Masked colourizing layer"
isolation="isolate">
    <layer composite-op="svg:dst-in" name="Mask" ... />
    <layer composite-op="svg:src-over" name="Lots of colours" ... />
  </stack>
  <layer name="Greyscale thing to be coloured" ... />

* A way of handling group isolation in conjunction with the above. The
model proposed in Compositing-1 is sane and backwards-compatible.
Group isolation is required for masking if the model illustrated above
is to be used.

I'll post an alternative, simpler proposal shortly. Thanks for the feedback!

> With this new spec I can still see myself generating .ora files, but I
> can't possibly see supporting *reading* them when written by another
> program that may have exposed a different combination of blend modes
> to it's users. I definitely can't see making a GUI that exposes the
> blend/composite split because that is just too much choice to throw at
> the user.

A fair point. NxM complexity of this sort is overkill in a layers
panel, or really in anything short of an advanced layer properties
dialog. Which I've been playing with without really being happy with
it. A straight, linear N+M menu of possible modes is vastly simpler,
given that's basically what everyone already does.

Agreed, interchange is really, really important. It's basically the
whole point of ORA right now, so it makes sense to get it right.



[1] http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.html#comp-op-property

-- 
Andrew Chadwick