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
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
Gimp-developer mailing list