OpenDocument. Was: [Gimp-developer] Photoshop PSD 6 format Spec / Gimp XCF format Spec
Okay, so it turned out that I was still subscribed under an old email address, but my mailers sends everyone with the current one. Anyway, my fault, and I would like to thank Manish for helping me out of my bewilderment. What I wanted to propose & work on after my 1.5 release is the following:
Cooperating on get an OpenDocument specification for layered raster images done and into the OASIS OpenDocument standard. Krita would use that format for its native format, of course, as all of KOffice is moving to OpenDocument.
OpenDocument automatically means some choices are made for us: a zip file store, a certain layout inside that store, and xml main document and resources for the binary data. Those choices may not be the best possible technical choices, but Krita already uses a similar mechanism and it seems to work.
And since the Gimp and Krita have a different set of capabilities, we'd have to make a flexible and complete specification, one that includes all possible (possibly uninvented as yet) color models, adjustment layers, paths (which Krita doesn't have) and so on.
I would really like to cooperate on this, since a standard used by one application isn't a standard at all and since it would mean much better interchange of documents than would be possible through either Photoshop (ancient version 6 or reverse-engineered later versions) or XCF.
I'm prepared to do most of the writing & nagging of David Faure about procedures and guidelines, but I'm not knowledgeable enough to do it all on my own.
Boudewijn Rempt said the following, On 2006-03-02 20:44:
Okay, so it turned out that I was still subscribed under an old email address, but my mailers sends everyone with the current one. Anyway, my fault, and I would like to thank Manish for helping me out of my bewilderment. What I wanted to propose & work on after my 1.5 release is the following:
Cooperating on get an OpenDocument specification for layered raster images done and into the OASIS OpenDocument standard. Krita would use that format for its native format, of course, as all of KOffice is moving to OpenDocument.
OpenDocument automatically means some choices are made for us: a zip file store, a certain layout inside that store, and xml main document and resources for the binary data. Those choices may not be the best possible technical choices, but Krita already uses a similar mechanism and it seems to work.
And since the Gimp and Krita have a different set of capabilities, we'd have to make a flexible and complete specification, one that includes all possible (possibly uninvented as yet) color models, adjustment layers, paths (which Krita doesn't have) and so on.
I would really like to cooperate on this, since a standard used by one application isn't a standard at all and since it would mean much better interchange of documents than would be possible through either Photoshop (ancient version 6 or reverse-engineered later versions) or XCF.
I'm prepared to do most of the writing & nagging of David Faure about procedures and guidelines, but I'm not knowledgeable enough to do it all on my own.
I have feeling that packaging graphics "document" in a zip file is overkill _similar_ to doing that with database "document", in terms of saving/loading time and disk space needed for loading/saving. Think about _large_ documents.
I'd like to propose use well documented binary format, e.g. using Binary XML.
http://www.w3.org/TR/xbc-use-cases/#intro
I wonder why OASIS picked to only use compressed XML as a medium: -it will also not work well for video data, BTW. -OpenOffice.org Base already failed to deliver robust solution because 100% of the data has to be processed on loading/saving (unless it's stored on the server).
Or, any chances to join forces with GIMP and their XCF format? Ideally, I'd see both projects moving to binary (read: extendable) XML. Even sticking with another iteration of XCF, as a container seems better. Eventually, you can always append a chunk of XML data (metadata) to such a binary block _in place_ ang get really good performance.
BTW: You all seem to know about poor performance (time, memory usage) of OpenOffice.org Calc (not mentioning KSpread) in terms of large document saving/loading, compared to competition[*], even if the compettion that uses XML too. What's wrong with text XML in Calc is that Calc is used by some of the users as a database medium, what's terible but it's true. Good XML parser (we're going to use with KSpread too) is only to make us perform 2 times slower except 10 times slower, because the competition use more flattened and simplified XML, what OpenDocument backers criticize for a good reason.
Comments?
[*] MS Excel
On 3/3/06, Jaroslaw Staniek wrote:
I have feeling that packaging graphics "document" in a zip file is overkill _similar_ to doing that with database "document", in terms of saving/loading time and disk space needed for loading/saving. Think about _large_ documents.
I already thought about it. Yep, once you have a 500 MByte large file you will have to wait a lot until all data is repacked. But that mostly depends on level of compression, doesn't it?
I'd like to propose use well documented binary format, e.g. using Binary XML.
Binary sounds very unrepairable to my ears :), but it needs further investigation
Or, any chances to join forces with GIMP and their XCF format?
Actually, we started from that :)
Alexandre
ctually On Friday 03 March 2006 05:32, Alexandre Prokoudine wrote:
Or, any chances to join forces with GIMP and their XCF format?
Actually, we started from that :)
Alexandre
I find the xml format used by Scribus to be readable, though too wordy (all xml is too wordy IMO)
Jaroslaw Staniek wrote:
I wonder why OASIS picked to only use compressed XML as a medium: -it will also not work well for video data, BTW. -OpenOffice.org Base already failed to deliver robust solution because 100% of the data has to be processed on loading/saving (unless it's stored on the server).
Heh. I've been working on saving .odg data from Inkscape for a couple of weeks now, so I have experienced the hell of the Zip format. ;-) I don't have an opinion on this stuff, but I thought I would send some FYI stuff while waiting for the pizza to arrive.
Actually, the entries of a zip can be saved with compression method '0', which means no compression. This allows normal streaming, with the benefit that you know the output size (==input size) before each file is attached to the zip. Also, all files are added at the front, and the directory is sent last, which means that all information is known by the time the directory is sent, which also supports streaming. No seeking is required. And, really, since all information is sent for each file, the directory at the end is not needed at all. Which means, theoretically, there can be an infinite stream of file chunks.
Compression could be done, too, with compression method '8' (deflate). This means that unless you want to buffer the whole thing in memory, like you say, the header info cannot store the compressed size without a seek, thwarting streaming. However, the zip format has a hack for this, too. If the flags at the start of each file header have bit 8 set, that tells the zip reader that the file's compressed and uncompressed sizes are unknown, and those bits, along with the crc, will be sent immediately following the compressed data. This would also work if you don't know the input stream length (like video).
HOWEVER ========= But there is one special trick to ODF that nobody ever uses. Zip is -NOT- required by the specification. (Though OO.org wants it.) You can fit everything into a single XML file, separating the different file pieces with XML namespaces, and have it be a perfectly valid and useful ODF file. People just don't use it because OO.org doesn't output data this way.
So, in theory, you could send ODF in a stream of XML stanzas much like Jabber.
bob (ishmal)
Bob Jamison wrote:
HOWEVER
But there is one special trick to ODF that nobody ever uses. Zip is -NOT- required by the specification.
Well, I might be wrong on this. The spec says "uses" a packaging format, though the wording does not say "shall" or "may." However, there is talk on the opendocument list about this, calling it the "flat xml" format. The spec doc is terribly vague in a lot of areas.
sorry. I'll crawl back into my hole now. :)
bob
I am starting to be lost in this thread spread over at least four mailing lists :) May I suggest the opening of a mailing list dedicaced to the talk about an OpenDocument for raster files ? Maybe on freedesktop as it is the most neutral organisation ;) But I have no contact with them :( But maybe some one of freedesktop is reading one of the mailing list and can do that ?
participants (6)
-
Alexandre Prokoudine -
Bob Jamison -
Boudewijn Rempt -
Cyrille Berger -
Jaroslaw Staniek -
John R. Culleton