OpenRaster

From Create Wiki

Introducing common exchange file formats has become a good tradition. We have such in CAD, audio production and video. When it comes to graphics, there is none. OpenDocument seems to be a good model to imitate.

OpenRaster was initiated at Libre Graphics Meeting 2006 in Lyon, when some of the developers of the Gimp and of Krita (and with other potentially interested members of other graphics softwares) met for the first time.

Contents 1 Drafts 2 Requirements 2.1 General 2.2 Metadata 2.3 Layers 2.4 Other 3 Likely Problems 4 Links 4.1 Similar Formats 5 Implementations

Drafts

Here is the list of drafts for the OpenRaster specifications:

• Layer Stack Specification
• Effects Specification
• File Layout Specification

There is page for points which are under discussion.

Requirements

Following features should be present:

General

• full freely available documentation
• OpenDocument type of file format (archive with multiple files inside)
• extensible, but private undocumented extensions should be excluded, any extension should be added to the spec and documentation of the file format
• applications aren't expected to support all features of the file format, but when manipulating the file they shouldn't lose any information they can't handle

Metadata

• storage of metadata using {XMP - Dublin Core - IPTC} tags
• possibility to store metadata tags per layer
• storage of EXIF tags
• all text data in Unicode (UTF-8 or UTF-16)

Layers

• storage of multiple layers
• storage of each layer's coordinates
• storage of blending (compositing) options for each layer
• storage of adjustment layers
• storage of layer effects
• groups of layers
• color information - profile, colorspace

Other

• storage of paths, clipping paths, text on path
• selections, masks
• embedding documents within OpenDocument framework

Likely Problems

A major problem is that because all features aren't available in all the programs, image won't be displayed the same way in different applications, especially for adjustement/filters layers. And "viewer" apps like inkscape or scribus won't have any implementation at all of those features

A likely work-around is the optional storage of a redundant extra layer containing the fully rendered pixel data as seen after all image processing, or possibly a lower-resolution snapshot of it suitable for previewing and thumbnailing.

Different implementations levels might be defined, like, tiny, simple, small, normal, full and custom.

Links

• http://article.gmane.org/gmane.comp.video.gimp.devel/8776
• http://pippin.gimp.org/xcf2/
• http://pippin.gimp.org/OpenRaster/
• http://books.evc-cit.info/odbook/book.html
• http://blogs.gnome.org/view/bolsh/2006/06/19/0
• http://www.valdyas.org/fading/index.cgi/2006/06/20#openraster
• http://norman.walsh.name/2006/06/18/xcfBahHumbug

Similar Formats

• http://broadcast.oreilly.com/2009/05/adobe-fxg-and-ooxml-the-big-fi.html
• http://www.andersblog.com/archives/2009/05/post.html

Implementations

• MyPaint saves to OpenRaster by default (sample file)
• Krita 2.0 can load OpenRaster documents saved by MyPaint
• GEGL is reported by pippin to be able loading ORA files created by MyPaint
• DrawPile/SVN saves to ORA by default
• GIMP has an unofficial plug-in for loading and saving ORA files.

Image Browsing:

• See OpenRaster/Desktop_Integration, there are thumbnailers for KDE and Gnome.