Re: [Gimp-developer] EXIF information in JPEG files
On Wed, 06 Feb 2002, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: On Wed, Feb 06, 2002 at 02:17:21PM +0100, Raphael Quinet [EMAIL PROTECTED] wrote: EXIF data and simply copy the descriptions given in the EXIF standard. Some of the fields will have to be discarded (or set read-only or not persistent) because they only make sense for the original file format It might hurt, but I think the best thing is to not attach these values at all, as there is no semantics attached to them until the core recognizes and modifies them properly on edits (at least for most values). A large part of the EXIF data can be useful for other plug-ins, so it would use the gimp-* namespace for the parasites the semantics of each parasite would be known. Other parts of the EXIF data are less interesting, usually because they describe some properties of the file format that would be changed when the image is saved into a new file (for example, RowsPerStrip, SamplesPerPixel, JPEGInterchangeFormatLength). I think that we should use non-persistent parasites for these parts. The data would not be saved in a new file (unless it is reconstructed by the JPEG/EXIF plug-in) but it would be available after the image has been loaded. Even if the core does not make use of this information, it could still be displayed to the user by a File-Properties plug-in. The dialog window created by this plug-in could provide several tabs that are specific to some file formats. There would be at least one or two tabs for the EXIF data, even for the non-persistent parts. I think that it would be very interesting for the user to know a bit more about the properties of the original file, even if these properties are lost after the conversion to a flat RGB bitmap. Even tools such as ImageMagick's identify do not always provide the information that I am looking for, although I know that it is loaded and parsed by the application. The biggest problem is the format inside parasites - i personally dislike gserialize (unused anyway), and strongly favour very simple decomposing, i.e. scalars (single-valued string-thingy) where possible. So the more parasites the better ;) I fully agree. All pieces of metadata can be decomposed to strings or single numbers. Blocks of raw data should also be allowed for special cases such as ICC color profiles, but only if these blocks are following a well-specified format (including endianness and other things that could cause problems on different platforms). As Sven has already suggested, all text strings should use UTF-8 encoding. It would be up to each plug-in to convert whatever is appropriate for each file format to/from UTF-8 if necessary. Currently, even the usage of gimp-comment causes some problems because some file formats (such as PNG) require ISO-8859-1 (Latin-1) for the character set, some say that the comment should be encoded in the user's current character set (how do you exchange files with others, then?), some others require 7-bit ASCII and most of them do not specify anything. These strings should not have any constraints regarding their length or format (single line or multiple lines of text). It should be up to each plug-in to do the appropriate conversions if necessary. On Wed, 06 Feb 2002, Sven Neumann [EMAIL PROTECTED] wrote: And the most natural place for this is parasites, [...] exactly. If there's a need to improve the current parasites, let's do that now. I could imagine that a more hierachical structure might help, but I'd like to see a real usage case before we consider doing such a change. Is the EXIF data such a usage case? No, all parts of the EXIF data can be stored in a flat list without losing any information. There are some sub-structures such as the GPSInfo, but that can easily be flattened as long as all parasites start with the same prefix (gimp-gps-latitude, gimp-gps-longitude, gimp-gps-img-direction and so on). I had a look at some other file formats that can contain significant amounts of metadata (PNG, TIFF, TGA) and I did not see anything that would require more hierarchical structures. This is not completely true because TIFF can be arbitrarily complex, but we will probably never try to cover all sub-formats of the TIFF standard. -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On , 7 Feb 2002, Sven Neumann wrote: exactly. If there's a need to improve the current parasites, let's do that now. I could imagine that a more hierachical structure might help, but I'd like to see a real usage case before we consider doing such a change. Is the EXIF data such a usage case? Uh - it already *is* hierarchical: that's exactly what: gimp-* gimp-exif-* etc are! It's hierarchical by convention, and this isn't checked, sure. But it's quick and easy. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
On Thu, 07 Feb 2002, Jon Winters wrote: Went to an Adobe conference yesterday and they claim photoshop 6 has been tested with images up to 8000 layers. They said it can probably handle more but that is where they stopped testing. How many layers are we supporting? (heh... memory is cheap!) Is there a limit? Does anybody have a machine with more than 4 GB of RAM to do some serious testing? ;-) The other biggie was limited support for _vector_ stuff. Mainly type but you are also able to import layers from Illustrator files. It would be kinda cool to pull in gfig elements and keep them as vector layers when the image is saved as .xcf.gz The vector layers would be rasterized as part of export to some other image format. [...] I've seen requests for some of this functionality before and I've also seen gimp developers belly ache about it. I know Gimp is a bitmap program... I also know Photoshop _used_to_be_ a bitmap program and now their users have some really nice tools that I would like to see in the Gimp some day. There are several wishlist items related to the support for vectors. Start with this one: http://bugzilla.gnome.org/show_bug.cgi?id=68915 ...and then follow the links to bug #61786, #6893 and #70499. Some time ago, I also thought that the GIMP was a bitmap program and should not mess with vectors, except for selections (paths). But now I have changed my mind. If you look at the commercial programs on the market today, most of the major paint programs have integrated more and mode vector functions: JASC's PaintShopPro, Adobe PhotoShop, the Corel suite, and probably others. We need a big merge and re-write of GFig, GDynText, the FreeType plug-in, the Path tool and the layers dialog in order to make all of this possible. This is not a trivial task. I am not opposed to it and I think that it would be a very good idea. Unfortunately, nothing will happen until someone has the time (and skills) to implement these nice features. Until then... Keep up the Good Work! GO WILBUR! GO WILBER! Wilber, not Wilbur! ;-) -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Thu, Feb 07, 2002 at 04:09:01PM +0100, Dave Neary [EMAIL PROTECTED] wrote: This is untrue (or at least, true only by convention). There's a solid argument (your mail is horribly mis-formatted and very hard to read, btw) that all metadata is plug-in independant, and therefore belongs in the gimp- Why is metadata plug-in independent? group. But there's nothing that forces people to honour any parasite naming Yes there is, it's called rules and conventions. The gimp is not about bondage and discipline. convention. I could write a plug-in that creates a parasite with a name not starting with gimp- and uise it in the core, or with the name gimp- and use it only in one plug-in. You could. You could also send the gimp process a kill signal at anytime. That doesn't make it correct, or right to do. one or 50 doesn't really matter, as long as it's documented. That's the major part of the problem. If someone adds metadata that's not documented, that's a problem. Yes. It's a problem because there's no one place that someone can go and say that they have the definitivelist of parasites. Sure, the documentation. That's fine if there are only a few, but if there are many, tracking them becomes a chore. And more it leads to the possibility of inconsistency. Another abstraction layer, of course, doesn't help getting rid of inconsistency. Yes, it does. We would have one parasite, named something original like gimp-image-metadata, and in one header file somewhere we would have the definition of the gimp-image-metadata structure, and the prototypes of the parsing functions.If someone added an extra bit of metadata and forgot to document it in the docs, well it's there in the code in the one place where all the fields supported in the metadata are - one place, definitive. So what does this buy us, apart from anothe rlevel of indiraction, to the current approach which also does all this? The parasites provide a namespace for this. Inventing yet-another-metadata-in-metadata-abstraction doesn't buy clarity. Perhaps not, but it buys consistency. You repeat this again and again. But people fail to see this. That's fine, when the documentation is accurate - if it lags behind anyone who thinks it doesn't is living in a dreaml world) it becomes best redundant and at worst misleading. Adding yet another place where this has to be documented does not, in my eyes, improve the situation. No, because the PNG developer has the definitive list of parasitres in the image metadata definition. If he's adding a new bit of metadata he's adding it there. And in that case, the duplication should be obvious. the definitive list and adding new bit of metadata contradict each other, at least in my mind. If someone could convince me that there were a way to get a list of all the parasites in use in the gimp (core and plug-ins) using the current structure of things, then I'd probably go along. I just have this use grep ;) vision of having a gimp-image-metadata-author in one plug-in, and gimp-metadata-author in another, and gimp-image-author in another, If you mean that this should not happen, I agree. But how would the other approach help this? One author could add a author field and another an image-author field to the structure. Again, another level of abstraction doesn't help at all. Either one avoids these bugs, or not. and so on. Possibly not for something as obvious as that, but you get my point. Yes, but instead you should gice points on why another metadata layer would solve the existing problems. IMnsHO doing the same thing in a slightly different way only increases the places where problems occur. -- -==- | ==-- _ | ---==---(_)__ __ __ 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: [Gimp-user] Opening Photoshop Files
On 7 Feb 2002, at 9:29, Jon Winters wrote: Went to an Adobe conference yesterday and they claim photoshop 6 has been tested with images up to 8000 layers. They said it can probably handle more but that is where they stopped testing. How many layers are we supporting? (heh... memory is cheap!) My GIMP crashed somewhere between the 300th and 400th 16x16 layer. I could not see exactly which layer, because I kept stabbing the mouse button quickly and after the 100th layer or so, the refresh of the Layers dialog could not keep up with me. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
Hi, Raphael Quinet [EMAIL PROTECTED] writes: We need a big merge and re-write of GFig, GDynText, the FreeType plug-in, the Path tool and the layers dialog in order to make all of this possible. This is not a trivial task. I am not opposed to it and I think that it would be a very good idea. Unfortunately, nothing will happen until someone has the time (and skills) to implement these nice features. I hope do be able to complete the new text tool anytime soon and it is supposed to give you even better rendering than gimp-freetype combined with the features of GDynText. Development on this tool has stalled a little but I'm planning to take up work on it soon. Let's see what we can do about the path tool. Simon started to hack on this, but I have no idea how far he's come. On the other hand we should probably decide on the feature-set for 1.4 soon and I don't think we should try to add sophisticated stuff like vector layers to 1.4 since it would probably delay the release too much. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How's CVS-HEAD?
Sven Neumann wrote: mct:~ gimp-1.3 gimp-1.3: fatal error: Segmentation fault gimp-1.3 (pid:9613): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s #0 0x40550924 in g_on_error_stack_trace (prg_name=0xb833 gimp-1.3) #1 0x4055083e in g_on_error_query (prg_name=0xb833 gimp-1.3) #2 0x80816cd in gimp_eek (reason=0x819cea8 fatal error, #3 0x808162e in gimp_fatal_error (fmt=0x40676e90 Segmentation fault) #4 0x8081225 in gimp_sigfatal_handler (sig_num=11) at main.c:501 #5 0x405c7858 in sigaction () from /lib/libc.so.6 #6 0x40564428 in g_main_context_iterate (context=0x8243550, block=0, #7 0x40564635 in g_main_context_pending (context=0x0) at gmain.c:2261 #8 0x40129e8e in gtk_events_pending () at gtkmain.c:863 #9 0x808e980 in user_install_continue_callback (widget=0x825e568, well, naturally I can't reproduce this here. I've removed my ~/.gimp-1.3 directory and was able to finish user installation w/o a problem. I can't see anything wrong with the code either: while (gtk_events_pending ()) gtk_main_iteration (); The crash is actually occurring inside gtk/glib-1.3 (joy!) but I haven't de-toxed enough yet to look deeper. *looks deeper anyway* Ah cool, a glib rebuild from today's HEAD stops me crashing. Thanks, now I almost have a working gimp! (After the current recompile, hopefully!) -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 But not us (no never) no not us (no never) We are far too young and clever ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How's CVS-HEAD?
On Thu, Feb 07, 2002 at 08:06:19PM +, Adam D. Moss wrote: Sven Neumann wrote: mct:~ gimp-1.3 gimp-1.3: fatal error: Segmentation fault gimp-1.3 (pid:9613): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s #0 0x40550924 in g_on_error_stack_trace (prg_name=0xb833 gimp-1.3) #1 0x4055083e in g_on_error_query (prg_name=0xb833 gimp-1.3) #2 0x80816cd in gimp_eek (reason=0x819cea8 fatal error, #3 0x808162e in gimp_fatal_error (fmt=0x40676e90 Segmentation fault) #4 0x8081225 in gimp_sigfatal_handler (sig_num=11) at main.c:501 #5 0x405c7858 in sigaction () from /lib/libc.so.6 #6 0x40564428 in g_main_context_iterate (context=0x8243550, block=0, #7 0x40564635 in g_main_context_pending (context=0x0) at gmain.c:2261 #8 0x40129e8e in gtk_events_pending () at gtkmain.c:863 #9 0x808e980 in user_install_continue_callback (widget=0x825e568, well, naturally I can't reproduce this here. I've removed my ~/.gimp-1.3 directory and was able to finish user installation w/o a problem. I can't see anything wrong with the code either: while (gtk_events_pending ()) gtk_main_iteration (); The crash is actually occurring inside gtk/glib-1.3 (joy!) but I haven't de-toxed enough yet to look deeper. *looks deeper anyway* Ah cool, a glib rebuild from today's HEAD stops me crashing. Thanks, now I almost have a working gimp! (After the current recompile, hopefully!) I doubt it's a gimp issue. Owen broke some main loop stuff for about a day in CVS. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How's CVS-HEAD?
essai ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
Hi, Branko Collin [EMAIL PROTECTED] writes: On 7 Feb 2002, at 9:29, Jon Winters wrote: Went to an Adobe conference yesterday and they claim photoshop 6 has been tested with images up to 8000 layers. They said it can probably handle more but that is where they stopped testing. How many layers are we supporting? (heh... memory is cheap!) My GIMP crashed somewhere between the 300th and 400th 16x16 layer. I could not see exactly which layer, because I kept stabbing the mouse button quickly and after the 100th layer or so, the refresh of the Layers dialog could not keep up with me. Script-Fu is still adding layers while I write this and the count is approaching 4000 layers of 16x16 pixels here. At the moment gimp uses about 330MB of virtual memory (256MB physical RAM). The script has (gimp-displays-flush) after (gimp-image-add-layer ...), so the layers dialog is fighting to keep up with the amount of layers and the scrollbar already shows that GTK+-1.2 has a problem with X coordinates being limited to 16bit. Let's see how far I can get, but I guess 8000 layers shouldn't be a problem with enough RAM and if you bring enough time. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How's CVS-HEAD?
Luc NOVALES wrote: essai sorry for this spam, I hope to change the address for an internal filtering test. Luc. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
At 8:37 PM +0100 2/7/02, Sven Neumann wrote: I hope do be able to complete the new text tool anytime soon and it is supposed to give you even better rendering than gimp-freetype combined with the features of GDynText. Will it still use FreeType for the actual rendering of the glyphs? And if not, then what? Leonard -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
Sven Neumann wrote: Script-Fu is still adding layers while I write this and the count is approaching 4000 layers of 16x16 pixels here. At the moment gimp uses about 330MB of virtual memory (256MB physical RAM). The script has (gimp-displays-flush) after (gimp-image-add-layer ...), so the layers dialog is fighting to keep up with the amount of layers You could try duplicating an existing layer multiple times instead of creating new ones, so the copy-on-write code saves you memory. If your layer is 16x16 though, I imagine that the per-layer thumbs are taking more memory than the layer data! I think it'd still be a fair comparison if you closed the layers dialog -- an image with 1000s of layers is probably not expected to be managable sanely with what amounts to a list paradigm. -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 But not us (no never) no not us (no never) We are far too young and clever ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Thu, Feb 07, 2002 at 02:45:03PM +0100, Raphael Quinet [EMAIL PROTECTED] wrote: not be saved in a new file (unless it is reconstructed by the JPEG/EXIF plug-in) but it would be available after the image has been loaded. If it is valid after the image is modified, yes. Otherwise I think it should not be attached at all. appropriate for each file format to/from UTF-8 if necessary. Oh yes, oh yes! ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] EXIF information in JPEG files
On Thu, 7 Feb 2002, Dave Neary wrote: Marc Lehmann wrote: There is no such thing as non-standard naming in this case. exif doesn't provide a standard name, so you need to make one up. Wether oyu make up one or 50 doesn't really matter, as long as it's documented. That's the major part of the problem. If someone adds metadata that's not documented, that's a problem. It's a problem because there's no one place that someone can go and say that they have the definitive list of parasites. That's fine if there are only a few, but if there are many, tracking them becomes a chore. And more it leads to the possibility of inconsistency. [snip] I think it's much easier to just look at the documentation rather than to run through header files until I can find what I need, hopefully with a sparse one-line comment, even. That's fine, when the documentation is accurate - if it lags behind (and anyone who thinks it doesn't is living in a dreaml world) it becomes at best redundant and at worst misleading. parasites were created for metadata. If they don't work well enough for that parasites should be improved, rather than becoming a legacy layer. To handle something like what we're talking about, you'd need something paralleling the PDB - a parasite database. And that seems to me like overkill. While I think that the problems with inconsistancy are overrated -- mitch and sven seem to review every cvs commit and wouldn't reluctant to revert a commit that adds a parasite without adding it to devel-docs/parasites.txt -- I also don't see why adding a PDB-style self-documenting parasite registry would be bad either. The advantage would be that there would be one place to read about all the parasites, even those that are not included with the GIMP. Before a plug-in could attach a parasite, the parasite would have to be registered. The registration function would take three parameters: the name of the parasite, a blurb about what it does, and the format that the parasite is stored in. (UTF-8, 7-bit ASCII, string representation of a float, etc.) Perhaps even a custom format could be provided that calls a custom verification function. Since more than one plug-in might use a parasite, but all of them have to register the parasite, it's possible that the information registered can conflict. It seems best to make the second registration function fail should the formats be different, but if the blurb is different, it is probably best to silently ignore it. What do you think? Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
