Okay, following up on earlier discussion: I think I have a reasonable way of dealing with the jpeg-exif stuff until Raphael's metadata code arrives. Raphael's plan is to turn everything into XMP and store it all in a single parasite. The interface between the jpeg plug-in and the metadata system, so far as exif is concerned, would consist of two functions, gimp_metadata_store_exif() -- which translates the exif into XMP and adds it to the metadata parasite -- and gimp_metadata_generate_exif(), which constructs an ExifData struct using the information from the metadata. (Raphael's plan has them implemented as plug-ins, but I think that's too awkward.)

I rewrote the jpeg plugin to use those two interfaces. As I now have it written, here is what it does:

On loading an exif-jpeg file, it (1) calls gimp_metadata_store_exif(), and (2) extracts the orientation from the exif and, if it is not top-left, queries the user whether to rotate the image.

On saving an exif-jpeg file, it (1) calls gimp_metadata_generate_exif(), and (2) sets the correct values for fields that according to the exif specs should be modified when an image is saved, including the thumbnail, image dimensions, orientation, etc.

It won't be possible to fully implement the two interface functions, gimp_metadata_store_exif() and gimp_metadata_generate_exif(), until Raphael's XMP parsing/formatting code is in CVS -- and even then it will be a lot of work. In the meantime, I created temporary implementations that do the following:

gimp_metadata_store_exif() serializes the exif data and attaches it to the image as an "exif-data" parasite.

gimp_metadata_generate_exif() extracts the contents of the "exif-data" parasite and deserializes them.

That is, the two functions combine to handle the exif data in the same way that it has been handled in the past. I put the code for the two functions (and a few small utility functions) into a new file called gimpexif.c in the jpeg directory. This should eventually go into a new metadata library, but it can live in the jpeg directory for a while.

So, to sum up, I believe that my code makes the jpeg plug-in handle exif data correctly, and interface correctly with Raphael's system. It no longer creates any parasites except "exif-data" -- which means that there is no way to edit the exif data until Raphael's editor is available, but so be it. Future development consists of implementing the two interface functions so that they actually translate to and from XMP, and implementing the metadata editor.

I've tried to put this together in a way that meets all concerns, but I'm perfectly happy to make further changes if there would be better ways of doing things.

Best,
-- Bill

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

Sven wrote:

Sorry, but before I continue reading, why is Raphaels' metadata code not available? You certainly wrote him a mail asking for it, didn't you? So why is he holding the code back? Does it even make sense to continue discussing this w/o Raphael?

The code is available from Raphael's web page, but it isn't in CVS, and it's up to Raphael when to put it there.

And yes, it makes sense to continue discussing this w/o Raphael, although it would make a lot more sense to continue discussing it with him. I'm sure he will contribute to the discussion when he's ready to.

-- Bill

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

Me:

(Raphael's plan has them implemented as plug-ins, but I think that's too awkward.)

Sven:

What is akward about it?

Passing, say, an ExifData struct to a plug-in is awkward. Calling a function and giving it a pointer is simpler, and much faster too. And then there's all the extra baggage of registering a plug-in etc.

Sven:

The JPEG plug-in would have to change the orientation tag if it's rotating the image on load, wouldn't it? It would have to do that before calling gimp_metadata_store_exif().

It can do that if it wants to, but there is no requirement. The orientation needs to be set to "top-left" when an image is saved, but it doesn't really matter whether the change is made upon loading or upon saving. If nothing else, doing it on saving prevents the user from setting things incorrectly in the metadata editor.

Me:

gimp_metadata_store_exif() serializes the exif data and attaches it to the image as an "exif-data" parasite.

gimp_metadata_generate_exif() extracts the contents of the "exif-data" parasite and deserializes them.

Sven:

Excuse my ignorance, but why do you need to serialize the data? What does serializing mean here anyway?

What I was trying to say, rather awkwardly, is that the two functions are implemented to do exactly what the current code does. By "serializing" I meant calling the libexif function exif_data_set_data to turn an ExifData struct into a string of bytes that can be stored in a parasite in a machine-independent way, and by "deserializing", turning the bytes back into an ExifData struct.

-- Bill

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

Sven:

I agree that for a C plug-in a library is easier to use but we will also have to care about plug-ins written in other languages. Making the functionality available in the PDB solves this nicely. What we usually do is to provide wrappers that let the procedure call appear as a simple function call.

This is only relevant to file plug-ins. It didn't occur to me that they would ever be written in anything except C, but if that is a reasonable possibility, then I accept the argument.

Sven:

Well, how is the save plug-in supposed to know that it needs to change the orientation field upon saving? Only when the image is rotated, during load, is this information available. Or am I missing something here?

The orientation is *always* supposed to be set to "top-left" when an image is saved, on the principle that after the user has edited the image in GIMP, the orientation is the way the user wants it. Only a camera should ever set it to anything other than "top-left".

-- Bill

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

Sven wrote:

It's just an argument, not a requirement. Simply something that might be worth keeping in mind. Is this really only relevant to file plug-ins? A metadata editor would need to use these functions as well, wouldn't it?

Raphael's plan, which makes sense to me, is that the metadata editor and metadata accessor functions will work exclusively with XMP, and that file plug-ins will translate between XMP and other metadata formats (IPTC, EXIF, DICOM, etc) on loading or saving, using interface functions supplied by the metadata system. So the interface functions xxx_metadata_store_exif() and xxx_metadata_generate_exif() only come into play when loading or saving a file with exif data. Fortunately the Adobe XMP specification completely defines the translation between EXIF data and XMP data, so the EXIF->XMP->EXIF round trip can be done without losing any information.

Hmm, so if I open an image, do some color corrections, but do not rotate it, the orientation tag is supposed to change? I can hardly believe that. But if you say that's what the spec says...

It *is* what the spec says, and it seems to me that the only reasonable assumption is that if the user looks at the image before saving it, what the user sees is what the user wants. I admit that for non-interactive use this might not always be the most desireable thing, and perhaps it is worth thinking about whether that should (or could) be handled differently.

-- Bill

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

Raphael wrote:

Yes to both, although the basic stuff hasn't changed much. I never managed to finish the code that generates the EXIF block from XMP, though, so that's still work-in-progress.

The most important thing is the XMP parsing/formatting code. Once that is in place, I can help with the EXIF-XMP translation code.

Best, -- Bill

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