Sven Neumann wrote:
I never understood the reasoning for this discussion anyway. IMHO the format that Nathan suggested seems like something from the dark ages of file formats (where TIFF and the like originated from). I haven't heard a single good argument for it except that it can do most of the things that the XML/archive approach can do. There was however nothing mentioned that it can do better. Or did I miss something?
I think there are three separate problems to solve here.
1) How to store the compositing tree (and other meta-data) that GEGL needs.
2) How to store bulk texels in a variety of data formats (byte, int, float, etc) and in a variety of colour representations (RGBA, CMYK, etc).
3) How to put together (1) and potentially many (2)'s into a single file.
It seems to me that XML was just *made* to do (1) nicely. It's also rather nice that this is human readable and the parsers for it are likely to be easy. XML is nice and modern and there are loads of supporters of it. I don't think this should even be a matter of debate - it's *so* obvious that this is the way to go.
(3) Looks a lot like taking an XML file and a bunch of simple images and stuffing them together into an archive. There are lots of choices for the archive format - and it probably doesn't matter which one you choose. I rather like the idea of using 'ar' - but that's a UNIX-centric viewpoint. Something like 'zip' with it's ability to compress *and* archive multiple files into one file would be good. But the obvious OpenSourced candidates (bzip2 and gzip) don't do that. Tar+Gzip would work though. The only argument I heard against it was that tar doesn't allow arbitarily long filenames...that's irrelevent because the XML code at the top of the archive can map long layer names into short sub-image names for the benefit of those who care.
Bulk image storage (2) seems a bit more problematic. It would be nice to use a standard file format so that you could unbundle a GIMP 'archive' into an XML file and a bunch of standard images, operate on them individually with other tools that know nothing about GIMP, GEGL, etc - and then put them all back together again with the archiver. So what's needed is a standard (and hopefully rather simple) image file format. However, we don't seem to be finding any nice modern, robust, well-known and portable formats that can do bizarre things like full floating point CMYK.
I think you could resolve the issue of how to store bulk image data by not making a decision!
Allow any of the file formats that GIMP uses to be used to represent a layer in the total image archive. The XML file can tell us what format each sub-image is stored in...and GIMP already has loaders for gazillions of file formats.
That way, we could use (say) PNG for storing run-of-the-mill RGB images, and invent custom formats (or TIFF with tags or whatever) for storing the bizarro stuff.
---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@xxxxxxxx http://www.link.com Home: sjbaker1@xxxxxxxxxxx http://www.sjbaker.org
