GNOME Bugzilla – Bug 515265
use exiv2 as metadata source
Last modified: 2021-06-19 08:46:19 UTC
I just reworked the trunk version of gThumb to exiv2 to read all metadata. I humbly suggest that eog do the same... Exiv2 can replace libexif, libiptcdata, and exempi, with a single consistent metadata interface. It can read metadata from jpeg, tiff, RAW files, and xmp sidecars. It can read and write exif, XMP, IPTC, and most MakerNotes. libexif is crufty, crash prone, and poorly maintained. The exiv2 maintainer is very responsive. The key gThumb file is here: http://svn.gnome.org/viewvc/gthumb/trunk/libgthumb/gth-exiv2-utils.cpp?view=markup It is C++, but the external functions are C compatible. - Mike
Hi Michael, sounds like an interesting proposal. However, I had a quick look at the code and it seems that exiv2 has it's own way of reading metadata. Can it read metadata from remote files (http, ssh, smb, etc)? Is there any way to integrate it with gio/gvfs?
Lucas, Exiv2 just uses local path names. There is no built-in support for gio/gvfs. You would need a wrapper layer. Of course, the same is true for libexif and libiptcdata. Perhaps Andreas (exiv2 author) would consider adding a gio-compatibility interface. I'll cc him to this bug report. In gThumb, we copy all remote files to a local cache, to get around issues like this (and to speed things up). - Mike
Besides for a local path name, Exiv2::ImageFactory::open is also implemented for a memory area (taking a const Exiv2::byte* data and long size) and one for an Exiv2::BasicIo, which is Exiv2's simple IO interface. Currently there exists an implementation of BasicIo for files and for memory areas (FileIo and MemIo). Thus, a wrapper could either use the memory area interface or, perhaps more appropriately, could be done in a new class derived from BasicIo. However, I'm not familiar with gio/gvfs to judge which approach is better. (IIRC someone wrote an http version of BasicIo once). Andreas
i don't know if i have to fill a separate bug report, but on Ubuntu Hardy beta EoG doesn't show keywords added with F-Spot whereas Nautilus does (through File Properties Dialog box) There is a sample file there https://bugs.launchpad.net/ubuntu/+source/eog/+bug/146288/comments/2 (that bug report on Launchpad was at first about EoG in Ubuntu 7.10 showing no metadata at all. While Ubuntu 8.04 fixed it, EoG still doesn't show all matadata) Since Nautilus and F-Spot also displays metadata, maybe all these applications should use the same backend ?
(In reply to comment #4) > i don't know if i have to fill a separate bug report, but on Ubuntu Hardy beta > EoG doesn't show keywords added with F-Spot whereas Nautilus does (through File > Properties Dialog box) Yes, please file a separate bug report.
ok, that's Bug 526331. Thank you
Is using gexiv2 not a better idea? http://trac.yorba.org/wiki/gexiv2 ?
Hmm, I am still a bit undecided on how to handle this. To me it looks like if we wanted to integrate gexiv2 into our current image loading infrastructure (which streams the files in 64k packets to the parsers) it would have to be extended to be able to just receive the single metadata (Exif/XMP) blocks and possibly to re-produce them for image saving (with changed values). On the other side, if it is possible, giving gexiv2 access to the file operations (through a GIO wrapper) we could profit from the fact that Exiv2 apparently can parse more image formats for metadata than eog can. This would require larger changes to eog and (at least at the beginning) would have us loose the color profiling support as Exiv2 apparently doesn't support accessing the embedded profiles yet.
What is the advantage of exiv2 over exiftool?
exiv2 is written in C++ which is easier to interface from eog than ExifTool which is actually a Perl module.
exiv2 0.25 will be out later this year and includes many features which may be useful for eog. Not only in the image formats read, but also in reading and writing much useful metadata. http://dev.exiv2.org/versions/51 gexiv2 has also come a long way in the last 4 years. https://git.gnome.org/browse/gexiv2/tree/NEWS libexif meanwhile appears to have stagnated. http://sourceforge.net/p/libexif/news/ I understand that it is a lot of work to make such a change and wish I had the coding skills to help. But I believe it will address many, many current bug reports and prepare eog for a productive future.
Hi all, I have started to port it to gexiv2, will provide branch wit current progress later
https://git.gnome.org/browse/eog/log/?h=wip/phako/gexiv2
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/eog/-/issues/ Thank you for your understanding and your help.