I've been working on the jpeg plug-in, and would like to summarize
developments and give a sense of where I would like to take it.
(Please read to the end before deciding to react negatively :-) .)

1) First, because the code size has been exploding recently, it has
   been placed in a separate directory, plug-ins/jpeg, and split up into
   files jpeg.c, jpeg-load.c, jpeg-save.c, and jpeg-exif.c, the last
   of these containing newly written exif-handling code.

2) The jpeg plug-in now pretty closely adheres to the instructions in
   the exif specifications concerning which fields should be altered
   by an image-editing program.  There are a couple of fields
   remaining that I haven't yet figured out how to set properly.

   There is now a file called "exif-handling.txt" in devel-docs that
   summarizes my understanding, based on the exif specifications, of
   how an image editor is supposed to handle the exif data in a file.
   Of course we need not take the specifications as gospel (among
   other things, they specify that a proper EXIF file must have a file
   name in 8.3 format, ending in .JPG!), but they should serve as a
   good default.

3) A few special pieces of information, which may be relevant to many
   different file types, are extracted from the exif data on loading,
   and placed in special parasites.  Currently, the extracted items

   A) Artist:  Ascii, name of the image creator, in parasite

   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*.

   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".

   E) Colorspace:  Can be "sRGB" or "uncalibrated", in

   With the exception of Colorspace, these are not mandatory fields,
   and don't exist in the majority of exif files.  If a field does not
   exist, no parasite is created.  When an image with exif is saved,
   if parasites with these names exist, their contents are inserted
   into the exif data.

   There are also a few exif fields relevant to color management,
   which the current code does not extract.  It will be good to add
   this once we have a general color management solution in place.

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)

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.

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.

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.) 

Of course none of this is written in stone.

  -- Bill

______________ ______________ ______________ ______________
Sent via the CNPRC Email system at primate.ucdavis.edu

Gimp-developer mailing list

Reply via email to