Author: Nathan Willis
At issue is the interchange of layered documents between apps, not the usurpation of the native file format of individual editors. In years past, the Adobe Photoshop format (.PSD) served this need; it was well documented and supported the necessary features. But it is now no longer compatible with free software. Adobe pulled the public specification and closed the documentation; now those who wish to view it must sign agreements not to use the information to compete with Adobe products.
In the absence of .PSD, there is no application-agnostic file format up to the task. The goal of an open interchange format would be to move “complex” raster image documents between multiple applications, preserving high-level structural elements like layers, groups, masks, and paths, permitting access to metadata, and supporting image data from a multitude of bit-depths and color spaces. Properly designed and documented, full-featured apps like editors could implement the entire specification, and multiple apps could alter the same file, while simpler apps like viewers need only implement part of the specification.
An oft-mentioned second choice, the GIMP‘s XCF format, is supported by a number of free software programs, but was not designed for interchange or extensibility, and is likely to be replaced in the not-too-distant future anyway. The venerable TIFF format is highly extensible, but also very complicated. Extending the TIFF format might be possible, but adding non-raster data like text layers would be difficult, and the TIFF format is already so extended that most apps only implement a subset of its features.
OpenRaster
This leaves free software developers with a vacancy to fill. Discussion on the various approaches, their merits, and their drawbacks has taken place mainly on the CREATE project’s mailing list. Krita developer Cyrille Berger first proposed building a new file format from the ground up back in March, and along with Krita maintainer Boudewijn Rempt wrote a draft specification based on the feedback received.
Berger and Rempt’s proposal — tentatively termed OpenRaster — follows the form of the existing OpenDocument specification. Each OpenRaster document is an archive of multiple binary data files and XML descriptors detailing the relationships between the parts. CREATE’s Web site hosts both the OpenRaster proposal itself (in PDF) and a wiki page tracking the continuing development.
Rempt points out that by agreeing to work within the existing OpenDocument framework, arguments over basic structure and formatting decisions can be skipped entirely. Instead, he says, “we can move on to the fun bits: what does the composite operation OVER mean, and how can we specify a Gaussian blur adjustment layer that’s portable between apps.”
Reaction and outlook
Critics of OpenRaster cite the complexity of OpenDocument as more of a burden than a benefit. For example, OpenDocument specifies the ability to embed other documents within an OpenDocument file, but this can introduce both complexity for each application, and uncertainty, as multiple applications may not render the embedded document in the same way.
There are alternative theories to the OpenRaster approach. The GIMP’s Øyvind Kolås posited a simpler technique in his earlier XCF2 proposal. This proposal also uses a combination of XML and binary data, but makes no attempt to implement OpenDocument. Note that despite its reference at various points in the OpenRaster debate, Kolås proposed XCF2 for the next generation of the GIMP, not in response to OpenRaster.
As Rempt alluded to, though, questions over the overall structure of the file format may be contentious, but more critical are the nuts and bolts of representing the image data within that structure. Indeed, after Berger and Rempt submitted the draft to the CREATE list, discussion rapidly veered off of the merits of OpenDocument itself and toward dissecting the technical issues.
That reinforces Rempt’s point: that it is better for the graphics community to jump on the OpenDocument bandwagon than to try and hash out a separate standard, since it is a more efficient use of their time.
The process has just begun, and numerous arguments are sure to follow before anything concrete emerges. But the proposed format is not likely to wither away; Berger and Rempt are certain to propel their ideas forward, if for no other reason than they need a new native format for Krita.
Rempt took over as Krita’s maintainer in 2003, and says he is stubborn enough to insist that whatever else happens, Krita’s next-generation format will be OpenDocument-compliant. That said, as long as the Krita team was going to design a new format anyway, the community would be well-served if Krita focused on drafting the much-needed raster interchange format, rather than one specific to Krita alone. The other apps may never adopt OpenRaster as their own native format, but as long as its specification is open and community-driven, it will continue to be compatible, and thus serve as a valid replacement for PSD.
