Several XCF formats have already been proposed; why should I propose another? It seems to me like the existing proposals have all missed the main point. While they have nice properties for certain extreme cases, they miss the boat when it comes to the main point of a graphics format, which is to efficiently store (and load) graphical information. This has lead to proposals that are neither elegant nor simple; instead they are cumbersome, with redundant, and superficial information stored, along with potential for confict between different sections of the file. But rather than detail these problems, let me suggest my own solution. Let us start with an existing graphics format, for inspiration if nothing else. The format I chose is PNG, because it is arguably the best existing lossless portable graphics format available. Before we continue, though, allow me to ennumerate what charactoristics the Gimp native format should possess, in no particular order: 1 lossless 2 portable between architectures and programs 3 extensible 4 capable of representing trees and graphs 5 recoverable from corruption 6 fast random access of data 7 able to support many color depth and spaces 8 able to represent any state that gimp maintains 9 fast loads and saves 10 compact 11 good compression of graphical data PNG certainly supports 1,2,6,7,9,10, and 11. Let us examine the other issues in more detail. Extensablity: PNG supports some degree of extensiblity, but the namespace available is quite small, being only four letters. While we could use the same chunk type name for all of our additions, say 'GIMP', and then have the first field in the chunk contain which kind of chunk it really is. But this is an inelegant hack. Capablitity of representing trees and graphs: Obviously, png's minimal extension facilities could be used to implement chunks that envelope an entire tree of chunks, but this would be difficult to reconsile with PNG's current order-based approach to metadata association, and would be awkward for GIMP-aware and non-GIMP-aware PNG readers alike. Corruption Recovery: PNG has good corruption detection, but little to facilitate corruption recovery. Representation of GIMP state: see extensibility. While PNG's faults aren't serious, we can do better. A pure XML format, by way of comparison, would fulfill requirements 1,2,3,4,7, and 8. Requirement 5 in practice would be difficult to fulfill in a pure XML format without hand-hacking, which is beyound the skills of most users. A zlib-style compression step could make some progress towards 10. An archive with XML metadata and png graphical data, on the other hand, would satisfy requirements 1,2,3,4,7,8, and 11. Requirement 6 is fulfilled for simple images, but for more complex images XML does not scale well, since every bite from the begining of the XML file to the place in which the data you are interested in is. It seems like all we have to do is combine the strengths of PNG and the strengths of XML to create a format that satisfies our requirements. What we really need is not an extensible text markup language, but an extensible graphics markup format. Such a format would bear strong resemblence to both PNG and XML. Portable XCF would use a chunk system similar to PNG, with two major differences. First, chunk type would be a string instead of a 32-bit value. Second, chunks can contain an arbitrary number of subchunks, which of course can contain subchunks themselves. At the end of each chunk is a checksum, as well as a close-chunk marker. The purpose of the close-chunk marker is to help recover in case of corruption; if no corruption is detected, the close-chunk marker is ignored. One of the major advantages of this hybred technique is that if an implementation does not understand or is not interested in a particular chunk, it can seek to the next chunk without having to read or parse any of the data in-between. image data chunks should use png-style adaptive predictive compression. They should also use adam-7. An example is worth a thousand words. Here is a simple RGB image with two layers (one with a parasite) and a comment. This is just a rough sketch of what it would look like: (labels in all capitial letters are for illustrative purposes and do not take up any space in the file.) FILE HEADER: "portable xcf file" version major - 1 byte version minor - 1 byte CHUNK: chunk start, optional - 2 byte bitmask with some png-like flags "xcf-comment" total size of chunk and subchunks - 4 bytes size of chunk - 4 bytes "This is the comment" chunk end (flags) - 2 bytes "xcf-comment" 1 (subchunk depth) - 1 byte crc32 - 4bytes CHUNK: chunk start, manditory - 2 bytes "xcf-layerstack" total size - 4 bytes size - 4 bytes SUBCHUNK: chunk start, manditory - 2 bytes "xcf-colorspace" total size - 4 bytes size - 4 bytes "xcf-sRGB" chunk end (flags) - 2 bytes "xcf-colorspace" 2 (depth) - 1 byte crc32 - 4 bytes SUBCHUNK: chunk start, manditory - 2 bytes "xcf-layer" total size - 4 bytes size - 4 bytes <graphic data> PARASITE SUBSUBCHUNK: chunk start, optional - 2 bytes "gimp-parasite" total size - 4 bytes size - 4 bytes <parasite data> chunk end - 2 bytes 3 (depth) - 1 byte crc32 - 4 bytes chunk end (flags) - 2 bytes "xcf-layer" 2 (depth) - 1 byte crc32 - 4 bytes SUBCHUNK: chunk start, manditory - 2 bytes "xcf-layer" total size - 4 bytes size - 4 bytes <graphic data> chunk end (flags) - 2 bytes "xcf-layer" 2 (depth) - 1 byte crc32 - 4 bytes chunk end (flags) - 2 bytes "xcf-layerstack" 1 (subchunk depth) - 1 byte crc32 - 4bytes chunk begin, optional - 2 bytes "xcf-end" total size-4 bytes size - 4 bytes crc of entire file - 4 bytes Any comments? Rockwalrus
