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 _______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
