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
