[CREATE] Re: Open File Format for Raster/Bitmaps Graphics

[Larry Ewing]

On Tue, 2006-03-21 at 08:55 +0100, Boudewijn Rempt wrote:
> On Tuesday 21 March 2006 00:40, Cyrille Berger wrote:
> 
> > Firstly, I invite developers of The Gimp, Cinepaint, Krita and any other
> > projects interested in talking about an Open File Format for Raster/Bitmaps
> > Graphics to join the create mailing list at freedesktop.org (more
> > information at http://lists.freedesktop.org/mailman/listinfo/create) and
> > not to answer it on specific projects mailing list.
> 
> Thanks Cyrille, for picking this up.
> >
> > So this discution is about a common file for graphics applications, and
> > used for sharing graphics between different projects, like OASIS's
> > opendocument is for office applications, and svg for vectorial graphics.
> 
> I would not say "like". My intention when I brought this up was to _be_ an 
> OASIS OpenDocument file format specification. That means that the basic 
> technical decisions are a given: a zipfile containt an XML main document 
> describing the image, and blobs with the image data in subdirectories. 
> 
> I have read most of the publicly available prior discussion on XCF2 and 
> similar efforts, and I know about the shortcomings of that scheme. But: 
> 
> * zipfile with maindocument and layers in seperate documents is a scheme that 
> has proven itself already.
> * OpenDocument has mindshare and momentum
> * OpenDocument is relatively easy to implement 
> * OpenDocument is not dependent on the internal organization of any 
> application.
> * And finally, by taking OpenDocument as a starting point we can skip all the 
> agonizing discussions that stymied any effort at getting somewhere before.
> 
> > - someone (a native speaker would be better I guess) will then write the
> > draft of the list of requirements for the specification, after this
> > document is produced, we take some time to think about what we have
> > forgotten, what need to be add and modified, and the final version will be
> > published for the end of April the begining of May.
> 
> I'm not a native speaker, but I think my command of English is sufficient take 
> this on. After all, the rest of the OASIS OpenDocument specs aren't 
> magnificent English either :-).
> 
> > - until the end of june, we take between a month or two months to discuss
> > the general technical solutions and we decide who (a group of person) will
> > be charge of writting the draft of the specification
> >
> > It would be nice to have the specification ready for the end of the year.
> > And as the specifications has to be extensible, it seems to be a reasonable
> > goal.
> 
> It would be even nicer to have v1 done in September.
> 
> The specification needs to have at least the following features:
> 
>
> * Layerdata in an extensible set of colorspaces (the list of colorspaces in 
> e.g. /usr/include/icc34.h is not enough. Krita already goes beyond that.)
> * Composition operations (maybe this list can be exhaustive)

Be sure to be very explicit about the math used for each mode, and any
mapping between these modes and modes from other formats.  

> * Layer states (locked, visible, etc)
> * Paths (the gimp uses svg here, right? That should suffice for all purposes)

SVG is a huge spec (and references a huge number of other specs) and
covers most of what this format you are describing can do itself.
Including it as a path format is overkill and would make it trivial to
write files that no two programs could render the same way.  Is there
even a fully complaint SVG renderer in existence?

If you want to use svg like constructs make a micro format that defines
path elements the same way as a specific version of svg spec and give a
trivial example how to convert it to svg, hopefully then you can avoid
including all of CSS DOM ECMAScript etc. as part of your specification.

> * Channels (don't know about these)
> * Selections, masks
> * Adjustment layers: these may be very hard to make interoperable. But we 
> should look into it
> * metadata (covered by OpenDocument already)
> * embedded data like profiles, exif blobs. Krita calls this annotations, the 
> Gimp parasites, but the idea is the same
> * embedded documents (either vector graphics or other) -- this is handled by 
> OpenDocument already, we just need to keep it possible.

Making generic container formats quickly runs into a couple of problems.
One is that parts of the file will quickly get out sync with other parts
(especially metadata) try to be very explicit about what to do with
metadata that the program doesn't understand.

Another is similar to the one above with svg.  You end up with files
that nothing but the program that wrote the file can render and
interchange becomes problematic.  This isn't easy to solve but it might
be a good thing to have a very public way for applications to provide
extension documents.  Both so that compliance with the main
specification means something and so that people know where to look for
information on what an application is doing.  Something as simple as
requiring extended formats to include a URL to a public specification
to be considered valid might go a long way.

In my view is is better for a spec to be very strict well defined and
easy to comply with than it is to try handle every imaginable case.  The
bar you are setting for someone to implement this format from scratch is
pretty high when you consider all the list above zip, xml, ICC etc.
and here are already a lot of raster formats that act as containers out
there.  Many of them aren't in wide use because they are too broad or
poorly defined.  Don't compound the problem by trying to be too
flexible.

--Larry