Re: [Gimp-developer] GimpCon RFC: Portable XCF
At 4:37 PM -0700 8/9/03, Nathan Carl Summers wrote: Trees, yes - for things like layers. But why a graph?? GEGL supports graphs. If we use GEGL graphs, we'll need a representation ;) Ah... I haven't seen/used GEGL - just keep hearing about it here on the list as the new imaging engine. I see fast loads as an absolute requirement. Then we need to also look at the GIMP itself and what can be done there. Hopefully, GIMP's file handling will improve to the point where it will load thing on an as-needed basis. Therefore, fast random access is necessary. Having load on demand via random access is what will really get you the fast loads!! If you don't solve that, then any work on the file format will be a waste towards your goal. Being compact is nice as well, because not everyone has 3 terrabyte harddrives and a T3 line into their house. Agreed, but what does this really mean in real world terms. Are we willing to sacrifice functionality to get a couple of bytes here and there? The image data is the big hit in this format - the structure will end up as a small fraction of any XCF file. * incremental update just update a single layer w/o rewriting the whole file! This seems like an excellent goal. It seems like you are suggesting a database-like format. Not necessarily. You should be able to do it with any format with a good catalog system, but some will be easier than others. I think sub-chunks is a bad idea. Although a common way to represent hierarchical relationship, they can also put overhead on random access and also slow down read/write under certain conditions. How about a TIFF-like directory chunk at the beginning (except hierarchical)? That would be one solution - sure. I just think that doing a full reinvent of an image format seems like a waste of time. Let's look at Photoshop... Photoshop is able to do 100% round-tripping of ALL of its functionality in three formats - PSD, TIFF and PDF. PDF is done via throwing their private info into an undocumented blob - so it doesn't really count. So let's look at the other two. Both PSD and TIFF are rich image formats that already address most of your original list and are well defined and supported by many existing tools (including GIMP itself). Both are extensible (TIFF more so) and would allow for additional blocks to meet our needs. Is there a good reason not to use either PSD or TIFF as the native format? The only possible argument for either is that Adobe controls them both. However, I would state that TIFF has pretty much taken on a life of its own outside Adobe (via libtiff). LDR -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
Hello, Everyone :) I've had this problem for the last two development versions of the Gimp: 1.3.17 and 1.3.18 Hopefully, to maximize the clarity of the information that I have to give you, and minimize the size of this e-mail, I will proceed with a series of links to screen shots and brief, appropriate comments. 1. For the sake of accuracy, I first include a screen-shot of GIF that has this problem, as viewed in a non-Gimp application: Gqview 1.3.2 http://www.faith4miracle.org/01-GimpSS-GQVIEW.jpg You will notice that the background is transparent, as represented by the grey/light gray checks. No problem here. 2. Next, I opened up the exact same image with Gimp 1.2.3, the version that ships by default with Red Hat 9: http://www.faith4miracle.org/02-GimpSS-gimp-1.2.3.jpg Just like in example 1, it displays properly. 3. Next, with the exact same image as in all the other examples, the current stable version of the Gimp: Gimp 1.2.5: http://www.faith4miracle.org/03-GimpSS-gimp-1.2.5.jpg Again, no problem. 4. Next, the oldest Gimp development version I have installed on my system: Gimp 1.3.16: http://www.faith4miracle.org/04-GimpSS-gimp-1.3.16.jpg Again, no problem. Here is where the problems start, with Gimp 1.3.17 and 1.3.18: 5. Gimp 1.3.17: http://www.faith4miracle.org/05-GimpSS-gimp-1.3.17.jpg As you can clearly see, the background is now pink. 6. Gimp 1.3.18: http://www.faith4miracle.org/06-GimpSS-gimp-1.3.18.jpg As in example 5, the background is pink. Before I move on, to clarify, in the making of all these screen-shots, I used the exact same image. I can manipulate, copy, paste, etc, the image just fine if I use one of the first three versions of the Gimp mentioned above. But if I edit the image in the two most recent development versions of the Gimp (1.3.17 and 1.3.18), the background permanently becomes pink. If someone were to suggest that there was an issue with the way that I made it (I cropped it using a program in Windows, and exported the actual GIF that you see in the screen-shots from an OpenOffice.org Impress presentation slide.), I would have to point out that it displays and edits perfectly in three of the five versions of the Gimp that I tried it on. If you have any questions for me, I am more than happy to answer anything you may have to ask me. I checked bugzilla.gnome.org and I found nothing but a reference to an apparently similar issue with an animated GIF. When I grabbed that image and opened it up in Gimp 1.3.17 and 1.3.18, I saw absolutely nothing wrong with it. The background is transparent on my system, so as a result, I Assume that my problem is different :) I am running Red Hat 9, with every package installed. (That's almost 1400 packages) I have all the official Red Hat updates installed. As far as gtk+ and gtk2, I have the versions that ship with Red Hat 9 installed. If something relating to a known dependency is affecting Gimp 1.3.17 and 1.3.18 on Red Hat 9, I do apologize and if you say so, I will try upgrading to newer versions. The reason I haven't yet is because I've had really bad luck upgrading Gtk related items in the past. But if you say so, with your expert guidance, I will gladly try again :) Steven P. Ulrick ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Second try
hmm...Agreeded. I'd suggest 10 days instead of 5 (if I, for an example, am on a heavy workload week, 5 days could not be enough to make my points, if they need soem expermenting on the codebase), But since the decision was taken, so mote it be - it's not gonna hurt. As for the foundation., I'd be happy if it was in Europe. USA is getting more and more of those stuppid laws, including states passing super-DMCAs¨ , that if enforced would stop the Internet alltogether. The foundation has to care off one other thing I did not see on the summary: most, or all of the codebase must be owned by it. It would legally allow small adjusts in the license, like the recently one that clarified that there could be proprietary plug-ins for the GIMP. (Strictly in terms of the GPL, as currently the copyright holder is each individual author, there would be the need to have express permission from each author for this change). Also, there is the GNU motive - if the need arises to defend GIMP's IP in court, it is easier if the foundation is the owner, and not a lot of people spread over the world. Off course there must be foolproof safeguards to keep the foundation from doing non-wanted things to the codebase. So, that GIMP should be free software should be specified in the reason of beingof such a foundation. These are my points so far. Cheers, JS -- - Decisions --- Not too many of these... we will have a release manager, but we need to define exactly what his/her remit will be. And who it will be. We agreed that the 5 days and it's dead rule for threads makes sense, so that will be done. - Future 1) Roadmap - rough release schedule, we will have a first draft today. 2) GIMP Foundation - we need to define its responsibilities, set up election rules, and get this set up. The principle of the foundation is more or less agreed. 3) Communication 4) Release Manager - what'll he do, who'll he be. This should be short once we have discussed communication channels a bit. 5) Technie stuff - Sven and mitch are going to talk to us about the re-organisation of the code, GObjectification of everything, and other stuff. Daniel and Calvin are going to talk to us about Gegl and how they feel the GIMP could use it. This will probably be a two-way discussion about what kind of things we expect gegl to furnish as well. 6) GIMP tutorials - jimmac and nomis are going to do some presentations for people, which should be good. 7) Plug-in distribution - 3 years ago this was discussion, yosh has been working on something as a proof-of-concept, it would be nice to address this and get something in place soon. So there you go. Hello everyone from camp. Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
At 6:01 PM -0700 8/8/03, Nathan Carl Summers wrote: Let us start with an existing graphics format, for inspiration if nothing else. OK. The format I chose is PNG, because it is arguably the best existing lossless portable graphics format available. Well, I would argue that TIFF has the crown... However, PNG is an excellent standard, regardless. 4 capable of representing trees and graphs Trees, yes - for things like layers. But why a graph?? 5 recoverable from corruption 6 fast random access of data 9 fast loads and saves 10 compact Good goals, but not a requirements. Perhaps you should separate those two things out... And I can think of other goals that I'd like to see: * incremental update just update a single layer w/o rewriting the whole file! * rich metadata (this may be your 7, but needs to be spelled out) PNG certainly supports 1,2,6,7,9,10, and 11. Let us examine the other issues in more detail. I would argue that PNG doesn't do 7 - it has no native support for CMYK, for example. (but yes, it does RGB, Gray and indexed). And for comparison, I would offer that TIFF does the same list and REALLY does 7, including CMYK, Lab, ICC and Spot color spaces. It's extensibility is similar to PNG (in fact, PNG's chunks were modelled on TIFF chunks). A pure XML format, by way of comparison, would fulfill requirements 1,2,3,4,7, and 8. I'd add 9, just being in XML doesn't mean it can't be fast. Requirement 5 in practice would be difficult to fulfill in a pure XML format without hand-hacking, which is beyound the skills of most users. A zlib-style compression step could make some progress towards 10. But gzipping the entire XML block would then pretty make 6 impossible unless you want to seriously increase in-memory requirements. An archive with XML metadata and png graphical data, on the other hand, would satisfy requirements 1,2,3,4,7,8, and 11. An archive (zip, tar, ar) with XML metadata plus raster image data (ie. my previous proposal) would meet 1,2,3,4,6,7,8,10,11. 5 10 are related to the archive format of choice since some are better at these than others. But yes, I suspect that it would probably be a bit slower. Requirement 6 is fulfilled for simple images, but for more complex images XML does not scale well, since every bite from the begining of the XML file to the place in which the data you are interested in is. But the XML is just a catalog of what's in the archive (at least in my proposal). So you read the catalog up front and then use it to quickly find the part of the archive you want and viola - fast random access to data. It seems like all we have to do is combine the strengths of PNG and the strengths of XML to create a format that satisfies our requirements. What we really need is not an extensible text markup language, but an extensible graphics markup format. That's what TIFF and PNG were designed for. Portable XCF would use a chunk system similar to PNG, with two major differences. First, chunk type would be a string instead of a 32-bit value. Second, chunks can contain an arbitrary number of subchunks, which of course can contain subchunks themselves. I think sub-chunks is a bad idea. Although a common way to represent hierarchical relationship, they can also put overhead on random access and also slow down read/write under certain conditions. At the end of each chunk is a checksum, as well as a close-chunk marker. The purpose of the close-chunk marker is to help recover in case of corruption; if no corruption is detected, the close-chunk marker is ignored. This is a common technique in many file formats for corruption detection. It works. One of the major advantages of this hybred technique is that if an implementation does not understand or is not interested in a particular chunk, it can seek to the next chunk without having to read or parse any of the data in-between. How does it do that? How do you find start of chunk without a catalog? How do you get random access to a particular chunk w/o a catalog? image data chunks should use png-style adaptive predictive compression. They should also use adam-7. Great - but that's not specific to a file format - we can do that anywhere... 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] gimp 1.3.18 - Pink backgrounds on GIF's
Hi. Jeff Trefftzs wrote: Without getting fancy, I just tried this image in gimp-1.3.18 (Linux, RedHat 9). It opened with the pink background Wait, it OPENED with the pink background? You didn't have to save it out again first? -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
On Mon, 11 Aug 2003, Adam D. Moss wrote: IIRC, the Loki guys. Some ramblings a few years ago on the problems of interoperability of game data between windows/mac/linuxx86/linuxalpha/etc over network and on disk. They made a special point of saying something like 'never, ever serialize floats' and it sounded like the voice of experience. Java doesn't seem to have a problem with it. Even poor fools like me who are working on VM's for machines with non-IEEE floats don't have too much of a problem. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Cannot save my work ...
Philippe wrote: (gimp-1.3.16-2.fr / gimp-perl-1.2.3-16) Hi, I am using gimp from rpm package. After making a image, with multiples layers, ans saving it under xcf format, I am trying to save it under PNG or another file type. png does not save layers. I was wondering while I read this if you are trying to save as a png before flattening it. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
Good to get some high-quality feedback. On Sat, 9 Aug 2003, Leonard Rosenthol wrote: At 6:01 PM -0700 8/8/03, Nathan Carl Summers wrote: Let us start with an existing graphics format, for inspiration if nothing else. OK. The format I chose is PNG, because it is arguably the best existing lossless portable graphics format available. Well, I would argue that TIFF has the crown... However, PNG is an excellent standard, regardless. Good point. It can't hurt to take a look at several graphics formats and take the best parts from each of them. 4 capable of representing trees and graphs Trees, yes - for things like layers. But why a graph?? GEGL supports graphs. If we use GEGL graphs, we'll need a representation ;) 5 recoverable from corruption 6 fast random access of data 9 fast loads and saves 10 compact Good goals, but not a requirements. Perhaps you should separate those two things out... I see fast loads as an absolute requirement. Being compact is nice as well, because not everyone has 3 terrabyte harddrives and a T3 line into their house. Hopefully, GIMP's file handling will improve to the point where it will load thing on an as-needed basis. Therefore, fast random access is necessary. A VIPS-like demand-driven pipeline would increase gimp responsiveness a lot. And I can think of other goals that I'd like to see: * incremental update just update a single layer w/o rewriting the whole file! This seems like an excellent goal. It seems like you are suggesting a database-like format. * rich metadata (this may be your 7, but needs to be spelled out) Well, that was what I meant by extensibility and the ablity to represent anything GIMP can. I agree that this is important. PNG certainly supports 1,2,6,7,9,10, and 11. Let us examine the other issues in more detail. I would argue that PNG doesn't do 7 - it has no native support for CMYK, for example. (but yes, it does RGB, Gray and indexed). And for comparison, I would offer that TIFF does the same list and REALLY does 7, including CMYK, Lab, ICC and Spot color spaces. It's extensibility is similar to PNG (in fact, PNG's chunks were modelled on TIFF chunks). Indeed. A pure XML format, by way of comparison, would fulfill requirements 1,2,3,4,7, and 8. I'd add 9, just being in XML doesn't mean it can't be fast. I guess if you used raw image data instead of base64 or something similar Requirement 5 in practice would be difficult to fulfill in a pure XML format without hand-hacking, which is beyound the skills of most users. A zlib-style compression step could make some progress towards 10. But gzipping the entire XML block would then pretty make 6 impossible unless you want to seriously increase in-memory requirements. right. An archive with XML metadata and png graphical data, on the other hand, would satisfy requirements 1,2,3,4,7,8, and 11. An archive (zip, tar, ar) with XML metadata plus raster image data (ie. my previous proposal) would meet 1,2,3,4,6,7,8,10,11. 5 10 are related to the archive format of choice since some are better at these than others. But yes, I suspect that it would probably be a bit slower. Requirement 6 is fulfilled for simple images, but for more complex images XML does not scale well, since every bite from the begining of the XML file to the place in which the data you are interested in is. But the XML is just a catalog of what's in the archive (at least in my proposal). So you read the catalog up front and then use it to quickly find the part of the archive you want and viola - fast random access to data. It seems like all we have to do is combine the strengths of PNG and the strengths of XML to create a format that satisfies our requirements. What we really need is not an extensible text markup language, but an extensible graphics markup format. That's what TIFF and PNG were designed for. Portable XCF would use a chunk system similar to PNG, with two major differences. First, chunk type would be a string instead of a 32-bit value. Second, chunks can contain an arbitrary number of subchunks, which of course can contain subchunks themselves. I think sub-chunks is a bad idea. Although a common way to represent hierarchical relationship, they can also put overhead on random access and also slow down read/write under certain conditions. How about a TIFF-like directory chunk at the beginning (except hierarchical)? At the end of each chunk is a checksum, as well as a close-chunk marker. The purpose of the close-chunk marker is to help recover in case of corruption; if no corruption is detected, the close-chunk marker is ignored. This is a common technique in many file formats for corruption detection. It works. One of the major advantages of this hybred technique is that if an implementation does
Re: [Gimp-developer] gimp 1.3.18 - Pink backgrounds on GIF's
Tom Mraz wrote: It is probably this checkin: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=contextwhitespace_mode=showfile=gifload.cbranch=root=/cvs/gnomesubdir=/gimp/plug-ins/commoncommand=DIFF_FRAMESETrev1=1.30rev2=1.31 The guchar - gchar change without correcting the code using the buf isn't probably good idea? I think you're right. That bogus change totally sneaked under my radar... (heads will roll! :D :D :D ) If someone who sees the problem can test this fix: http://icculus.org/~aspirin/gifload.c that'd be good. Thanks, --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 I am NOT a nut! I am the keeper of the seven universal truths! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
