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) * Layer states (locked, visible, etc) * Paths (the gimp uses svg here, right? That should suffice for all purposes) * 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. I have probably forgotten something... Note that I didn't intend this proposed format to replace the native format for any application. It will probably become Krita's native format, because Krita is part of KOffice and KOffice will become fully OpenDocument native in the future. I'm also not proposing a common library to handle loading and saving to this format. -- Boudewijn Rempt http://www.valdyas.org/fading/index.cgi
pgpW8WSTs5OdR.pgp
Description: PGP signature
_______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
