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)

Gimp-developer mailing list

Reply via email to