At first glance everything looks ok but somewhere backend exiv2 0.22 is in use and serving metadata and not exiv2 0.23 and over libkexiv. KDE 4.8.3 on Ubuntu is built against exiv2 0.22 and is linked against libexiv2.so.11. Building Digikam 2.6 against and linked to updated exiv2 0.23 (including libkexiv) should make Digikam only use libexiv2.so.12 but somehow metadata from the older version of libexiv get shown when both are on the same system. Everything in digikam show that it use exiv2 0.23 but it doesn't show correct metadata for lenses introduced in 0.23 but errors as in 0.22. Showfoto show the correct metadata though. Does (lens) metadata in digikam get collected over kde runtime backends like kioslave that is built against exiv2 0.22 and not always metadata collected via libkexiv that use 0.23 on my system? This didn't happen with digikam 2.5 even though my system setup was different but the build progress and workflow was the same. $ ldd /usr/bin/digikam | grep -i exiv libkexiv2.so.11 => /usr/lib/libkexiv2.so.11 (0x00007f3dc0008000) libexiv2.so.12 => /usr/lib/libexiv2.so.12 (0x00007f3db7cd8000) $ ldd /usr/bin/showfoto | grep -i exiv libkexiv2.so.11 => /usr/lib/libkexiv2.so.11 (0x00007feea693b000) libexiv2.so.12 => /usr/lib/libexiv2.so.12 (0x00007feea07c3000) $ ldd /usr/lib/libkexiv2.so.11 | grep -i exiv libexiv2.so.12 => /usr/lib/libexiv2.so.12 (0x00007f475f0c5000) KDE kio slave exiv2 linkage example: $ ldd /usr/lib/kde4/rawthumbnail.so | grep -i exiv libkexiv2.so.10 => /usr/lib/libkexiv2.so.10 (0x00007f17590d2000) libexiv2.so.11 => /usr/lib/libexiv2.so.11 (0x00007f1754393000) $ ldd /usr/lib/kde4/jpegthumbnail.so | grep -i exiv libexiv2.so.11 => /usr/lib/libexiv2.so.11 (0x00007fc0a93f5000) Components information: digiKam version 2.6.0 Exiv2 can write to Jp2: Yes Exiv2 can write to Jpeg: Yes Exiv2 can write to Pgf: Yes Exiv2 can write to Png: Yes Exiv2 can write to Tiff: Yes Exiv2 supports XMP metadata: Yes LibCImg: 130 LibClapack: internal library LibExiv2: 0.23 LibJPEG: 80 LibJasper: 1.900.1 LibKDE: 4.8.3 (4.8.3) LibKExiv2: 2.3.0 LibKGeoMap: 2.0.0 LibKdcraw: 2.1.0 LibLCMS: 2020 LibLensFun: external shared library LibLqr: internal library LibPGF: 6.11.42 - internal library LibPNG: 1.2.46 LibQt: 4.8.1 LibRaw: 0.14.6 LibTIFF: LIBTIFF, Version 3.9.5 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc. Marble Widget: 0.13.3 (stable release) Parallelized demosaicing: Yes Database backend: QSQLITE LibGphoto2: 2.4.14 LibKface: 2.0.0 LibKipi: 1.6.0 LibOpenCV: 2.4.0 Libface: 0.2 Reproducible: Always Steps to Reproduce: 1. Check lens metadata on image with lens only supported in exiv2 0.23 2. 3. Actual Results: Image show cryptic lens model name 251. Expected Results: Image should show lens metadata for "Tamron 17-50/2.8" in Digikam as it do in Showfoto. Example image that can produce this problem with mix of exiv2 0.22 and 0.23 in this way can be found in this bug report: http://dev.exiv2.org/issues/791
Andreas, your viewpoint about this report ? Gilles Caulier
Gilles, just from the ldd output, I'd also ask the same question as the OP. Or can data stored in the database somehow affect the output? Andreas
It doesn't help to re-read metadata in Digikam for the image so I don't think it's something to do with the database. /Philip (In reply to comment #2) > Gilles, just from the ldd output, I'd also ask the same question as the OP. > Or can data stored in the database somehow affect the output? > > Andreas
Also find that Digikam detects and names the lens correctly in Digikam Image Editor and use Enhance > Lens > Lens Auto-Correction. Lens meta data in the meta data fields there show correct Tamron lens name and not "251" as with exiv 0.22 so exiv 0.23 is at work here. Looks like "Photograph Properties" in Album view collect meta data differently over kio or some other KDE backend and not over digikams own updated version of libkexiv.
Philip, "Looks like "Photograph Properties" in Album view collect meta data differently over kio or some other KDE backend and not over digikams own updated version of libkexiv" no. Exiv2 is used everywhere in the same manner... Gilles Caulier
In Digikam 2.7 this bug no longer seem to be present.
I don't know why but this bug is valid again in digikam 2.8. Worked for me in digikam 2.7. The strangeness continues in this regard...
same problem with my installation digikam 2.8
Philip, This entry still valid with digiKam 3.5.0 ? Gilles Caulier
I don't have the same setup with mixed libexiv2 versions so I can veryfi the problem anymore.