Re: [Gimp-developer] Portable XFC
Hi, On Thu, 2003-08-14 at 22:58, Nathan Carl Summers wrote: 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. s/most/all, and many other good things besides. Which are? There was however nothing mentioned that it can do better. Or did I miss something? XML is a text markup language. If the designers thought of using it for raster graphics, it was an afterthought at best. XML is simply the wrong tool for the job. The XML/archive idea is the software equivalent of making a motorcycle by strapping a go-cart engine to the back of a bicycle. It will work, of course, but it's an inelegant hack that will never be as nice as something designed for the job. I think it is an elegant solution to the problem of designing a file format w/o knowing beforehand what will have to go into it. I don't think that binary chunks are feasible for a format that will have to extend a lot while it is already being used. None of the file formats mentioned provide this functionality and I think it is essential here. But to answer your question: 1. Putting metadata right next to the data it describes is a Good Thing. The XML solution arbitrarily separates human readable data from binary data. No one has yet considered what is to be done about non-human readable metadata, but I imagine it will be crammed into the archive file some way, or Base64ed or whatever. Either way is total lossage. How is metadata in the archive total lossage? If the metadata is binary it should of course be treated just like image data. 2. Imagine a very large image with a sizeable amount of metadata. If this seems unlikely, imagine you have some useful information stored in parasites. The user in our example only needs to manipulate a handfull of layers. A good way of handling this case is to not load everything into memory. Say that it just parses out the layer list at the start, and then once a layer is selected and the metadata is requested, it is read in. With the XML proposal, the parser would have to parse through every byte until it gets to the part it is interested in, which is inefficient. The XML parser would only have to read in the image structure which tells it where to locate the actual data in the archive, nothing else. 4. Implementing a reader for the XML/archive combo is unnecessarily complex. It involves writing a parser for the semantics and structure of XML, a parser for the semantics and structure of the archive format, and a parser for the semantics and structure of the combination. It is true that libraries might be found that are suitable for some of the work, but developers of small apps will shun the extra bloat, and such libraries might involve licensing fun. We are already depending on an XML parser right now. I don't see any problem here. I do know however that the code that reads stuff like TIFF or PNG is ugly and almost unreadable. SAX-based XML parsers tend to be darn simple however. The semantics and structure of the combination is not a trivial aspect -- with a corrupt or buggy file, the XML may not reflect the contents of the archive. With an integrated approach, this is not a concern. I don't see how an integrated approach avoids this problem any better. 5. Either the individual layers will be stored as valid files in some format, or they will be stored as raw data. If they are stored as true files, they will be needlessly redundant and we will be limited to whatever limitations the data format we choose uses. If we just store raw data in the archive, then it's obvious that this is just a kludge around the crappiness of binary data in XML. I don't understand you. If you think that raw data is a good idea, we can have have raw data in the XML archive. Allowing a set of existing file formats to be embedded makes the definition of our format a lot simpler however and allows for various established compression techniques to be used. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
On Thu, Aug 14, 2003 at 09:10:37PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: point where no image manipulation program has gone before. However there is still the need for a good format for exchanging layered images between applications. So perhaps it makes sense to also develop such an I don't think there is a need for such an extra format. Existing formats like MIFF can easily cope with layered images and can easily be extended (linearly) with additional metadata. And surely if people want to read/write xcf and don't want to use GEGL i'd firmly say it's their problem entirely. I mean, if people want to read/write PNG without libpng it's their problem, too, and png was designed as interchange format, while xcf is not, should not, and will not. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
Nathan Carl Summers wrote: On Thu, 14 Aug 2003, Sven Neumann wrote: Hi, 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). PNG is something from the dark ages? 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. s/most/all, and many other good things besides. There was however nothing mentioned that it can do better. Or did I miss something? XML is a text markup language. If the designers thought of using it for raster graphics, it was an afterthought at best. XML is simply the wrong tool for the job. The XML/archive idea is the software equivalent of making a motorcycle by strapping a go-cart engine to the back of a bicycle. It will work, of course, but it's an inelegant hack that will never be as nice as something designed for the job. But to answer your question: 1. Putting metadata right next to the data it describes is a Good Thing. The XML solution arbitrarily separates human readable data from binary data. No one has yet considered what is to be done about non-human readable metadata, but I imagine it will be crammed into the archive file some way, or Base64ed or whatever. Either way is total lossage. nonhumanreadablebinary cludge/nonhumanreadable is lossage? The recent time I spent communing with dselect, I saw a couple of binary editors. The existence of such software makes me think that binary can be easily xmlized also. Working with software my APT wrote to suit my needs on the new outdated and unloved web site (http://mmmaybe.gimp.org), it makes me want more of this same sort of editing ability with gimp stuff. I have proven myself to be very very human though. The machines perhaps will not like the xml as much as I did. 2. Imagine a very large image with a sizeable amount of metadata. If this seems unlikely, imagine you have some useful information stored in parasites. The user in our example only needs to manipulate a handfull of layers. A good way of handling this case is to not load everything into memory. Say that it just parses out the layer list at the start, and then once a layer is selected and the metadata is requested, it is read in. With the XML proposal, the parser would have to parse through every byte until it gets to the part it is interested in, which is inefficient. Frankly, this wouldn't be feasable. Only two crappy ways would be possible to get around this: store everything in memory (hope you have plenty of virtual memory!) or write out a temp file with the metadata in it, for later use, and in a random-accessable format. If you're going to do that, why not do it right the first time and save yourself the trouble? When someone asks me to imagine a large image file I naturally think of the biggest image files I ever worked with. This would be psd. It seems like the GIMP developers should be able to make something smaller than this. Sorry, I got stuck on the first line of this item. Imagining a very large image file, and the previous mail about how psd is a personalized tiff makes me even less want to use it ever. 3. None of the current suggestions for archive formats do a good job with in-place editing. AR can't even do random access. Zip can do an ok job with in-place editing, but it's messy and often no better than writing a whole new file from scratch. This means that a program that makes a small change to a file, such as adding a comment, needs to read in and write a ton of crap. 4. Implementing a reader for the XML/archive combo is unnecessarily complex. It involves writing a parser for the semantics and structure of XML, a parser for the semantics and structure of the archive format, and a parser for the semantics and structure of the combination. It is true that libraries might be found that are suitable for some of the work, but developers of small apps will shun the extra bloat, and such libraries might involve licensing fun. The semantics and structure of the combination is not a trivial aspect -- with a corrupt or buggy file, the XML may not reflect the contents of the archive. With an integrated approach, this is not a concern. mmmaybe has an xml reader. It is small and nice. An attribute rewritter that skips a lot of the crap that the old tools brought along with it. Or is this mention out of line here 5. Either the individual layers will be stored as valid files in some format, or they will be stored as raw data. If they are stored as true files, they will be needlessly redundant and we will be limited to whatever limitations the data format we choose uses. If we just store raw data in the archive, then it's obvious that this is just a kludge around the crappiness of binary data in XML. How much binary data is in images. This is very confusing to me. For
Re: [Gimp-developer] Portable XFC
Stephen J Baker wrote: 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. I second the obvious part to this. I have been seriously caught off guard lately as this seems so obvious to me that I could not begin to envision a conversation being needed to support it. However, I have had great success with xml, only after I had my own tools built for it. The nice thing about xml is that you can build your own issues into it. This is also why I found it necessary to build our own. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
Hi, I'd like to mention that none of the proposed formats except the XML approach would be capable of supporting the stuff we want to add to GIMP with GEGL. I don't think any existing format could be sanely extended to support complex render graphs as will be introduced with GEGL. We are not talking about simple layer lists or trees any longer but we need to be able to store complex processing intructions with each node. XML seems to be the only reasonable choice here. According the library that reads and writes the new format, GEGL should provide this functionality. The basic file format should be defined by GEGL and GIMP will only add some user interface specific things in its own namespace. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
At 8:32 PM -0300 8/13/03, Joao S. O. Bueno wrote: People have considered TIFF, PSD in this newer thread - before the Camp, on the list, we were almost closed in an ar archive, with XML informatin and possibly PNG raster data inside. Which is still a valid approach, but would DEFINITELY require a standard library since 'ar' isn't a standard outside the Linix world... Why not settle for a Postscript subset? Because Postscript is dead. It hasn't been updated in over 6 years, and Adobe themselves are slowly moving towards PDF-based solutions, including printing. Also, Postscript is a programming language. You would need to implement a full parser and interpreter for it. NOT a fun thing. You'd be better off heading down the PDF route...All the benefits of PS, but a LOT easier to implement and MUCH more extensible and supported. The major one, of course, is that the file would be essentialy auto renderable - no need of GIMP, neither of any other program, to get it printed. Assuming a PS printer... But most users either have PCL or raster-based printers... Since PSD and TIFF are used by ADOBE, ADOBE also has a program that makes use of postscript subsets.. I just do not remember which file type it is. Versions of Adobe Illustrator = 8 used a subset of EPS (Encapsulated Postscript) as its native file format. As of version 9, it now uses PDF as the file format. It can have color profiling support - it is on the specifications. It has support for multiple compression standards... (ok, maybe you have to encode the decompressor algorithm inside the file as well if you want something too different) PS doesn't support plug-in filters... Text layers would have trivial, transformation independent, support. Storing the text isn't the hard part of text layers... Leonard -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
On Thu, 21 Aug 2003, Leonard Rosenthol wrote: At 1:47 PM +0200 8/14/03, Sven Neumann wrote: I'd like to mention that none of the proposed formats except the XML approach would be capable of supporting the stuff we want to add to GIMP with GEGL. Well, that pretty much settles that discussion... Not really, since that reasoning is based on an untruth. And even if it wasn't, it's a logical fallocy to assume that because no graph-capible proposal was made, that XML was the only possible way of representing a graph in a file format. According the library that reads and writes the new format, GEGL should provide this functionality. Requiring an application to incorporate all of GEGL in order to read/write an XCF file is, in my opinion, a recipe for it not getting used by other applications. (and I say this as one of those other application developers). That is why I suggest both a lightweight library and gegl routines for it. Actually, gegl can use the lightweight library for the loading. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
Thank you for the comments. I quite much agree with all of them, I just threw it in because I think it'd more interesting than TIFF or PSD alltogether. Quite informative is the part about Adobe patents. I will no longer mention PS as a native file format, GSview is quite good as a PS loader as it is today. As to Leonard who suggested that postscript doesn't accept plugins, I have to point him for the fact that it i s a programing language - and the dedcoding algorithns I mentioned would just be placed in the file as postscript procedures. And why PS instead of PDF? You can edit good Postscript files with a text editor, just as you can do with XML. Regards, JS -- Mukund wrote: On Wed, Aug 13, 2003 at 08:32:00PM -0300, Joao S. O. Bueno wrote: | But on this new thread were proprietary formats batle along with mutant | ideas, here I go: | Why not settle for a Postscript subset? PostScript is a proprietary format controlled by Adobe. Adobe has several patents on various aspects of the PostScript format any implementation would be affected by. | The major one, of course, is that the file would be essentialy auto | renderable - no need of GIMP, neither of any other program, to get it | printed. This is a good idea, but it would also mean GIMP would have to read back a PostScript file. PostScript is a huge standard outside the scope of an application such as the GIMP. Developers would have to put in kludges and special comments which'll help them represent structures which cannot be natively represented using PostScript. Isn't this just as expensive as implementing a new specification? What's more easier? A Have a native file format designed for the GIMP. Those who want to use it with PostScript aware applications export the native format using a plug-in. If XML is used for the underlying data representation, any XML parser can be used to parse information, especially information such as the author of an image, size and colour depth of the image, etc. B Use a subset PostScript as the native file format. Design and implement representation of unrepresentable structures in PostScript comments. Implement a PostScript parser (which is as good as a stack based interpreter). | Since PSD and TIFF are used by ADOBE, ADOBE also has a program that | makes use of postscript subsets.. I just do not remember which file type | it is. | | It can have color profiling support - it is on the specifications. It | has support for multiple compression standards... (ok, maybe you have to | encode the decompressor algorithm inside the file as well if you want | something too different) Support for multiple compression algorithms can be implemented in an XML based format. One can also have data in other image formats such as TIFF, PNG or even the same GIMP native format itself embedded as CDATA, or the file format may be an archive of associated images, etc. The features implemented depend on how far developers want to take the new file format. The developers themselves are capable of doing what they want :-) Mukund ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
At 1:47 PM +0200 8/14/03, Sven Neumann wrote: I'd like to mention that none of the proposed formats except the XML approach would be capable of supporting the stuff we want to add to GIMP with GEGL. Well, that pretty much settles that discussion... So let's start talking XML + archive again, shall we ;). According the library that reads and writes the new format, GEGL should provide this functionality. Requiring an application to incorporate all of GEGL in order to read/write an XCF file is, in my opinion, a recipe for it not getting used by other applications. (and I say this as one of those other application developers). Leonard -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
On Thu, 14 Aug 2003, Sven Neumann wrote: [Note: quote blocks have been reordered for clarity] Hi, I'd like to mention that none of the proposed formats except the XML approach would be capable of supporting the stuff we want to add to GIMP with GEGL. On the contrary, my proposal would handle graphs as easily as XML would. We are not talking about simple layer lists or trees any longer but we need to be able to store complex processing intructions with each node. XML seems to be the only reasonable choice here. My proposal is tree-based just like XML. And you can do graphs in it exactly the same way it is done in XML -- by labeling elements of the tree and using the labels to denote the links between the nodes on the graph. I don't think any existing format could be sanely extended to support complex render graphs as will be introduced with GEGL. Depends on what you mean by sanely extended. Of course it is unlikely that you could create something that interoperates well with existing applications, but there is nothing inheritly wrong with takiing an existing format, or more than one, and using it for the basis of the new XCF. According the library that reads and writes the new format, GEGL should provide this functionality. The basic file format should be defined by GEGL and GIMP will only add some user interface specific things in its own namespace. I can imagine that parasites, at the minimum, would also go in the GIMP namespace. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
On Wed, Aug 20, 2003 at 07:45:33PM -0400, Leonard Rosenthol wrote: | | Because Postscript is dead. It hasn't been updated in over 6 | years, and Adobe themselves are slowly moving towards PDF-based | solutions, including printing. PostScript is far from dead. You would be banishing the entire publishing industry if you say PostScript is dead :-) Are you sure it hasn't been updated for so long? Take a look at the PostScript 3 reference manual. | Also, Postscript is a programming language. You would need | to implement a full parser and interpreter for it. NOT a fun thing. | | You'd be better off heading down the PDF route...All the | benefits of PS, but a LOT easier to implement and MUCH more | extensible and supported. Implementing a full PDF parser is definitely much harder than a full PostScript parser. PDF more or less encompasses PostScript. PostScript is much more widely supported than PDF. It is just as extensible as PDF as far as imaging goes. | The major one, of course, is that the file would be essentialy | auto renderable - no need of GIMP, neither of any other program, | to get it printed. | | Assuming a PS printer... | | But most users either have PCL or raster-based printers... Most printers are raster based at the core, except for certain plotters (which are very interesting to watch BTW). Some printing solutions implement the RIP in software on the host computer (such as Ghostscript or Adobe's PressReady -- not sure if the latter has been deprecated by something else). Others implement it on the printer itself, such as a few printers in the HP LaserJet family. More or less, most people are able to print PostScript on their printers on most major operating systems. | Since PSD and TIFF are used by ADOBE, ADOBE also has a program that | makes use of postscript subsets.. I just do not remember which file | type it is. | | Versions of Adobe Illustrator = 8 used a subset of EPS | (Encapsulated Postscript) as its native file format. As of version | 9, it now uses PDF as the file format. | | | It can have color profiling support - it is on the specifications. | It has support for multiple compression standards... (ok, maybe you | have to encode the decompressor algorithm inside the file as well if | you want something too different) | | PS doesn't support plug-in filters... As compared to PDF? In the context of the original poster's comment, what did you have in mind for using plug-in filters? How is the PDF plug-in support useful in any way with image representation? The original poster was talking about color profiles. Mukund ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
On Thu, 14 Aug 2003, Sven Neumann wrote: Hi, 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). PNG is something from the dark ages? 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. s/most/all, and many other good things besides. There was however nothing mentioned that it can do better. Or did I miss something? XML is a text markup language. If the designers thought of using it for raster graphics, it was an afterthought at best. XML is simply the wrong tool for the job. The XML/archive idea is the software equivalent of making a motorcycle by strapping a go-cart engine to the back of a bicycle. It will work, of course, but it's an inelegant hack that will never be as nice as something designed for the job. But to answer your question: 1. Putting metadata right next to the data it describes is a Good Thing. The XML solution arbitrarily separates human readable data from binary data. No one has yet considered what is to be done about non-human readable metadata, but I imagine it will be crammed into the archive file some way, or Base64ed or whatever. Either way is total lossage. 2. Imagine a very large image with a sizeable amount of metadata. If this seems unlikely, imagine you have some useful information stored in parasites. The user in our example only needs to manipulate a handfull of layers. A good way of handling this case is to not load everything into memory. Say that it just parses out the layer list at the start, and then once a layer is selected and the metadata is requested, it is read in. With the XML proposal, the parser would have to parse through every byte until it gets to the part it is interested in, which is inefficient. Frankly, this wouldn't be feasable. Only two crappy ways would be possible to get around this: store everything in memory (hope you have plenty of virtual memory!) or write out a temp file with the metadata in it, for later use, and in a random-accessable format. If you're going to do that, why not do it right the first time and save yourself the trouble? 3. None of the current suggestions for archive formats do a good job with in-place editing. AR can't even do random access. Zip can do an ok job with in-place editing, but it's messy and often no better than writing a whole new file from scratch. This means that a program that makes a small change to a file, such as adding a comment, needs to read in and write a ton of crap. 4. Implementing a reader for the XML/archive combo is unnecessarily complex. It involves writing a parser for the semantics and structure of XML, a parser for the semantics and structure of the archive format, and a parser for the semantics and structure of the combination. It is true that libraries might be found that are suitable for some of the work, but developers of small apps will shun the extra bloat, and such libraries might involve licensing fun. The semantics and structure of the combination is not a trivial aspect -- with a corrupt or buggy file, the XML may not reflect the contents of the archive. With an integrated approach, this is not a concern. 5. Either the individual layers will be stored as valid files in some format, or they will be stored as raw data. If they are stored as true files, they will be needlessly redundant and we will be limited to whatever limitations the data format we choose uses. If we just store raw data in the archive, then it's obvious that this is just a kludge around the crappiness of binary data in XML. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
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) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
On Wed, Aug 13, 2003 at 08:32:00PM -0300, Joao S. O. Bueno wrote: | But on this new thread were proprietary formats batle along with mutant | ideas, here I go: | Why not settle for a Postscript subset? PostScript is a proprietary format controlled by Adobe. Adobe has several patents on various aspects of the PostScript format any implementation would be affected by. | The major one, of course, is that the file would be essentialy auto | renderable - no need of GIMP, neither of any other program, to get it | printed. This is a good idea, but it would also mean GIMP would have to read back a PostScript file. PostScript is a huge standard outside the scope of an application such as the GIMP. Developers would have to put in kludges and special comments which'll help them represent structures which cannot be natively represented using PostScript. Isn't this just as expensive as implementing a new specification? What's more easier? A Have a native file format designed for the GIMP. Those who want to use it with PostScript aware applications export the native format using a plug-in. If XML is used for the underlying data representation, any XML parser can be used to parse information, especially information such as the author of an image, size and colour depth of the image, etc. B Use a subset PostScript as the native file format. Design and implement representation of unrepresentable structures in PostScript comments. Implement a PostScript parser (which is as good as a stack based interpreter). | Since PSD and TIFF are used by ADOBE, ADOBE also has a program that | makes use of postscript subsets.. I just do not remember which file type | it is. | | It can have color profiling support - it is on the specifications. It | has support for multiple compression standards... (ok, maybe you have to | encode the decompressor algorithm inside the file as well if you want | something too different) Support for multiple compression algorithms can be implemented in an XML based format. One can also have data in other image formats such as TIFF, PNG or even the same GIMP native format itself embedded as CDATA, or the file format may be an archive of associated images, etc. The features implemented depend on how far developers want to take the new file format. The developers themselves are capable of doing what they want :-) Mukund ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
At 1:58 PM -0700 8/14/03, Nathan Carl Summers wrote: XML is a text markup language. If the designers thought of using it for raster graphics, it was an afterthought at best. Completely agreed. Putting image data into the XML would be bad... The XML/archive idea is the software equivalent of making a motorcycle by strapping a go-cart engine to the back of a bicycle. Not at all! It's actually an elegant solution to the problem that XML was designed around teh idea of links and NOT around a single file container model. That's why many folks including OpenOffice, Adobe, etc. are using archive formats + XML as future data storage systems - best of both worlds. 1. Putting metadata right next to the data it describes is a Good Thing. right next to is an interesting choice of terms. What does that really mean in a single file. It's in the same file - does it really need to proceed or follow it IMMEDIATELY in byte order? As long as they are in the same physical file, so that one doesn't go w/o ther other - I don't see an issue. But yes, separate physical files woudl be bad! The XML solution arbitrarily separates human readable data from binary data. As it should be. The binary data is for computers, the human readable is for both humans and computers. No one has yet considered what is to be done about non-human readable metadata, but I imagine it will be crammed into the archive file some way, or Base64ed or whatever. I would think it might be based on size - over a certain threshold it goes into the archive, otherwise it's in the XML. Either way is total lossage. Why??? 2. Imagine a very large image with a sizeable amount of metadata. OK. The user in our example only needs to manipulate a handfull of layers. A good way of handling this case is to not load everything into memory. Say that it just parses out the layer list at the start, and then once a layer is selected and the metadata is requested, it is read in. OK. With the XML proposal, the parser would have to parse through every byte until it gets to the part it is interested in, which is inefficient. Parse through the XML, sure - but NOT the archive. But the fact is that you would load the ENTIRE XML into memory (a DOM tree) at document load time - because that's your catalog of information as well as (though not necessary) your metadata store. Perhaps, and this may be where you are going, there shoudl be two XML files - one which is the master catalog and hierarchical organization system and the other which is the metadata itself. 3. None of the current suggestions for archive formats do a good job with in-place editing. AR can't even do random access. Zip can do an ok job with in-place editing, but it's messy and often no better than writing a whole new file from scratch. This means that a program that makes a small change to a file, such as adding a comment, needs to read in and write a ton of crap. Zip does just fine with in place editing and can also be used for incremental update with on-demand garbage collection. (I know, I've used it that way before). 4. Implementing a reader for the XML/archive combo is unnecessarily complex. It involves writing a parser for the semantics and structure of XML, a parser for the semantics and structure of the archive format, and a parser for the semantics and structure of the combination. Well, the XML would be parsed by libxml (most likely) and read into a DOM tree which would then be used in combination with some archive format library to read each piece on demand as necessary. It has also been suggested that libgsf (the library that OpenOffice, AbiWord and Gnumeric all use to handle XML/archive file formats) might be the solution here to handle all of this. It is true that libraries might be found that are suitable for some of the work, but developers of small apps will shun the extra bloat, and such libraries might involve licensing fun. I am pretty sure that GNOME has all of the necessary pieces we'd need - of if not, something could be found. I am pretty sure that if we decide on the archive/XML format, the real work would be in the integration. The semantics and structure of the combination is not a trivial aspect -- with a corrupt or buggy file, the XML may not reflect the contents of the archive. With an integrated approach, this is not a concern. If the XML is the catalog, then inconsistant catalogs are a problem for ANY file format that uses them. This is one of those areas where improved error handling and recovery needs to be utilized. 5. Either the individual layers will be stored as valid files in some format, or they will be stored as raw data. If they are stored as true files, they will be needlessly redundant and we will be limited to whatever limitations the data format we choose uses. If we just store raw data in the archive, then it's obvious that this is just a kludge around the crappiness of binary
