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

_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to