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
