On Tue, Dec 04, 2001 at 03:32:18PM +0100, Raphael Quinet wrote: > Well, it is good that you posted that information to the list, because > I also started working on that problem although I have a slightly > different point of view. Instead of considering only the EXIF format, > I decided to investigate the more general problems of storage and > exchange of metadata in various image formats and also how to allow > the user to edit this information in the Gimp. Actually, that's the same thing that I've been thinking about and working on. > Some time ago, I submitted two bug reports about this: > http://bugzilla.gnome.org/show_bug.cgi?id=56443 (EXIF and metadata) > http://bugzilla.gnome.org/show_bug.cgi?id=61499 (editing metadata) I saw and read these (and the standards you pointed to), and understood them to mean "I've found this information, but don't have the time to work on them". That, and the facyt that the TODO item was unassigned, convinced me that ti was up for grabs :) > (Side note: I cannot access #gimp on IRC because of a firewall on my > main Internet access. I assume that I am not the only one. That's > why I think that all important things should be discussed on this list > and not on IRC. Also, the archives of this list are publicly > accessible and show up in search engines, which is nice for the > part-time contributors who are not subscribed to this list.) Point taken - I didn't think that there were many people for whom that was the case... > > As a matter of interest, does anyone have any ideas beyond "use a > > parasite, or a number of parasites" on how I can pass the data > > between the gimp and the plugins? All the image save and load > > functions should be able to see it, whether they use it or not is > > up to them. Also, beyond the data fields supported by EXIF, are > > there other metadata fields that people would like to see? > > As I mentioned in bug #56443, I suggest that you read the discussion > about EXIF on the PNG and MNG tools page (http://pmt.sourceforge.net/) > The "Rationale" section of the proposal explains why the metadata > should not be stored as one big chunk, but instead should be split in > individual values and each value should be interpreted, converted or > discarded as appropriate. Since the Gimp is an image manipulation > program, one can expect that the image data will be modified by the > user. I have the impression that you are trying to preserve the whole > EXIF metadata when saving the image, which is probably not a good > idea because some parts of if may not be valid anymore after the image > has been modified (or simply saved in a different format). That has been thought of, and I don't think that one metadata structure rules that out. In a way, it's just one bucket in which we store the various pieces of information. Of course each of them would be individually modifiable, and would be modified as a matter of course during the manipulation of the image (a good example would be the width & height parameters). > That's why I think that the first thing to do would be to define a > list of "standard" image parasites in the Gimp, with precise > definitions of the data types and constraints (so that's why I started > studying the specs of the various image formats). Once this list is > established and approved by everybody, this can be implemented in the > load/save plug-ins. There is already a document in the source tree > describing some parasites (devel-docs/parasites.txt) so we could > expand it and add more information about the constraints (valid ranges > and so on) for each parasite. I have a problem with creating potentially dozens of parasites and attaching them to images (possibly on a case by case basis, with some parasites not getting attached for some image types), when we could attach one object instead. Like you, I don't think we should limit ourselves to exif, and the kind of plan of attack I had doesn't really assume that. I reckon it'd be as easy as adding a metadata object to GimpImage, and then all our parasite stuff is defined in one place, and can be augmented and modified as required. It'd actually simplify GimpImage too. > For example, the parasite "gimp-comment" is used to store the image > comment and should use UTF-8 encoding. Some image formats such as GIF > have only one image comment field (in 7-bit ASCII) while EXIF (JPEG) > and TIFF/EP have separate fields for author name, copyright, image > description, user comments and so on. PNG supports several text > chunks of variable length, while other formats such as TGA have > strange limitations (the author name is limited to 40 characters and > the comments are limited to 4 lines of 80 characters). The best way > to handle the conversions between the different image formats is to > store everything in UTF-8 and apply the appropriate conversions when > saving/loading. But in order to avoid any ambiguity, it is necessary > to define the parasites in a very precise way so that all plug-ins > will use the same fields for the same purpose. Maybe we even need > some meta-meta-information saying for example if we are sure about the > character set that was used in the original image comment or if this > is only a best guess. I hope to have a proposal ready soon, but I > cannot say if this will be next week or next year... My personal opinion is that there's no need to tie ourselves down to a host of parasites when we can come up with one, hopefully clean, image data structure which will hold everything and will get passed around with the image, and modified when it needs to be accordingly. If we allow for the structure to be dumped independent of the image too (in xml, or some other friendly format), then we will have a consistent metadata approach, and every image may have a variety of (edittable) data fields associated with it. In addition, once we make the structure sufficiently complete, the various formats that support extra comments (such as exif/png) can write the bits they want into the images saved in the plug-in. Of course, I'm not saying "my way or the highway", but between the two approaches (numerous parasites tailored to the format, and one universal metadata object, parts of which are relevant to each format, which can also be saved separate from the image), I favour the latter. Cheers, Dave. -- David Neary, E-Mail dave.neary@xxxxxxxxxx Palamon Technologies Ltd. Phone +353-1-634-5059
