[CREATE] OpenRaster specification: updates to support masking

[Andrew Chadwick]

The branch

  https://gitorious.org/mypaint/achadwick-mypaint/commits/layer-enhancements-exp

now fully supports layer grouping, Compositing and Blending Level 1 -
style[1] layer stacking (all blend modes, all composite modes, and
layer group isolation done the way the spec says), and should make a
decent testbed for any updates we want make to OpenRaster.


Let's discuss how to represent this in *our* XML dialect though.
Currently the branch writes the compositing mode and the blend mode
separately:

  <layer blend="normal" composite="source-atop" ... />

But there may be a good argument to be had for trying to keep things
compatible with the old @composite-op: its tokens are broadly
compatible. Our composite-op[2] is based on the SVG 1.2 compositing
module's comp-op[3]  property, which allows basically the union of the
compositing and blending tokens, but only one token at a time, minus
the four additional blend modes from the W3C dev spec that turned into
[1]. For OpenRaster layers, it's productive to be able to do both at
once (and the layer rendering model suggested by [1] permits chaining
in this way, and leaves space for filters too), so what about allowing
*both* to be specified, separated by whitespace?

  <layer composite-op="svg:normal svg:src-atop" ... />

(Normalization: write blend mode, then compositing mode. Rationale:
looks more like the Porter-Duff compositing algebra... If no
compositing mode is specified when reading one of these,
"svg:src-over" should be used, and if no blend mode is specified, then
"normal" should be used. If more then one blend mode is found in the
string, the last one specified is to be used; same deal for
compositing modes)

Bit harder to validate, however.

Good idea? Bad? Anyone reading this?


[1] http://www.w3.org/TR/compositing-1/
[2] http://www.freedesktop.org/wiki/Specifications/OpenRaster/Draft/LayersStack/#layerelement
[3] http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.html#comp-op-property

On 18 January 2014 08:29, Sven Claussner <scl.gplus at gmail.com> wrote:
> Thank you, Andrew.
> I took myself to liberty to point the GEGL devs here.
> Perhaps it's also sth. for the LGM.
>
> Kind regards,
>
> Sven
>
>
> On  17.1.2014 at 11:08 PM Andrew Chadwick wrote:
>>
>> There is now some working code to test this concept out!
>>
>>    →
>> https://gitorious.org/mypaint/achadwick-mypaint/commits/layer-enhancements-exp
>>
>> This partially implements the proposal at
>>
>>    → https://gist.github.com/achadwick/7827931
>>
>> To mask with this branch, open the layers panel, then drag a layer
>> "into" another layer to start building structure,
>>
>>     Group
>>     ├ Layer 1
>>     └ Layer 2
>>
>> then draw a mask in pure white in the top layer and something you want
>> to mask in the lower layer in any colour you like. Set the top layer's
>> compositing mode to "Destination In" using the right button menu, and
>> the bottom layer (and anything else in the group) will be masked by
>> the top layer. You may need to refresh the view by dragging it around
>> a bit at the moment, but this annoyance should be gone soon.
>>
>> (It has to be in a group because MyPaint does non-isolated rendering
>> onto its internal background layer. Currently you see black if a layer
>> erases the background layer... The layer group implementation you see
>> here uses isolated rendering only, however, and the results of that
>> are then composited onto the background normally. This is just a
>> workaround for now, allowing some masking experiments.)
>>
>> On 13 December 2013 12:01, Boudewijn Rempt <boud at valdyas.org> wrote:
>>>
>>> I firmly intend to look into this into detail -- I'm not forgetting about
>>> it :-)
>>>
>>> On Friday 06 December 2013 Dec 16:49:10 Andrew Chadwick wrote:
>>>>
>>>> I'm in the process of (slowly and experimentally) refactoring the layers
>>>> code in MyPaint to add a bunch of fancy features like masking, nested
>>>> layers, and layer formats other than raster (but which either rasterize
>>>> (like SVG) or can be represented usefully as an icon (like basically
>>>> nothing right now)).
>>>>
>>>> I've noticed that the OpenRaster specification will need to be updated
>>>> to support the Porter-Duff "in" operator, and I'd like to take the
>>>> opportunity to allow sub-stacks to be composited with user-specifiable
>>>> blending and compositing operators. Conveniently enough, the W3C
>>>> Compositing and Blending Level 1 specification has evolved into a very
>>>> helpful and complete form, and defines neatly an important aspect of how
>>>> "groups" in formats like SVG - equivalent to our nested stacks - should
>>>> be expected to render.
>>>>
>>>> Therefore I'd like to update the OpenRaster draft specification[1] in
>>>> accordance with the attached proposal. See
>>>> https://gist.github.com/achadwick/7827931 in case the attachment hasn't
>>>> made it through the mailing list software.
>>>>
>>>>
>>>> [1] http://www.freedesktop.org/wiki/Specifications/OpenRaster/Draft
>>>>
>>>>
>>>
>>> --
>>> Boudewijn Rempt
>>> http://www.valdyas.org, http://www.krita.org,
>>> http://www.boudewijnrempt.nl
>>>
>>> _______________________________________________
>>> CREATE mailing list
>>> CREATE at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/create
>>
>>
>>
>>
> _______________________________________________
> CREATE mailing list
> CREATE at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/create



-- 
Andrew Chadwick