Re: [Gimp-developer] EXIF information in JPEG files
On Tue, 5 Feb 2002, Dave Neary wrote: Raphael wrote: There are several reasons for using individual parasites for each part of the EXIF data instead of using a single parasite including the whole structure: [snipped points] Your points all have merit. My problem is now, and has always been, that a parasite per piece of data would mean adding an extra 50 or 60 parasites which would be relatively persistent. That makes things pretty complicated, to my mind. What's the problem with having 50 or 60 parasites attached to an image? The parasites are very small and they are what the GIMP uses to store any kind of metadata about an image. Each of these parts can easily be accessed or modified by using its name. The GIMP parses the list of parasites for you, so you only have to write a few of lines of code to get the current value of gimp-comment (the comment attached to the image) or hot-spot (the position of the hot spot if you are editing a cursor) and modify it. Instead we could store the whole metadata in a nice format (say as xml?) as one parasite, and have it parsed in one place. Then people who want to use bits of the metadata would just use the bits they wanted, and ignore the bits they didn't I do not understand what we would gain by using an XML format to store a list of name-value pairs if the GIMP is already providing a mechanism for doing that: the parasites. This would only add an extra parsing step that is not necessary. It is better to be able to access any part of the data directly by using its name. Using a format such as XML could be useful if many plug-ins had to attach complex data structures such as trees or nested lists to the image (and if these data structures would be used by more than one plug-in) but I do not see any need for that. The EXIF data block itself is a list of name-value pairs so the GIMP parasites are perfectly suitable for that. I think one structure, defined in one place, makes the handling of metadata cleaner. Maybe I am sounding like a broken record, but there is already a structure that is designed for handling metadata: this is the list of parasites. This is precisely why the parasites were added to the GIMP: storage of metadata, and easy access by name. The only thing that is missing is a standard list of names and types for all parasites. Here is a partial list of the names that I could find in the last stable release of the GIMP: - gimp-comment (string) image comment - hot-spot (string) hot spot position, given as two numbers in ASCII - icc-profile (raw) ICC color profile used in TIFF images - gimp-brush-pipe-parameters (raw) GIMP-specific data for brushes In addition, several plug-ins define their own parasites (such as jpeg-save-options or ifscompose-parasite) that are only useful for themselves and does not need to be understood by other plug-ins. It would be trivial to map the names of the all EXIF fields to individual parasites. I will try to post a list before the end of the week, and maybe that could be used as a starting point for a standard list of GIMP parasites. I will also have a look at how much effort would be needed in order to have the types checked by the GIMP core. The parasites are just untyped blocks of data, so a plug-in could certainly copy everything, modify a part of the data and then re-attach the updated parasite to the image. But again this would assume that all file plug-ins that want to use (a part of) the metadata are able to parse the EXIF block. I would prefer to avoid this requirement. And herein lies the crux - one object which is parsed by any object that wants to use bits of it, or multiple objects which are the bits. I think the cleanliness of having everything in one place is appealing. Well, that depends on your point of view: as I see it, the one place is the list of parasites. Several plug-ins are already using this one place and the access functions provided by the PDB to get or change some elements from this list. I still do not see any advantage in using only one element from this list to store another list (or another type of data structure, although I do not expect that we need anything more complex than a list to be used by more than one plug-in). -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 Wed, 06 Feb 2002, Adam D. Moss wrote:
Raphael Quinet wrote:
The only thing that is missing is a standard list of names and types
for all parasites.
{docs|devel-docs}/parasites.txt
Err... Right. I knew that the file existed (I took a look at it the
last time we discussed the parasites) but I had forgotten its
location. It is indeed included in the GIMP tarball, in the
devel-docs directory.
But it needs to be extended with all the names of the EXIF parasites.
So I will try to do that this week. Basically, I think that it would
be enough to use the name gimp-blah for each blah field of the
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
and are irrelevant once the image is converted to an RGB bitmap. I
will probably start with the list given in:
http://pmt.sourceforge.net/exif/drafts/d020.html
-Raphael
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How's CVS-HEAD?
Hi, Adam D. Moss [EMAIL PROTECTED] writes: Is it pretty much definitely compilable and runnable by mortals right now (funtionality aside)? What additions have there been to the list of **essential** build libs/components since 1.2.x? yes, it should compile. As usual the files HACKING and INSTALL mention the build requirements. In particular these are: autoconf = 2.13 automake = 1.4 libtool = 1.3.4 pkg-config = 0.7 glib = 1.3.13 pango = 0.24 including FT2 support (freetype = 2.0.1) atk = 0.10 (required by gtk+) gtk+ = 1.3.13 Basically this boils down to a working GTK+-1.3.13 installation and the usual autofoo tools. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
Raphael Quinet wrote: But it needs to be extended with all the names of the EXIF parasites. So I will try to do that this week. Basically, I think that it would be enough to use the name gimp-blah for each blah field of the EXIF data and simply copy the descriptions given in the EXIF standard. Fair enough, though if a parasite is going in the general-purpose gimp-* namespace care should probably be taken not to impose constraints specific to the EXIF form of that metadata upon a more general-purpose gimp-wide version. 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 and are irrelevant once the image is converted to an RGB bitmap. Also fair enough, though I'd consider prefixing these with exif- or similar to avoid polluting gimp-* forever. FWIW I'm in favour of splitting out individual general-purpose parasites rather than a monolithic EXIF parasite. --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Wed, 06 Feb 2002, Dave Neary wrote: Parasite naming is non-standard. Anyone can create a parasite with any name they want. [...] Where *is* the list of parasites? There are only (as you point out) about 10 persistent parasites, and the list isn't maintained anywhere. One possible approach to the metadata thing (I won't call it a problem yet) is to maintain a list of all the parasites which are used along with a description, and any time someone adds a parasite, they add it (with a description) to the list. devel-docs/parasites.txt is something approaching that. But that makes maintenance pretty difficult, compared to having the code document itself (one metadata structure with typed fields, and a couple of parsing routines). OK, so now the problem is clear: we need a way to enforce some consistency for the names of the parasites in the standard namespace (gimp-*). The plug-ins should be allowed to do anything they want with the parasites in their own namespace (e.g., jpeg-save-options or tiff-save-options) and nobody has to worry about these. The only thing that should be checked is the usage of the gimp-* names, which should have a pre-defined name and type. Maybe we could also define the exif-* namespace as common, although it could also be gimp-exif-*. Any plug-in that attempts to set or get a gimp-* parasite that has not been defined in some central place should cause the core to generate some kind of warning. So, what about this solution: I convert the existing list of common parasites (only the gimp-* parasites in devel-docs/parasites.txt) to a list of strings that can be put in a *.c or *.h file. I also add the EXIF data to this list. Then if the GIMP is compiled in debug mode, I would add some code in the PDB functions for accessing the parasites. This code would trigger a g_warning if the name of a gimp-* parasite cannot be found in the pre-compiled list. The code could also check the type of the parasite automatically, but this would imply an API change for all PDB functions dealing with parasites and that would also require an upgrade of the XCF format. So this would break a lot of things, but maybe it is better to do it as early as possible. Any opinions on this? Note that the *.c or *.h file containing the list of common parasites in the gimp-* namespace could be generated at build time from an XML file. That file could also hold the human-readable documentation of these parasites and it could be used to generate a text file or HTML file documenting the common parasites. I don't see the parasite handler as one place. As a scenario - say that the TIFF plug-in wants to set some metadata information (but not all of it) for a certain image, and later we are saving as PNG, and we want to set some more metadata with the image, wouldn't you consider the two plug-ins as two places? If I add a parasite to the metadata in the TIFF plug-in, the PNG developer knows nothing about it - if I as a lazy developer didn't add it to the list of supported metadata he wouldn't know it existed. And let's say I as the PNG developer want to use the same data, but I call it a slightly different name - now we have two parasites which do the same thing. Those kind of problems are eliminated by definition if all the metadata's defined in one place. The usage of non-standard parasites has not been a problem so far. All authors of plug-ins have correctly followed the guidelines described in devel-docs/parasites.txt. From that point of view, I do not think that it is really important to add a mechanism that checks if the gimp-* namespace is used correctly. But I think that it could be a nice addition, so I will see what I can do about it until next week. -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 Tue, 06 Feb 2002, Adam D. Moss wrote: Raphael Quinet wrote: But it needs to be extended with all the names of the EXIF parasites. So I will try to do that this week. Basically, I think that it would be enough to use the name gimp-blah for each blah field of the EXIF data and simply copy the descriptions given in the EXIF standard. Fair enough, though if a parasite is going in the general-purpose gimp-* namespace care should probably be taken not to impose constraints specific to the EXIF form of that metadata upon a more general-purpose gimp-wide version. OK, so this means that any EXIF data that could also be used by other plug-ins (such as Artist, Copyright, ImageDescription, ColorSpace and many others) should use the gimp-* namespace and the type checking should be relaxed if we can forsee other uses than what is described in the EXIF standard. If would then be up to the JPEG save plug-in to constrain this parasite to the acceptable range when it saves it as EXIF. 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 and are irrelevant once the image is converted to an RGB bitmap. Also fair enough, though I'd consider prefixing these with exif- or similar to avoid polluting gimp-* forever. If I am still following you correctly, this means that all parts of the EXIF data that should not be persistent (such as SamplesPerPixel, JPEGTables, YCbCrCoefficients, Interlace, ExifOffset and others that are marked as drop in the PNG-EXIF proposal) would use a different namespace. These parasites would use the exif-* namespace and would be discarded when the file is saved (even if it is saved in another EXIF file, because that information must be re-constructed instead of being copied). On Tue, 06 Feb 2002, Lutz Müller wrote: On Wed, 2002-02-06 at 14:50, Raphael Quinet wrote: Maybe we could also define the exif-* namespace as common, although it could also be gimp-exif-*. It would be _really_ easy if you used the tag names for those parasites, i.e. gimp-exif-FillOrder or gimp-exif-SpectralSensitivity. Yes, that's what I was planning to do. Except that I would convert the MixedCaseNames to hyphen-separated-names in order to be consistent with other parts of the GIMP. So the parasites would be split in several categories: 1 - gimp-* for existing persistent parasites that are already shared by several plug-ins (e.g, gimp-comment although the definition of this one is much too vague, as a consequence of the different meaning that it can have in different image formats). 2 - gimp-exif-* for new persistent parasites derived from the EXIF specification and that could be used by other plug-ins such as TIFF or PNG. I will probably follow the list given in the PNG-EXIF proposal. 3 - exif-* for new non-persistent parasites derived from the EXIF specification. These ones might be displayed in the File Properties dialog if we ever have one, but they would never be saved again in a file and they would not be used by other plug-ins. The second category could be merged with the first one if we drop the -exif part of the name and put everything under gimp-*. I do not know what is better. Comments? Besides, that would save you a lot of writing, as you can just point to the EXIF reference for names. Sure, that was my goal. By the way, libexif-0.3 and libexif-gtk-0.2 is out. If you use that, you can even access the thumbnail embedded in the EXIF data using gimp-1.2.2 and my patches posted earlier. Again, just a proof of concept, but it works. Thanks. I will have a look at it as soon as possible. But as I wrote previously and as Dave agreed, it would probably make more sense to merge this code directly into the JPEG plug-in instead of requiring an additional library. Also, the GTK+ user interface should probably be converted to a separate plug-in to view and edit all file properties. -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
http://www.ecs.soton.ac.uk/~njl98r/chocbox1.png http://www.ecs.soton.ac.uk/~njl98r/chocbox2.png A potential UI for a textual metadata editor using Dublin Core's element names (and of course internally it could use any parasite names that were deemed fit, but since parasite names are arbitrary text strings it might as well be DC.Creator, DC.Title etc.) EXIF's Artist is DC's Creator and PNG's Author (by convention) EXIF and PNG's Copyright is DC's Rights There are also a number of useful generic metadata structures in EXIF like the GPS data which could arguably be shared with other systems, and might therefore deserve a gimp-foo parasite name. One thing I can't seem to find out (maybe I'm looking in the wrong place) is whether EXIF data is supposed to follow derived works or not. Some contributors to this thread seemed to feel that it was important that a Gimp image must always preserve the EXIF data, but this would only make sense is EXIF is indeed a historical record of the source, and not live metadata. Can someone clear that up (preferably with a reference to an EXIF standards document or something) ? Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Wed, 2002-02-06 at 16:06, Raphael Quinet wrote: Thanks. I will have a look at it as soon as possible. But as I wrote previously and as Dave agreed, it would probably make more sense to merge this code directly into the JPEG plug-in instead of requiring an additional library. As this conflicts directly with my dislike to copy paste instead of using common libraries, I won't do that. See, libexif is needed by gphoto2, a command-line frontend to libgphoto2. And libexif-gtk is used by gtkam, a GTK frontend to libgphoto2. I hope that libexif will be used by other exif tools, especially command-line tools. I am not willing to keep several libexif versions together or to answer for incompabilities among those. Perhaps someone else... Also, the GTK+ user interface should probably be converted to a separate plug-in to view and edit all file properties. libexif-gtk is an EXIF editor. If someone wants to write a gimp-parasite editor, this is ok. But I'd still like to give users the possibility to access/edit all EXIF data, because a gimp-parasite editor will never be able to cover all EXIF tags. Just think of MakerNote the contents of which vary from manufacturer to manufacturer. Lutz -- +--+ \|||/ | Lutz Müller+49 (7156) 34837 | (o o) | +---ooO-(_)-Ooo---+ | Hans-Sachs-Strasse 5 | | 71254 Ditzingenhttp://www.topfrose.de | | Germany[EMAIL PROTECTED] | ++ signature.asc Description: This is a digitally signed message part
Re: [Gimp-developer] EXIF information in JPEG files
Nick Lamb wrote: One thing I can't seem to find out (maybe I'm looking in the wrong place) is whether EXIF data is supposed to follow derived works or not. Some contributors to this thread seemed to feel that it was important that a Gimp image must always preserve the EXIF data, but this would only make sense is EXIF is indeed a historical record of the source, and not live metadata. Can someone clear that up (preferably with a reference to an EXIF standards document or something) ? Presumably (and this is just me - I have nothing to support this) that depends on the data. For example, copyright would have to follow the normal rules of derived works (whatever they may be), as would author, but something like GPS (which relates directly to where the image was originally captured) could be copied through unchanged. Some data logically stays read-only, and some data should be modifiable (one example of each would, presumably, be flash energy and image history respectively). Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
Raphael wrote: On Wed, 06 Feb 2002, Dave Neary wrote: Where *is* the list of parasites? There are only (as you point out) about 10 persistent parasites, and the list isn't maintained anywhere. OK, so now the problem is clear: we need a way to enforce some consistency for the names of the parasites in the standard namespace (gimp-*). Agreed (if we decide to go for multiple parasites, and it seems like I'm becoming outgunned). We should also work out whether what we've been talking about is exif, to the exclusion of other metadata, or generic metadata, which would include exif data as a subset. Maybe we could also define the exif-* namespace as common, although it could also be gimp-exif-*. Any plug-in that attempts to set or get a gimp-* parasite that has not been defined in some central place should cause the core to generate some kind of warning. If we go with the more generic metadata option, then we would have the option of gimp-metadata-*. But that's minutiae at the moment. So, what about this solution: I convert the existing list of common parasites (only the gimp-* parasites in devel-docs/parasites.txt) to a list of strings that can be put in a *.c or *.h file. I also add the EXIF data to this list. Then if the GIMP is compiled in debug mode, I would add some code in the PDB functions for accessing the parasites. This code would trigger a g_warning if the name of a gimp-* parasite cannot be found in the pre-compiled list. A parasite validator would certainly be a solution. The question would then be whether the overhead of validating every parasite request would outweigh the overhead of parsing one metadata object :-) The code could also check the type of the parasite automatically, but this would imply an API change for all PDB functions dealing with parasites and that would also require an upgrade of the XCF format. So this would break a lot of things, but maybe it is better to do it as early as possible. Any opinions on this? Well, XCF was due an upgrade, but backward compatibility is a concern... Note that the *.c or *.h file containing the list of common parasites in the gimp-* namespace could be generated at build time from an XML file. That file could also hold the human-readable documentation of these parasites and it could be used to generate a text file or HTML file documenting the common parasites. Sounds like a plan. The usage of non-standard parasites has not been a problem so far. All authors of plug-ins have correctly followed the guidelines described in devel-docs/parasites.txt. From that point of view, I do not think that it is really important to add a mechanism that checks if the gimp-* namespace is used correctly. But I think that it could be a nice addition, so I will see what I can do about it until next week. That's primarily because the use of parasites has been limited to a few - notably gimp-comment. Apart from 3/4 commonly used parasites it hasn't come up. If we're passing image metadata around a lot it'll certainly be more of a concern. But we're getting towards agreement. I'm still not convinced that that's the way to go, but I can see that it's certainly at least as workable as my suggestion :) Cheers, Dave. ___ 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: yes, it should compile. As usual the files HACKING and INSTALL mention the build requirements. In particular these are: [snip] Thanks. Well, 6 hours later I have gimp 1.3 built! Yay! Naturally, it crashes on startup. Boo! After trying to 'ok' the second page of the gimp user installation wizard I get this: 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, #10 0x405255c6 in g_cclosure_marshal_VOID__VOID (closure=0x825e340, #11 0x4051002e in g_closure_invoke (closure=0x825e340, return_value=0x0, #12 0x405247c0 in signal_emit_unlocked_R (node=0x825b4b0, detail=0, #13 0x40522f6b in g_signal_emit_valist (instance=0x825e568, signal_id=110, #14 0x40167e3e in gtk_signal_emit (object=0x825e568, signal_id=110) #15 0x400ac0b2 in gtk_button_clicked (button=0x825e568) at gtkbutton.c:548 #16 0x400ad259 in gtk_real_button_released (button=0x825e568) #17 0x405255c6 in g_cclosure_marshal_VOID__VOID (closure=0x825d7e0, #18 0x4051041f in g_type_class_meta_marshal (closure=0x825d7e0, #19 0x4051002e in g_closure_invoke (closure=0x825d7e0, return_value=0x0, #20 0x40524262 in signal_emit_unlocked_R (node=0x825d818, detail=0, #21 0x40522f6b in g_signal_emit_valist (instance=0x825e568, signal_id=109, #22 0x40167e3e in gtk_signal_emit (object=0x825e568, signal_id=109) #23 0x400ac012 in gtk_button_released (button=0x825e568) at gtkbutton.c:540 #24 0x400ad07e in gtk_button_button_release (widget=0x825e568, event=0x8321500) #25 0x4012b75c in _gtk_marshal_BOOLEAN__BOXED (closure=0x82521b8, #26 0x4051041f in g_type_class_meta_marshal (closure=0x82521b8, #27 0x4051002e in g_closure_invoke (closure=0x82521b8, #28 0x40524bcd in signal_emit_unlocked_R (node=0x8252200, detail=0, #29 0x40522fd8 in g_signal_emit_valist (instance=0x825e568, signal_id=58, #30 0x40167e3e in gtk_signal_emit (object=0x825e568, signal_id=58) #31 0x401f09d2 in gtk_widget_event_internal (widget=0x825e568, event=0x8321500) #32 0x401f05f1 in gtk_widget_event (widget=0x825e568, event=0x8321500) #33 0x4012b5f0 in gtk_propagate_event (widget=0x825e568, event=0x8321500) #34 0x4012a34e in gtk_main_do_event (event=0x8321500) at gtkmain.c:1069 #35 0x402b6d80 in gdk_event_dispatch (source=0x8243520, callback=0, #36 0x4056333b in g_main_dispatch (context=0x8243550) at gmain.c:1616 #37 0x40564187 in g_main_context_dispatch (context=0x8243550) at gmain.c:2152 #38 0x40564567 in g_main_context_iterate (context=0x8243550, block=1, #39 0x40564c80 in g_main_loop_run (loop=0x8320650) at gmain.c:2453 #40 0x40129c91 in gtk_main () at gtkmain.c:794 #41 0x8080463 in app_init (gimp_argc=0, gimp_argv=0xb6e8) #42 0x80811d3 in main (argc=1, argv=0xb6e4) at main.c:451 And now I'm going to go seek out some beer and friends to commiserate with... --Adam -- 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?
Hi Adam, Adam D. Moss [EMAIL PROTECTED] writes: Thanks. Well, 6 hours later I have gimp 1.3 built! Yay! Naturally, it crashes on startup. Boo! After trying to 'ok' the second page of the gimp user installation wizard I get this: 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 (); that might be deprecated API (I haven't checked) but it should work in any case. And now I'm going to go seek out some beer and friends to commiserate with... have fun. I'd really like to help you get a working gimp-1.3 installation, so please try to investigate the problem further and report back. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Wed, 6 Feb 2002, Nick Lamb wrote: http://www.ecs.soton.ac.uk/~njl98r/chocbox2.png ^^^ Looks very nice, but please, please call the last field Copyright instead of Digital Rights Management. Rockwlrs ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Wed, 6 Feb 2002, Dave Neary wrote: If we go with the more generic metadata option, then we would have the option of gimp-metadata-*. But that's minutiae at the moment. Isn't the fact that it's a parasite metadata-y enough? I suppose it's possible to attach a parasite to an image for something other than metadata, but I doubt that anyone will ever do it. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Wed, Feb 06, 2002 at 02:11:28PM +0100, Dave Neary [EMAIL PROTECTED] wrote: Parasite naming is non-standard. Anyone can create a parasite with any name they want. Untrue. Names beginning with gimp- are well-defined as belonging to the core. The gimp itself must, at one point, know how to deal with these. The core also is: the aim of having a metadata editor at some stage, 50 or 60 pieces of metadata with (possibly) non-standard naming is complicated. 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. parasites if we were guaranteed a consistent approach throughout the gimp, but parasites don't give that guarantee by definition almost. Why? What are the problems? The obvious way to maintain a consistency wrt the metadata is to define it in one place, maintain that list in one place, and have it parsed into a usable structure when needed. I think this is exatcly what parasites provide. You say that any piece of metadata can easily be accessed by name. The problem is going to be: What name? I think keeping stuff in one place offers consistency. Well, the everything-in-a-big-blob-approach doesn't help naming at all. At one point you simply have to make up names to access the exif information. The parasites provide a namespace for this. Inventing yet-another-metadata-in-metadata-abstraction doesn't buy clarity. (with a description) to the list. devel-docs/parasites.txt is something approaching that. But that makes maintenance pretty difficult, compared to having the code document itself (one metadata structure with typed fields, and a couple of parsing routines). 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. parasites. Having one metadata structure provides that one place. But parasites _is_ one metadata structure. I don't see why nesting etadata structures inside each other is a good thing - to me it only complicates things. parasites were created for metadata. If they don't work well enough for that parasites should be improved, rather than becoming a legacy layer. the TIFF plug-in, the PNG developer knows nothing about it - if I as a lazy developer didn't add it to the list of supported metadata he wouldn't know it existed. And let's say I as the PNG developer want to use the same data, but I call it a slightly different name - now we have two parasites which do the same thing. Your approach suffers exactly the same problem, btw. Those kind of problems are eliminated by definition if all the metadata's defined in one place. And the most natural place for this is parasites, which exist only to hold metadata. If their definition isn't clear enough then this is the problem to solve. Adding yet another layer makes the situation worse, not better ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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 Wed, Feb 06, 2002 at 03:41:17PM +0100, Lutz Müller [EMAIL PROTECTED] wrote: It would be _really_ easy if you used the tag names for those parasites, i.e. gimp-exif-FillOrder or gimp-exif-SpectralSensitivity. while i am not strictly opposed, these names are very ugly. more important, though, non-exif-specific metadata (like the above), would gain a lot by being in a common format. exif is not the only metadata format around and it would be nice to have the gimp metadata an abstraction. -- -==- | ==-- _ | ---==---(_)__ __ __ 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
Hi, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: But parasites _is_ one metadata structure. I don't see why nesting etadata structures inside each other is a good thing - to me it only complicates things. parasites were created for metadata. If they don't work well enough for that parasites should be improved, rather than becoming a legacy layer. Ack. One change we definitely should make soon is to enforce UTF-8 encoding on all strings used in parasites (names and values if defined as strings). And the most natural place for this is parasites, which exist only to hold metadata. If their definition isn't clear enough then this is the problem to solve. Adding yet another layer makes the situation worse, not better 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? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
