Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: One thing (to bring this more on-topic again) to note is that vim doesn't handle large (gigabytes) files nice, loading it into memory. The same is probably true for emacs. The only editor I know (I didn't test millions of them though), that nicely handles large files is joe, as it does't load them into memory. QEmacs does this too: http://fabrice.bellard.free.fr/qemacs/ I think it's only for unixoids. Not sure. -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol 10,Issue 18]
On Fri, Jul 18, 2003 at 10:16:27PM +0200, Tomas Ogren [EMAIL PROTECTED] wrote: vim? emacs? .. I bet there are many editors that can handle large text files.. One thing (to bring this more on-topic again) to note is that vim doesn't handle large (gigabytes) files nice, loading it into memory. The same is probably true for emacs. The only editor I know (I didn't test millions of them though), that nicely handles large files is joe, as it does't load them into memory. For images, which might become big especially when storing a lot of extra info (undo info etc.), this is an issue ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
Christopher W. Curtis wrote: The downside to using 'ar', really, is that WinZip doesn't support it. I haven't verified this - I hope a Windows user can do so for us. Just for reference, attached below is a CP of an ar archive I just made: Hmm..that just seens just plain as no downside at all. You see..windows users don't even have a comom tool to edit large ASCII files. Saying that a proprietary tool doesn't support this archive type should be of no concern. They will be able to open the New Gimp File based on ar on Microsoft Word, if there is such a need of a format hackeable by windows users. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
On Thu, Jul 17, 2003 at 09:45:51AM -0700, Manish Singh [EMAIL PROTECTED] wrote: Consider the case of a corrupted xcf file. Maybe only 1 layer out of 20 is corrupted. With this proposal, a user needs either a special tool to (in this case, tar and zip would be preferable over ar, as ar tools are not well-versed at repairing/ignoring corruption, tar/zip tools often are better prepared). which is why I prefer it. zip/jar is especially crappy since the file index is at the end, which means it's harder to recover from a partial file. Actually, zip has all file headers twice: once before the file within the stream, and another time at the end. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: new-xcf [Re: Gimp-developer Digest, Vol 10,Issue 18]
On 18 July, 2003 - Joao S. O. Bueno sent me these 0,8K bytes:
Christopher W. Curtis wrote:
The downside to using 'ar', really, is that WinZip doesn't support it.
I haven't verified this - I hope a Windows user can do so for us. Just
for reference, attached below is a CP of an ar archive I just made:
Hmm..that just seens just plain as no downside at all.
You see..windows users don't even have a comom tool to edit
large ASCII files.
vim? emacs? .. I bet there are many editors that can handle large text
files..
/Tomas
--
Tomas Ögren, [EMAIL PROTECTED], http://www.ing.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
On Wed, Jul 16, 2003 at 06:19:27PM +0200, Sven Neumann wrote:
HOWEVER, this might be a good time to think about whether we'd
prefer a compressed format that we can random-access de/compress
on the fly instead of going via a huge (and with image data we
can easily be talking HUGE) temporary intermediate file.
If we would compress the image data in the archive there would be no
need for compression of the archive. Sure you could gain a few bytes
by compressing the XML but since the already compressed image data
doesn't compress well and in the worst case even gets larger, I don't
see why anyone would want to compress the archive.
Agreed.
I have a more concrete suggestion (I'm still favoring ZIP files because
they can somehow be handled without a GIMP which is useful, e.g. if they
are broken): Make an uncompressed ZIP (or maybe compress the XML part
only). The XML describes the structure and all attributes.
GIMP-Image.ZIP
|
+- image.xml
|
+- comment.{txt,html,xml}
|
+- layer1.png (stored uncompressed)
|
+- layer1.1.png
|
+- layer2.png
...
|
+- image-thumbnail.png (optional)
|
+- whole-image.png (flattened image, optional)
IMO this is a sane approach. It has lots of benefits:
- image contents are accessible without a GIMP
- thumbnails can be extracted easily
- a user can mess with the image
- images could be generated with external tools
(just create the XML, add some images as layers, here you are)
- it could be scanned for Java-viruses :-
Bye, Tino.
--
* LINUX - Where do you want to be tomorrow? *
http://www.tu-chemnitz.de/linux/tag/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
Hi, Christopher W. Curtis [EMAIL PROTECTED] writes: The nice thing about this is that it should be fully parseable by XML parsers (up until the first NULL [1 is required, the rest are optional I don't think the format you proposed is valid XML. There might be XML parsers that are able to read it but it violates the spec. If I am wrong here, please show me where the spec defines the special role of the NULL character. Is there a special reason you dislike the idea of using an archive instead of a single XML file? I thought we would have been past this point already... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
Sven Neumann wrote: Christopher W. Curtis [EMAIL PROTECTED] writes: The nice thing about this is that it should be fully parseable by XML parsers (up until the first NULL [1 is required, the rest are optional I don't think the format you proposed is valid XML. There might be XML Rule #1 in brainstorming: don't criticise any idea, no matter how silly. parsers that are able to read it but it violates the spec. If I am wrong here, please show me where the spec defines the special role of the NULL character. I would reiterate what I said, but you quoted it. fully parseable by XML parsers up until the first NULL. I'm not trying to jam image data into an XML format - simply prepending an XML header and using NULL as a separator. This means you can cat the file and know exactly what's there. Or you can open it in notepad (maybe make it NULL, ^Z for Windows people...) file will be able to readily identify the individual formats, and people could even use dd to extract the layers. Is there a special reason you dislike the idea of using an archive instead of a single XML file? I thought we would have been past this point already... I just don't see using another archive format as giving you anything. So say you use ZIP or JAR or TAR or AR: you still have to unpack (and possibly decompress) the thing just to find out what's in it. OTOH, any program that can open a file can read the XML header here, even if they don't parse it, it's still human readable. And this lets you do your fancy compression-based-on-data-type instead of generic-text-compression over each layer or the whole archive. If you want something fast, you can leave compression off and modify the data directly on disk without having to unpack/pack, as long as you stay within limits (ie: you can paint on a layer or move the layer around, but not add a new layer or change the bit-depth, and you just have to munmap() that section). This makes it easy to have specialized external tools that manipulate layer data without all the GIMP overhead, easily scriptable, etc... This would also be a much simpler format, and I like simple. If you want to talk about downsides, I can think of only one: the first data offset is not predictable. But I assert that that is irrelevant because you can specify it to be anywhere. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
Hi, Christopher Curtis [EMAIL PROTECTED] writes: I would reiterate what I said, but you quoted it. fully parseable by XML parsers up until the first NULL. I'm not trying to jam image data into an XML format - simply prepending an XML header and using NULL as a separator. This means you can cat the file and know exactly what's there. Or you can open it in notepad (maybe make it NULL, ^Z for Windows people...) file will be able to readily identify the individual formats, and people could even use dd to extract the layers. But you couldn't use any generic XML tools like validators or XSL transformations. If we go for XML we should really make sure that we make it proper XML, otherwise XML doesn't make sense at all. We could then as well go for a sexp syntax. Actually the latter would be a lot easier to implement since we could build on the established GimpConfig framework. Is there a special reason you dislike the idea of using an archive instead of a single XML file? I thought we would have been past this point already... I just don't see using another archive format as giving you anything. So say you use ZIP or JAR or TAR or AR: you still have to unpack (and possibly decompress) the thing just to find out what's in it. You don't have to unpack the whole archive and you can use existing widely-available tools to extract the parts you need. OTOH, any program that can open a file can read the XML header here, even if they don't parse it, it's still human readable. And this lets you do your fancy compression-based-on-data-type instead of generic-text-compression over each layer or the whole archive. If you want something fast, you can leave compression off and modify the data directly on disk without having to unpack/pack, as long as you stay within limits (ie: you can paint on a layer or move the layer around, but not add a new layer or change the bit-depth, and you just have to munmap() that section). This makes it easy to have specialized external tools that manipulate layer data without all the GIMP overhead, easily scriptable, etc... You can do all this with an uncompressed archive as I suggested. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
Manish Singh wrote: On Thu, Jul 17, 2003 at 12:06:12PM -0400, Christopher Curtis wrote: Rule #1 in brainstorming: don't criticise any idea, no matter how silly. So much for rules... Another downside: needing a special tool to manipulate it. Well, now, I want to end this silliness right here. Here's what you need to manipulate files in my propsed format: (cat and dd), or (vi), or (type and wordpad). There are no tools more standard than these. Consider the case of a corrupted xcf file. Maybe only 1 layer out of 20 is corrupted. With this proposal, a user needs either a special tool to extract out the good layers, or do a lot of work by hand to figure out how to use dd to grab it. With this format, a tool like the gimp can say layer X is corrupt and the user would have to do something crazy like edit the file with vi and delete the ``layer type=corrupt ... /layer'' section from the XML header. With say ar, the user can extract individual layers by some tag, referenced in the xml metadata. Then can edit the xml to stub out the broken layer, and repack it and have a valid xcf file. This could be the difference between losing 10% of the work vs. all of it. Ahh yes, this way all the user has to do is: ar x file look for the right xml and edit it out or something based on some tag (I'm so glad this is so well thought out...) ar a file everythingelse1,2,3 Won't the Windows people be happy that they can do this instead of just opening a friggin binary-safe text editor. So while a user can open a text file header in an editor, they are going to need a tool anyway to manipulate it effectively. Yeah - it's called the same text editor. That's the advantage of using a standard format. Using standard tools to manipulate it. More likelihood of a machine having a tool installed, and less work for the GIMP team in maintaining special tools. taptaptap ... is this thing on? You're right about simplicity though -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
Sven Neumann wrote: Hi, But you couldn't use any generic XML tools like validators or XSL transformations. If we go for XML we should really make sure that we make it proper XML, otherwise XML doesn't make sense at all. We could then as well go for a sexp syntax. Actually the latter would be a lot easier to implement since we could build on the established GimpConfig framework. I'm not going to argue it. I disagree that an XML preamble is useless becuase you can't XSLT the entire file just as much as I'd disagree if you said that saving a file to disk is useless because it's not a full core image. You don't have to unpack the whole archive and you can use existing widely-available tools to extract the parts you need. Fair enough. When I save a file, I typically need the whole thing. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
Ok .. I want to apologise to everyone for overreacting. After a brief moment of reflection, a simple container has notable advantages over a single file, not to mention that a one of my assumptions didn't make sense. Where is there documentation on the ar format? I can't seem to find any. I'd like to read up on it some before commenting further... Thanks, Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
On Thu, 17 Jul 2003 [EMAIL PROTECTED] wrote: If we really are in brainstorming mode here, following the suggestions listed above, how about a format something like the following, which is essentially just an XML preamble, followed by raw binary data: The nice thing about this is that it should be fully parseable by XML parsers (up until the first NULL [1 is required, the rest are optional Fully parseable XML until it is isn't :) It is far better not to XML at all than to break XML. (incidentally this is similar to what has been suggested for Cinepaint). The proper XML way to do what you describe would be to take the raw binary and base 64 encode it (ick) which is grossly inefficient for anything large. The more sensible way and still valid way is to use a container format and to link to the raw BLOB (binary large object) that would be another file in your container format. I just don't see using another archive format as giving you anything. So say you use ZIP or JAR or TAR or AR: you still have to unpack (and possibly decompress) the thing just to find out what's in it. OTOH, any Using Zip as a container is not On The Other Hand, it does not prevent any of the things you are suggesting. Zip allows you to grab just one file out of the archive if that is all you want, you can have differnt files inside a Zip archive each with different amounts of compression (including no compression). program that can open a file can read the XML header here, even if they don't parse it, it's still human readable. And this lets you do your run 'head' on an OpenOffice document and you will see that the manifest is left uncompresses so that you can easily read it as text. fancy compression-based-on-data-type instead of generic-text-compression over each layer or the whole archive. If GIMP were to use Zip/Jar only as a conatianer and not use the Zip compression then the whole container could be compressed using different / better compression if that is what you want. (I say better very guardedly because compression is often a trade off against how long you want to spend compressing or decompressing). yosh wrote: data offset is not predictable. But I assert that that is irrelevant because you can specify it to be anywhere. Another downside: needing a special tool to manipulate it. To reiterate what Yosh said, Needing specialised external tools would require more developement work, and add complexity not make things simpler. By reusing standards you can leverage existing tools, libraries and other peoples work, leaving more time to focus on image manipulation. That's the advantage of using a standard format. Using standard tools to manipulate it. More likelihood of a machine having a tool installed, and less work for the GIMP team in maintaining special tools. You're right about simplicity though, and ar is simpler than tar or zip/jar, which is why I prefer it. zip/jar is especially crappy since the file index is at the end, which means it's harder to recover from a partial file. I think the JAR format gets around the Zip crappiness by putting the manifest.xml at the start of the file. I could not say how hard it is but Winzip seems to do a pretty good job of repairing any broken zip archives I throw at it, at least allowing me to get some of the files out. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
Alan Horkan wrote: It is far better not to XML at all than to break XML. (incidentally this is similar to what has been suggested for Cinepaint). Just for the record ... I read the CinePaint file format, and it doesn't even resemble XML. My PREAMBLE is valid XML. If they implement what they have written, they don't even bother with things like closing tags or putting parameters in quotes. The proper XML way to do what you describe would be to take the raw binary and base 64 encode it (ick) which is grossly inefficient for anything Which is why I said preamble. large. The more sensible way and still valid way is to use a container format and to link to the raw BLOB (binary large object) that would be another file in your container format. Which is what, at this point, I would prefer. OTOH, any Using Zip as a container is not On The Other Hand, it does not prevent any of the things you are suggesting. Using a container at all is OTOH. run 'head' on an OpenOffice document and you will see that the manifest is left uncompresses so that you can easily read it as text. OpenOffice documents are zipped; you can't head them. btw: META-INF/manifest.xml is at the end of my .sxi file. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
Manish Singh [EMAIL PROTECTED] writes: I don't see a compelling argument to use zip/jar. It's complexity that doesn't buy us anything over ar. $ ar t gimp1.2-print_4.2.5-4_i386.deb debian-binary control.tar.gz data.tar.gz The Debian dpkg .deb package format uses an ar archive with gzip compressed members. It's very robust, and it's simple to extract information from any of the members as needed. e.g. $ ar p gimp1.2-print_4.2.5-4_i386.deb control.tar.gz | tar xfz - ./md5sums $ cat md5sums 3698d1f4ce3025bc8c0af73aad39c351 usr/lib/gimp/1.2/plug-ins/print a9e993933c62cf972a07ba60d099a5be usr/share/doc/gimp1.2-print/html/FAQ.html 0f06e25e158d58be369f6c81c74f350f usr/share/doc/gimp1.2-print/html/print-color.png 8af9040e743fdea01d048a9625be3f37 usr/share/doc/gimp1.2-print/html/print-main.png 9bcaba3b091edb324a4e3658d3b4c17b usr/share/doc/gimp1.2-print/html/print-setup.png bdb27f0b9e600cbf067b34d26b62727b usr/share/doc/gimp1.2-print/samples/colorbars4.png cd6014ab378eeebbaee1723b78ef4459 usr/share/doc/gimp1.2-print/samples/colorsweep.png a9e993933c62cf972a07ba60d099a5be usr/share/doc/gimp1.2-print/FAQ.html d41331233e7703ff0c7f365a1f1fa2a4 usr/share/doc/gimp1.2-print/README.Debian 37ae0a31af00c0fa8569104c96927391 usr/share/doc/gimp1.2-print/copyright 9581201d2bf1fc7b5fcf4c3463d79854 usr/share/doc/gimp1.2-print/changelog.gz 7b58392e6bc678907651c89bdb134763 usr/share/doc/gimp1.2-print/README.gz 5fa90d8012eebb8038dd991d46155ff5 usr/share/doc/gimp1.2-print/changelog.Debian.gz -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
On Thu, 17 Jul 2003, Roger Leigh wrote: Date: Thu, 17 Jul 2003 22:22:17 +0100 From: Roger Leigh [EMAIL PROTECTED] To: Manish Singh [EMAIL PROTECTED] Cc: Alan Horkan [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol 10, Issue 18] Manish Singh [EMAIL PROTECTED] writes: I don't see a compelling argument to use zip/jar. It's complexity that doesn't buy us anything over ar. $ ar t gimp1.2-print_4.2.5-4_i386.deb debian-binary control.tar.gz data.tar.gz The Debian dpkg .deb package format uses an ar archive with gzip compressed members. It's very robust, and it's simple to extract information from any of the members as needed. e.g. $ ar p gimp1.2-print_4.2.5-4_i386.deb control.tar.gz | tar xfz - ./md5sums you used a pipe what happened there is that you just unzipped the entire archive then in a seperate operation you extracted just the files you wanted. there is nothing wrong with that, you get better compression that way. In a zip archive you really do just extract the single file, there is no unzipping of the whole archive first, which is useful if you just want to grab one or two files quickly from a large archive. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
On Thu, 17 Jul 2003, Christopher Curtis wrote: Date: Thu, 17 Jul 2003 17:10:02 -0400 From: Christopher Curtis [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol 10, Issue 18] It is far better not to XML at all than to break XML. (incidentally this is similar to what has been suggested for Cinepaint). even resemble XML. My PREAMBLE is valid XML. If they implement what they have written, they don't even bother with things like closing tags or putting parameters in quotes. A preamble, which is effectively full XML file, a boundry then more information which is effectively another file. Two files in one file, sounds like an ad-hoc container to me. Which is what, at this point, I would prefer. OTOH, any Using Zip as a container is not On The Other Hand, it does not prevent any of the things you are suggesting. Using a container at all is OTOH. run 'head' on an OpenOffice document and you will see that the manifest is left uncompresses so that you can easily read it as text. OpenOffice documents are zipped; you can't head them. btw: META-INF/manifest.xml is at the end of my .sxi file. I made a terrible mistake of generalising from one instance. It is doable it but it was just coincidental in that it was done that way in the file I looked at. While I am apologising, I may as well repeat what I said offlist. I only used Winzip as an example, there are several programs which can recover parts of zip files, so repairing damaged zip files is possible (although I cant guess how difficult it is do it). I expect there must be command line tool for unix zip files, i just dont happen to know what it is yet. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
On 07/17/03 19:41, Alan Horkan wrote: On Thu, 17 Jul 2003, Christopher Curtis wrote: even resemble XML. My PREAMBLE is valid XML. If they implement what they have written, they don't even bother with things like closing tags or putting parameters in quotes. A preamble, which is effectively full XML file, a boundry then more information which is effectively another file. Two files in one file, sounds like an ad-hoc container to me. As interesting as what I said was, I don't see how your comment logically follows. Anyway ... I only used Winzip as an example, there are several programs which can recover parts of zip files, so repairing damaged zip files is possible (although I cant guess how difficult it is do it). This is something that shouldn't really be an issue. The ZIP format keeps the list of files at the end, so that if the file is clipped, the directory is lost, and you can recreate it by scanning the archive for delimiters. The reason it can be repared at all is because the most likely thing to get lost is the meta-information. So, after some research, I've decided that ar is a fine container format. My only conribution, which you may take as you will, would be to specify that the first entry in the archive is the descriptive catalog. Naturally I'm thinking the XML snippet I stated earlier, sans the data offset thing. The advantage to this is that you can detect if the file is corrupt, and you have two ways or accessing data: via meta-information only, or via the actual data entry. This means there's no need to scan through the archive to find its contents, and means that you can read the file using more and it works fine (as long as the XML file is uncompressed). The downside to using 'ar', really, is that WinZip doesn't support it. I haven't verified this - I hope a Windows user can do so for us. Just for reference, attached below is a CP of an ar archive I just made: bash-2.05b$ echo 1 file1 bash-2.05b$ echo 2 file2 bash-2.05b$ ar r myar.xcf file* bash-2.05b$ (echo --; cat myar.xcf; echo --) -- !arch file1/ 1058492021 1000 1000 100644 2 ` 1 file2/ 1058492025 1000 1000 100644 2 ` 2 -- Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: new-xcf
Hi, Adam D. Moss [EMAIL PROTECTED] writes: HOWEVER, this might be a good time to think about whether we'd prefer a compressed format that we can random-access de/compress on the fly instead of going via a huge (and with image data we can easily be talking HUGE) temporary intermediate file. If we would compress the image data in the archive there would be no need for compression of the archive. Sure you could gain a few bytes by compressing the XML but since the already compressed image data doesn't compress well and in the worst case even gets larger, I don't see why anyone would want to compress the archive. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: new-xcf
Hi, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: If we would design our own extremely simple wrapper format there would be no need to work with the compatibility mess existing formats are (all of them :). If we say that access by other tools than gimp is not important we could get away with an extremely simple format, say, cat files*, index at end which could be just offset and length, indexed by number, meta-info is all handled by an xml sub-file. The question is simply wether it should be a standard format or not. I would really like to see a format that is suited to serve as a more general exchange format for image data. If possible it should not be designed as a GIMP-only format. People already use XCF in other apps simply because there is no reasonable format for layered images. So there's seems to be a need for such a format which is why I would like to make access to it as simple as possible. Of course this goal could also be achieved by providing a library that handles whatever weirdo binary format we come up with... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: new-xcf (was:Re: GIMP GBR format spec)
[EMAIL PROTECTED] (2003-07-16 at 2223.29 +0200): If we would design our own extremely simple wrapper format there would be no need to work with the compatibility mess existing formats are (all of them :). If we say that access by other tools than gimp is not important Brainstorming, a dir named .xcf2 with the proposed contents inside? :] GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
On Wed, Jul 16, 2003 at 10:43:13PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: designed as a GIMP-only format. People already use XCF in other apps simply because there is no reasonable format for layered images. That is not true. MIFF was around for years, for example, was always able to store layers, animations, and an unlimited amount of meta information. There are probably others, too. XCF isn't the first (nor the most open) format for this task (and it wasn't intended as one). there's seems to be a need for such a format which is why I would like to make access to it as simple as possible. This, of course, is a good goal in it's own. However: - maybe there is a need to have a gimp-specific file format, especially when you want to store the image data in a non-trivial way to speed up access. - maybe there is a need to have a nicely defined exchange format for complex images (xml + data is nicer than the ad-hoc design of miff). These are conflicting goals. Realisticelly, however, it'll be a long time till gimp wants a special, optimized on-disk format. (as for a format, miff is basically line-based header + image data, iterated, which is very nice... it'S not nifty XML, but the fatc that image data and metadata are grouped so near to each other is also nice...) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: new-xcf
On 07/16/03 20:26, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: - maybe there is a need to have a gimp-specific file format, especially when you want to store the image data in a non-trivial way to speed up access. - maybe there is a need to have a nicely defined exchange format for complex images (xml + data is nicer than the ad-hoc design of miff). If we really are in brainstorming mode here, following the suggestions listed above, how about a format something like the following, which is essentially just an XML preamble, followed by raw binary data: gimp type=image version=1.0 nameMy Example Image/name authorChristopher W. Curtis/author descriptionA big, purple, E/description date format=logical2003/07/18/date copyright2003 FSF, All Rights Reserved/copyright layer name=Background mode=overlay opacity=0% dimensions width=800 height=600 / origin x=0 y=0 / data offset=2000 format=RGBA bpp=12 / /layer [...] /gimp \000\000\000 [...] \000 until file offset=2000 raw binary data The nice thing about this is that it should be fully parseable by XML parsers (up until the first NULL [1 is required, the rest are optional buffer space for those too lazy to do math]), it is completely human readable and very descriptive, highly extensible, and fully functional. You can add an encoding= or compression= option, specifying none, bzip2, or whatever, or even format= and jpg (at the layer mode, making the dimension, etc. tags optional; you'd still need data offset, etc.) The other nice thing is that you can just read the header, and load the rest of the layers on demand (for other 'preview' tools or what have you), and it can be used for other items as well. Instead of type=image you can have type=brush, etc. Maybe even add an attribute like thumbnail format=jpg offset=12580 /. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
