[CREATE] OpenRaster BOF
boud at valdyas.org
Thu May 27 06:29:52 PDT 2010
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
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
* 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
* 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
More information about the CREATE