On Fri, 19 Jan 2007 14:10:44 +0300, "Alexandre Prokoudine" <alexandre.prokoudine@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
