Hi, "William Skaggs" <weskaggs@xxxxxxxxxxxxxxxxxxx> writes: > A) Artist: Ascii, name of the image creator, in parasite > "gimp-artist". ASCII isn't a reasonable encoding for names. I strongly hope the EXIF spec doesn't define this as ASCII. > B) Copyright: Ascii, in "gimp-copyright". The format of this is a > bit peculiar -- it consists of two null-terminated strings > end-to-end, the first containing the *editor copyright*, and the > second the *photographer copyright*. The term "string" is meaningless unless an encoding is specified. > C) User Comment: in "jpeg-user-comment". This can contain > arbitrary binary data, so it must be handled with care. > > D) Image Description: Ascii, in "gimp-comment". gimp-comment is UTF-8, not ASCII. > 4) When the exif specifies that an image is rotated, the plug-in pops > up a query asking the user whether to rotate it into standard > alignment. I thought it was better to ask rather than do it > automatically, because there are probably a substantial number of > existing images that have been edited without having their exif > information properly updated (for example, by earlier versions of > GIMP). When an image is saved with exif, the orientation is set to > "top-left", as the exif specifications require. (See bug #121810) Fortunately this isn't really an issue for The GIMP since people owning a camera that adds rotation information will use tools such as exiftran to deal with it. GIMP shouldn't very often see images with an orientation tag other than "top-left". So your approach is probably fine. > Where to go: > > 1) As Sven has pointed out (and I agree), putting information into a > set of separate parasites is a Bad Thing To Do. Instead, the Right > Thing To Do is to have a single "gimp-metadata" parasite containing > all of the general metadata, and a set of functions for > manipulating them. Once such a thing exists, it should be very > easy to port the existing code to use it. Thus, the existing code > should be thought of as essentially a stub for the correct code. > In any case, the existing parasites are marked as non-persistent, > so they will only stick around for the current session, and not be > saved in xcf files. I don't think that a "gimp-metadata" parasite is the right thing to do. Instead we should continue to use the "exif-data" parasite. Plug-ins that need to deal with EXIF data can use libexif to extract the relevant informations. I don't see any point in preprocessing the EXIF data the way you are doing this now. What's the benefit of all this? Why introduce new parasites? > 2) Exif is not relevant only to jpeg: it can appear in TIFF and Raw > files, and there are draft standards for including it in PNG and > other file types. I would like to extract the generic parts of the > exif handling code for jpeg-exif.c and place it into a new library > for generic file-handling code, libgimpfile, which we have > discussed creating some time ago (see bug #139354). The file > jpeg-exif.c will still however need to exist, because the exif > specifications require some different fields for compressed (jpeg) > vs uncompressed (tiff) exif files. libgimpfile is about abstracting file handling and is supposed to wrap gnomevfs and similar libraries. It is not at all about handling exif data. It might turn out that we need a library that deals with metadata but the API of such a library needs to be carefully designed, so please hold back until that has happened. > 3) I have created a very simple parasite browser plug-in, capable of > listing image parasites, editing their contents if they are ascii, > creating new ones, loading the contents of the file into one, or > saving a parasite to a file. I would like to add this to cvs, > partly because it is useful, partly for the assistance of > developers who need to look at parasites, and partly as a > placeholder for a more powerful metadata plug-in that is hoped to > appear sometime during the current development cycle. (See bug > #61499, #120563, tracking bug #118202, etc.) There's a parasite editor in gimp-perl already which can do all this. I don't think we need yet another implementation. We also have a more or less complete metadata editor that waits to be committed to CVS. I don't understand why you are ignoring the work of Raphael. IMO you two should work closely together instead of duplicating each other's work. IMO this metadata topic needs to be treated with more foresight. I am rather unhappy with the latest developments in CVS. I don't see how the latest changes take into account IPCT and XMP metadata and I think it's a bad idea to ignore this. I'd have welcomed the changes to be discussed here before any code is changed. Sven
