On Fri, 19 Jan 2007 14:10:44 +0300, "Alexandre Prokoudine" <[EMAIL PROTECTED]> 
wrote:
[...]
> Out of curiosity, are you planning to use Exiv2 for that? Exiv2 seems
> to slowly obsolete libexif these days, because it reads/writes both
> EXIF and IPTC (IIM). It's already used by UFRaw, digiKam and
> Rawstudio.

The code that I started writing two years ago includes a (very limited)
EXIF parser and does not use libexif nor exiv2.  There were several
reasons for that:

- The metadata editor works with XMP, which is a superset of the other
  metadata formats and can be extended easily.  So instead of keeping
  the EXIF block in memory and fetching values from it on request (as
  done by libexif and most other libraries), the tags in the EXIF
  block are read one by one and converted immediately to XMP.

- Libexif was very EXIF-centric (of course).  The same applies to
  exiv2, although I did not consider it at that time.  It contains
  lots of nice descriptions and help strings for the various EXIF
  tags, but many of them are not appropriate after the data is
  converted to XMP.  For example, some separate EXIF tags are merged
  into a single XMP property, some others are orgnized differently
  and accept a different range of values, etc.

- There was an explicit wish to avoid depending on libexif.  Its API
  has changed a couple of times and broke the GIMP plug-ins.  It
  contained several bugs that caused many bug reports to be reported
  against GIMP while the bugs were in the library.  And the libexif
  code was not very clean nor easy to follow.

In retrospect, given the time that has passed since then and the lack
of progress on my part, maybe I should have used some library anyway.
I am not sure...

I did not evaluate exiv2 at that time.  It shares some of the problems
described above for libexif, but it seems to be structured and
maintained in a better way.  On the other hand, it is written in C++
instead of C and it is licensed under the GPL only.  I would like to
use a rather permissive license for the metadata editor so that it
could be re-used in other applications.  That's why I picked the LGPL
for the moment, although I could even use a more permissive license as
long as I am the main author of the code.  Using exiv2 would introduce
a dependency on GPL-only code and limit the opportunities for re-use
of the metadata editor.

> The next version will most likely feature i18n support, and since
> support for XMP/EXIF/IPTC in GIMP means showing all those variables
> translated, reducing overhead for translators would be awesome.
> Exiv2.pot has over 1000 messages, so you might guess how much work it
> would be for GIMP translators, if they did it alone... ;-)

Sure.  But as mentioned above, many of these messages are specific to
EXIF and may be irrelevant or inappropriate when the metadata is
converted to XMP.  The messages that refer to the specific encodings
used by EXIF (rational numbers, date formates, etc.) would have to be
replaced by different messages in the metadata editor.  Besides, there
are many other properties in XMP that are not part of EXIF and would
have to be described, translated, etc.  This includes the Dublin Core
properties, the license-related stuff (Creative Commons, etc.)...
Although it would be possible to fetch some of the tag descriptions
from the library and have all other descriptions in the editor itself,
I am not sure about how much work would be saved by that.

I haven't really made up my mind yet.  Maybe I should just get rid of
the code that I started writing a long time ago and use some EXIF
library instead.  Maybe this would save some development time.  Maybe
not.

-Raphaël
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Reply via email to