Dave Neary wrote:
>>> You cannot use this plug-in to work with EXIF data, unfortunately:  it
>>> is stored in a binary format that requires special handling.
>>
>> Any plans to add this in the future?
>
> There have been (long) discussions on this before...
>
> [ . . . ]
>
> Somewhere in there you might find some ideas for how exif data 
> could be handled :)

Actually it's not so hard.  The libexif site contains code for a
widget called "gtk_exif_browser", which operates on an exif_data
structure of the sort that you (Dave) wrote the code to load from
a jpeg file for people who have libexif.  So it's simply a matter
of writing a plug-in that starts a gtk_exif_browser and feeds the
contents of the jpeg-exif-data parasite to it -- really not
more than a few hours of work, probably.  The only downside is
that the gtk_exif_browser code is unmaintained and rather buggy,
but it does at least basically work.  (The libexif site also
has the code for a program called gexif which is simply a wrapper
around gtk_exif_browser.  All of this stuff compiles straightforwardly
except that you have to turn off -DGTK_DISABLE_DEPRECATED in the
Makefile.)

> Personally I think it would be easier to have an EXIF editor, a 
> Dublin Core editor, an IPTC/XMP editor and so on, rather than have 
> one generic one size fits all metadata editor which magically makes 
> itself look OK regardless of the data involved.

I agree completely, at least for the initial stages of development.
At some point in the future, it might be desirable to try to
wrap things up neatly -- but not now.

Best,
  -- Bill

 

 
______________ ______________ ______________ ______________
Sent via the KillerWebMail system at primate.ucdavis.edu


 
                   
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to