Hi,
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
are:
A) Artist: Ascii, name of the image creator, in parasite
"gimp-artist".
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
"gimp-colorspace".
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.
Best,
-- Bill
______________ ______________ ______________ ______________
Sent via the CNPRC Email system at primate.ucdavis.edu
