[CREATE] OpenRaster BOF

[Boudewijn Rempt]

Hi!

We had a really good BOF session on OpenRaster today. More than twenty people 
joined and we had a wide-ranging yet still focussed discussion. Here's a short 
report on what we discussed. Jon, Martin and me are going to edit the spec 
accordingly today (or at least this weekend) and then put it up here again for 
comments.

I don't have an attendance list, unfortunately, but there were plenty of 
people, with Gimp, Mypaint, Scribus, Inkscape, Adobe, f-spot, SVG, Nathive and 
Krita at least represented, as well as artists interested in the workflow 
openraster can afford them.

Here it is, as short bullet-points:

* Fundamentally, OpenRaster is an interchange format meant to be used by 
artists switching between applications in their workflow. 

* There is a Baseline Intent that all applications must roundtrip correctly. 
The Baseline can be extended by modules, for instance SVG layers.

* Extending upon the interchange format, we will define an Archival Intent. 
All extensions to the Baseline Intent in the Archival Intent must have defined 
fallbacks. The Archival Intent must also store the rendered image in addition 
to the layer data, this is not mandatory for other intents. The Archival 
Intent cannot be extended with application-specific extensions. This is also 
an invitation to discuss other desirable features for the Archival Intent.

* Metadata is stored as XMP in separate files inside the container, with 
metadata possible for the image as well as per layer.

* There are two ways of implementing layer groups: isolated and non-isolated. 
Isolated is to be implemented as layer groups, non-isolated as tags on layers.

* Layer groups should have pre-rendered fallbacks on top-level.

* Vector masks (clipping masks) and bitmap masks: vector masks are to be 
stored as svg, bitmap masks as grayscale png's. Layers with masks must have a 
pre-rendered fallback.

* Vector/Text layers: stored as SVG with editable text, not svg-fonts. There 
must be a rendered fallback. It is up to the applications to decide what to do 
here: if the rendered layer is shown and made editable, one option is to 
discard the svg data (and warn the user), the other option is to duplicate the 
original layer and hide it.

* Creation history: there was a request from an artist for this. For this we 
can use the multi-media extensions for xmp and store that as metadata, like 
Adobe apps do now. This should be a module. This request was about saving the 
creation history of the work of art, not replaying the creation of the work of 
art.

* Colorspaces: for now, we stick with what svg supports. A future extension 
might have higher-bit depth layers stored with png fallbacks.

* Versioning: a possible future extension.



-- 
Boudewijn Rempt | http://www.valdyas.org