Sven wrote:
>> 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.
The spec defines it as ASCII. Before you get too outraged, please bear
in mind that the EXIF spec was created in Japan, where they were certainly
aware of the significance of what they were doing. (It was, however,
derived from the TIFF spec for the fields that the two share, and that
is probably the source of the ASCII specification.)
>> 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.
As I wrote, it's again ASCII.
>> 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.
Okay, so gimp-comment should go into the "User Comment" field.
> There's a parasite editor in gimp-perl already which can do all this.
> I don't think we need yet another implementation.
That's fine, it's available from the registry if anybody wants it.
> 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.
I agree! I am not at all ignoring Raphael's work -- if it was
accessible, I would be interfacing with it instead of using
temporary hacks. I don't actually think that the code I have
added will duplicate Raphael's work, though -- most of it is
devoted to making sure that exif data, if it exists for an image,
is updated as required by the specs when the image is saved as a
jpeg file. That is the responsibility of the jpeg plugin, not of
a metadata editor. A metadata library might facilitate it, but
the jpeg plugin still needs to take responsibility for making it
happen.
> 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.
The only important thing in the code I added is that it makes the
jpeg plug-in follow the exif specifications when it saves a file with
exif data. Everything else is simply a stub, easily altered to fit
any reasonable metadata-handling scheme that we come up with. I only
bothered putting things into parasites because I have found that
implementing a bad solution tends to provoke the appearance of a
better solution, whereas a void does not necessarily provoke the
appearance of anything. That code took about 10 minutes to write,
and shouldn't take much longer to change.
> 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.
This statement gives the essence of what has been holding us back.
"It might turn out . . ." means that there is no concrete sense of
what is needed. But how can an API be carefully designed without
a concrete sense of what is needed? It isn't possible. The only
way to get anywhere is to experiment, and when something doesn't
work, change it. It's not like we're working with core code here
that will break GIMP if it's imperfect.
Best,
-- Bill
______________ ______________ ______________ ______________
Sent via the CNPRC Email system at primate.ucdavis.edu
