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 editors."
* 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]
-Raphael
