On Tue, 5 Feb 2002, Dave Neary wrote:
 > Raphael Quinet wrote:
 > > [...] Note that it is important
 > > that each individual item in the EXIF data is converted to a
 > > separate GIMP parasite instead of importing the whole EXIF data in
 > > one big chunk because [...]
 > I'm not sure I agree with you here... I thought the matter was
 > closed and that we were in agreement last December, but as I
 > understand it there is no reason to have more than one parasite for
 > exif data (or if you prefer a more generic metadata parasite which
 > encompasses a superset of exif).

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:

* The metadata is likely to be useful for other plug-ins, even if they
   do not understand the full EXIF format.  If the EXIF data is saved
   in one big chunk, then every file plug-in that wants to use a part
   of the information (for example, only the author name or only the
   date at which the original image was created) would have to be able
   to decode the EXIF format, deal with struct padding, byte-ordering
   problems, and so on.  It should not be necessary to do all this in a
   plug-in if the only thing that it wants to do is to get a string or
   a timestamp from the metadata associated with the image.

* The EXIF standard requires some fields (e.g., DateTime, Software) to
   be updated by any application that conforms to that standard.  If a
   plug-in does not understand or does not need some of these fields,
   then it is better to drop them instead of copying them blindly.
   Using separate parasites makes the default behavior correct (because
   if a plug-in does not know how to handle a part of the EXIF data, it
   will not know its name either so it will not get it and copy it).

* Instead of rephrasing them, I will simply quote three additional
   reasons directly from the proposal to include EXIF data in the PNG
   file format (http://pmt.sourceforge.net/exif/drafts/d020.html):
   "- The data is potentially useful to human readers; this proposal
      allows them to view the information with existing PNG
      software. If it were kept in binary form, only special-purpose
      applications would be able to read it. Also, combining different
      data management methods (as in Exif format that embeds TIFF and
      JPEG encoded stuff), makes things unwieldy.
    - Data that is of no conceivable use after the image has been
      converted from the original format (JPEG tables, TIFF tiling
      layout, etc.) would be unnecessarily saved, wasting space.
    - The data would be at risk of being unnecessarily discarded by PNG

* The GIMP can use more metadata than what is defined in the EXIF
   standard.  This could be done (and is already done) by using
   separate parasites for saving generic or GIMP-specific information.
   For consistency reasons, it would be better if all plug-ins would
   simply have to know the name and type of a parasite in order to be
   able to access its value, instead of having to go through an
   intermediate parsing step if the data is saved in the EXIF block.

 > My understanding, from what Sven and Mitch told me back then, was that
 > a part of a parasite could quite easily be modified independant of the
 > rest.

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.

[snipped other comments for which we agree]


Gimp-developer mailing list

Reply via email to