rock@xxxxxxxx (2003-08-08 at 1801.54 -0700): > 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. PNG 32 bit names are char... or at least all them can be read. :] And I think the purpose of this was, among other ideas: easy to parse (always four chars) and makes sense with some rules about chars (caps vs normal). Even the magic of PNG had a reasoning (part binary to avoid confusion with text and capable of detecting non 8 bit transmision or bad byte order). IOW, why not make it similar, but just bigger (four char for name space and 12 more for function)? Arbitrary size strings does not seem a good idea to me. Another thing, alignment (and thus padding), is worth the problems it could cause? If the format has to be fast, maybe this should be taken into account, and not only about small sizes in memory (ie 32 bit), but maybe disks (ie blocks) or bigger sizes in memory (ie pages) too. Would the format be used just as storage, or would it be used as source / destination when memory is scarce. Remember that some apps are capable of working in areas instead of the full image, to improve global troughput. > 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. I would avoid compression inside the format. Files can be compressed as a whole, and IIRC Adam7 is about interlacing, not compression, dunno why an editor should do progressive load. Load smaller res in case of problem? I would try to avoid that instead of try to fix it, with proper storage and transmission. Load with proxy images? Too rough, IMO, it is not a scaled down version. PNG compression is the one provided by zlib, and I can show you cases in which other compressors have done a better job with my XCF files (anybody can try bzip2), and if computers keep evolving the same way, the extra CPU load is better than the disk or network transfer. Letting other apps do it means those apps could be general, reducing work load. Or better, custom, but once the "look" of the data is well known and there is plenty of test cases (like FLAC but for XCF2, compression targeted at some kind of patterns). Realize too that this links to aligment things, if you know that a layer is always somewhere and requires X MB, you can overwrite and reread without problems. > 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" Note what I said about PNG file header above. > 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 For all these sizes... why not 64 and be avoid future problems? If someone likes it and uses it for really big things, segmentation is a negative point. Or maybe force a small max size for each chunk (forcing segmentation) which would give more CRCs. Options, options, options... > "This is the comment" > chunk end (flags) - 2 bytes > "xcf-comment" > 1 (subchunk depth) - 1 byte > crc32 - 4bytes [...] I would add unique chunk ID to each, so then can make references. So of your list of items, 1 (lossless), 2 (portable), 3 (extensible), 4 (graphs), 7 (depth and spaces), 8 (gimp states) are a must. 5 (recoverable) will be nice, a lot, but if you want it to work, it sounds like some escaping and reserved flags will be needed (like line code in transmissions). I would forget 11 (compression), and put 10 (compact) as a secondary to 9 (fast load/save) and 6 (fast access). I would add tile based as 12. To some extent, it reminds me of the Blender format (with the add on that Blender files are 64 or 32 bit, little or big endian, and all the plataforms can load them fine... Adam will love it :] ). GSR
