Bug 338783

In Setup/Metadata panel, do you turn on "Read from sidecar files" option ?

Gilles Caulier

I have exactly the same behavior.
I use digiKam 4.2.0 with KDE 4.11.5 on opensuse 13.1

Jean Pierre,

Do you seen my question from Comment #1 ?

Gilles Caulier

(In reply to Gilles Caulier from comment #1)
> In Setup/Metadata panel, do you turn on "Read from sidecar files" option ?
> 
> Gilles Caulier

Yes, in Setup/Metadata panel I have
read from sidecar files (In reply to Gilles Caulier from comment #3)
> Jean Pierre,
> 
> Do you seen my question from Comment #1 ?
> 
> Gilles Caulier

Yes, I was drafting my reply ;-)
Yes, I have "Read from sidecar files" turned on.

Jean Pierre,

Well, please turn off this option and look if problem is reproducible in this case.

If not, please provide the files relevant (image + side-car)

Gilles Caulier

I turned off the "Read from sidecar files" option. the behavior is the same.

If we go into details, it's a little more complicated than what was written peter. As he says exiv2 displays meta data correctly. Digikam also shows them in the PROPERTIES tab and in the Metadata tab -> maker notes, but nothing in the metadata tab -> EXIFS, metadata -> IPTC and metadata -> XMP.

On the other hand, all my photos are affected; none displayed metadata. What have been taken yesterday, there one month, one year or 10 years. Whether they are JPEG, NEF or DNG.

One NEF file and the associated XMP are here: http://ovh.to/ZLagmZ

Sorry, I'm very bad English writer and Google translate sometimes produces strange results

JP

Jean Pierre,

Can you go to Help/Components Info dialog and copy/paste content in this report ?

Gilles Caulier

Jean Pierre,

I cannot reproduce the problem here using last digiKam implementation from git/master and Exiv2 library 0.24 with your NEF + sidecar file.

I take 2 screenshots :

https://www.flickr.com/photos/digikam/14951914319/sizes/o/

With this first one, i can see Exif and Makernotes tabs filled. IPTC and XMP are empty. In this case, XMP sidecar is not used to populate metadata views.

https://www.flickr.com/photos/digikam/15138234432/sizes/o/

With this first one, i can see Exif and Makernotes, IPTC, and XMP tabs filled. In this case, XMP sidecar is used to populate metadata views.

Which Exiv2 and libkexiv2 shared libs version you use exactly on your computer to run digiKam ?

Gilles Caulier

(In reply to Gilles Caulier from comment #1)
> In Setup/Metadata panel, do you turn on "Read from sidecar files" option ?

My "Setttings -> Metadata -> Behavior":

 Write This Information to the Metadata
  [x] Image tags
  [x] Captions and title
  [x] Rating
  [ ] Pick label
  [ ] Color label
  [x] Timestamps
  [x] Metadata templates
  [ ] Face Tags

 Reading and Writing Metadata
  [ ] Read from sidecar files
  [ ] Write to sidecar files
  [ ] If possible write Metadata to RAW files
  [ ] Update file timestamp when files are modified

=> I don't use sidecar files.


(In reply to jean-pierre.verrue from comment #6)
> ... Digikam also shows them in the PROPERTIES tab ....
> 
> On the other hand, all my photos are affected; none displayed metadata. What
> have been taken yesterday, there one month, one year or 10 years.

That's also true for me:
EXIF information like Aperture, Focal, Exposure or Sensitivity is correctly
shown in the "Properties" tab of the right side view, but not in the "Metadata" tab
of the right side view. So I guess, reading the data from the image file is not the
problem.
And the bug effects all of my images, even those, taken 10 years ago.

  
The EXIF and XMP tags are not shown for 
 - images, newly imported from the SD-card and 
 - images, edited and tagged with digiKam
 - old images, edited with digiKam 3.5.0


I use JPGs, coming from a Canon EOS 500D, imported from a SD-Card
via USB card reader.


From the menu:
 Image -> Write Metadata to Image
and
 Image -> Reread Metadata from Image
does no change this bugs effect.


Maybe one interesting point:
After installing digiKam 4.2.0, I deleted all my digiKam settings:
  ~/.kde4/share/apps/digikam
  ~/.kde4/share/config/digikamrc
  ~/.kde4/share/config/digikam_tagsmanagerrc
and the digiKam dbs:
  - digikam4.db
  - thumbnails-digikam.db
To do a fresh, clean, new restart.
Since I have all important Metadata written to the JPG files, 
a fresh new digikam4.db (version 4.2.0) was build from those.

@Jean Pierre:
Did you recently delete your digiKam settings, too?

(In reply to Gilles Caulier from comment #7)
> Jean Pierre,
> 
> Can you go to Help/Components Info dialog and copy/paste content in this
> report ?
> 
> Gilles Caulier

Here is the list of components

digiKam version 4.2.0
CPU cores: 4
Codec PGF parallélisé: Non
Composant graphique Marble: 0.16.5 (stable version)
Dématriçage parallélisé: Non
Exiv2 peut écrire dans un fichier JP2: Oui
Exiv2 peut écrire dans un fichier JPEG: Oui
Exiv2 peut écrire dans un fichier PGF: Oui
Exiv2 peut écrire dans un fichier PNG: Oui
Exiv2 peut écrire dans un fichier TIFF: Oui
Exiv2 prend en charge les métadonnées XMP: Oui
LibCImg: 130
LibEigen: 3.2.0
LibExiv2: 0.23
LibJPEG: 80
LibJasper: 1.900.1
LibKDE: 4.11.5
LibKExiv2: 2.3.1
LibKGeoMap: 2.0.0
LibKdcraw: 2.3.1
LibLCMS: 119
LibLensFun: 0.2.8-0
LibPGF: 6.12.24 - bibliothèque partagée externe
LibPNG: 1.6.6
LibQt: 4.8.5
LibRaw: 0.15.3
LibTIFF: LIBTIFF, Version 4.0.3 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc.
Prise en charge du codec RawSpeed: Non
LibGphoto2: 2.5.2.1
LibKface: 3.0.0
LibKipi: 2.1.0
LibOpenCV: 2.4.6.1
Modules externes KIPI: 4.2.0
Moteur de base de données: QSQLITE

JP

Thi si s the most important part for this bug :

LibExiv2: 0.23 ==> this is not the last one, and it's very old now. Bug come from this lib. Me i use 0.24 (the last one)
LibKExiv2: 2.3.1 : sound like the last implementation.

This bug is not related to database. Metadata views are populated with tags list and gived from Exiv2 shared lib.

Important : I changed the ways to apply metadata filter over this view, since 4.0.0. The settings of this filter are in Setup/Metadata panel. I recommend to reset these filter to use default value and try again.

Metadata filter settings is stored in digikamrc file.

Gilles Caulier

after posting the components list, I realized that libexiv2 is 2.3 release, which is probably the bug origin.
Then I looked at the list of installed packages. On my opensuse 13.1. I have:

Name: libexiv2-12
Version: 0.23-9.1.3
Arch: x86_64

AND

Name: libexiv2-13
Version: 0.24-5.1
Arch: x86_64

Digikam therefore uses the wrong library.

I have tried uninstalling libexiv2-12, but alas, this release is required by nepomuk-core. I did not want to break my system, so how force Digikam to use good lib?

@peter
No, I did not delete my digikam settings for many years. Did I even deleted one day? I do not remember... (I use Digikam for 10 years)

(In reply to Gilles Caulier from comment #11)
> Thi si s the most important part for this bug :
> 
> LibExiv2: 0.23 ==> this is not the last one, and it's very old now. Bug come
> from this lib. Me i use 0.24 (the last one)
> LibKExiv2: 2.3.1 : sound like the last implementation.
> 
> This bug is not related to database. Metadata views are populated with tags
> list and gived from Exiv2 shared lib.
> 
> Important : I changed the ways to apply metadata filter over this view,
> since 4.0.0. The settings of this filter are in Setup/Metadata panel. I
> recommend to reset these filter to use default value and try again.
> 
> Metadata filter settings is stored in digikamrc file.
> 
> Gilles Caulier

J'ai vu l'onglet setup --> métadonnées --> affichage. J'ai essayé les deux boutons : "sélectionner tout" et "défaut". Mais cela ne change rien

JP

Oops, bad copy / paste ;-)
I saw the setup tab -> Metadata -> display. I tried the two buttons: "select all" and "default". But that does not change

JP

Here my system has Exiv2 0.23 (Mageia).

I use Exiv2 0.24 to :

- 1 recompile Exiv2 myself and install it (you can install more than one version of Exiv2 at the same time)
- 2 recompile digiKam WITH libkexiv2 against Exiv2 0.24 (the more recent version found will be used)

Gilles Caulier

(In reply to Gilles Caulier from comment #15)
> Here my system has Exiv2 0.23 (Mageia).
> 
> I use Exiv2 0.24 to :
> 
> - 1 recompile Exiv2 myself and install it (you can install more than one
> version of Exiv2 at the same time)
> - 2 recompile digiKam WITH libkexiv2 against Exiv2 0.24 (the more recent
> version found will be used)
> 
> Gilles Caulier

Well, the bug is not blocking, recompile take a lot of time and energy. After all, I can see the basic data on the properties tab.
I'll wait for the next release of opensuse (13.2 in November). Hoping the libexiv2 0.23 492 dependencies are resolved !
There is still something I do not understand. Why exif data is displayed in Properties tab and not in metadata tab? Also, why are displayed MakerNotes? In my little mind, the data should be displayed everywhere ... or not at all. Where is the subtlety?

JP

Metadata Views (Exif, Maker-notes, IPTC, and XMP) are raw view where contents is taken as well from file and filtered or not.

Properties view is a synthesis of most important metadata really stored in database. We don't store whole Exif, Maker-notes, IPTC, and XMP.

maker-notes are a subsection from Exif. In fact Exif working group has dedicated this place to camera makers to host private data which cannot be cataloged by standard Exif. This is why maker-notes are displayed in dedicated view.

Note : maker-notes are just like RAW format : a pure shame against standardization. Nothing is documented and reverse engineering must be processed to understand these data.

(In reply to Gilles Caulier from comment #11)
> LibExiv2: 0.23 ==> this is not the last one, and it's very old now. Bug come
> from this lib. Me i use 0.24 (the last one)
> LibKExiv2: 2.3.1 : sound like the last implementation.

Same old lib seems to apply to me:
My digiKam says:
------------------ 8< ------------------
[...]
LibExiv2: 0.23
[...]
LibKDE: 4.12.5
LibKExiv2: 2.3.1
[...]
------------------ >8 ------------------

There is a media-gfx/exiv2-0.24 in gentoo's portage tree. So I started compiling... ;)
I am not shure, if I can finish it this evening, but I hope I find time this weekend.
I will report...

Another question:
I used media-gfx/exiv2-0.23 since "23. Feb 2013" together with 
 - media-gfx/digikam-2.9.0
 - media-gfx/digikam-3.1.0
 - media-gfx/digikam-3.5.0
In all this time, I can't remember to have encountered this bug. So did digiKam 4.x break compatibility with media-gfx/exiv2-0.23?

I used media-gfx/exiv2-0.23 since "23. Feb 2013" together with 
 - media-gfx/digikam-2.9.0
 - media-gfx/digikam-3.1.0
 - media-gfx/digikam-3.5.0
In all this time, I can't remember to have encountered this bug. So did digiKam 4.x break compatibility with media-gfx/exiv2-0.23?

==> digiKam no, because it don't use Exiv2 API directly. All is done through libkexiv2 interface.

Gilles Caulier

(In reply to Peter Albrecht from comment #18)
> (In reply to Gilles Caulier from comment #11)
> > LibExiv2: 0.23 ==> this is not the last one, and it's very old now. Bug come
> > from this lib. Me i use 0.24 (the last one)
> > LibKExiv2: 2.3.1 : sound like the last implementation.
> 
> Same old lib seems to apply to me:
> My digiKam says:
> ------------------ 8< ------------------
> [...]
> LibExiv2: 0.23
> [...]
> LibKDE: 4.12.5
> LibKExiv2: 2.3.1
> [...]
> ------------------ >8 ------------------
> 
> There is a media-gfx/exiv2-0.24 in gentoo's portage tree. So I started
> compiling... ;)
> I am not shure, if I can finish it this evening, but I hope I find time this
> weekend.
> I will report...

Done compiling. But bad news: Bug is still there. :(

Details: I installed "media-gfx/exiv2-0.24", which replaced "media-gfx/exiv2-0.23". Gentoo automatically compiled "kde-base/libkexiv2-4.12.5" again, to use exiv2-0.24.
After this, I started digiKam, which lists at "Components Information":
------------------ 8< ------------------
  [...]
  LibExiv2 0.24
  [...]
  LibKExiv2 2.3.1
  [...]
------------------ >8 ------------------
But there are still no EXIF informations shown in the "Metadata" tab of the right side view. :(

Then I even recompiled digiKam, but this did not change anything.

Peter,

Ok, so i suspect a garbage in your digiKam configuration file.

Rename your ~/.kde4/share/config/digikamrc file as *.old. Restart digiKam, and try again

Gilles Caulier

(In reply to Gilles Caulier from comment #21)
> Ok, so i suspect a garbage in your digiKam configuration file.
> Rename your ~/.kde4/share/config/digikamrc file as *.old. Restart digiKam,
> and try again

I moved my "digikamrc" file away, started digiKam and click through the configuration wizard, without changing one single option. Then I pasted one image in the new album, but the EXIF tab of the "Metadata" side view keeps empty.

Well, i don't know why this problem happen, and why i cannot reproduce it here...

Somebody use git/master code (next 4.3.0 release) to check if this problem disappear ?

Gilles Caulier

Hi,

after reading about this bug report I think its something openSuSE 13.1 specific. I also run digikam 4.3 (package built by openSuSE) on a openSuSE 13.1 system and have the very same problem. 

To make sure that its not a specific setting I created a new user account on my system and started digikam for the new user and saw the same problem. 

From digikams component information I get this info:
LibExiv2: 0.23
LibKExiv2: 2.3.1

However when I try to find the version of libkexiv2 I get different versions. 

Which version does digikam dynamically link in:
[krienke@bliss:~/tmp] 1017 > ldd /usr/bin/digikam|grep exiv
        libkexiv2.so.11 => /usr/lib64/libkexiv2.so.11 (0x00002b3323dab000)
        libexiv2.so.12 => /usr/lib64/libexiv2.so.12 (0x00002b332c4e7000)

Which rpm package does this so lib file belong to:
[krienke@bliss:~/tmp] 1018 > rpm -qf /usr/lib64/libkexiv2.so.11
libkexiv2-11-4.11.5-298.1.x86_64

Print Information about the package:
[krienke@bliss:~/tmp] 1019 > rpm -qi libkexiv2-11
Name        : libkexiv2-11
Version     : 4.11.5
Release     : 298.1
Architecture: x86_64
Install Date: Fr 07 Feb 2014 10:42:08 CET
Group       : Development/Libraries/KDE
....

So digikam reports version  2.3.1 for libkexiv2, the rpm package management reports Version 4.11.5. 

Actually I am confused now.

Rainer

The right Exiv2 or libkexiv2 libraries version used by digiKam are listed in Help/Components Info dialog.

All other information taken from package manager cannot indicate which libraries are used by digiKam, but only installed one.

The digiKam dialog show components used to compile and link digiKam. There is no doubt using this dialog.

Gilles Caulier

Le 29/09/2014 16:25, Gilles Caulier a écrit :
> https://bugs.kde.org/show_bug.cgi?id=338783
>
> --- Comment #25 from Gilles Caulier <caulier.gilles@gmail.com> ---
> The right Exiv2 or libkexiv2 libraries version used by digiKam are listed in
> Help/Components Info dialog.
>
> All other information taken from package manager cannot indicate which
> libraries are used by digiKam, but only installed one.
>
> The digiKam dialog show components used to compile and link digiKam. There is
> no doubt using this dialog.
>
> Gilles Caulier
>

Hi,

The solution proposed Sept. 27 by Gian Paolo Sanino Vattier in"SOLVED: 
updated to DK4.3.0 purpose it crashes and can not go back to 4.2.0 ..." 
topic, solvemissing EXIFbug.

On opensuse 13.1, simply install both packages offered by Gian Paolo (or 
only libkexiv2-11-4.14.1-1.1, if DK 4.3.0-24.1 packageis already 
installed, which was my case).

#338783 The bug is solved for me.:-)

JP

Hello Jean Pierre,

thanks for the hint. Using libkexiv2 

http://ftp5.gwdg.de/pub/opensuse/repositories/KDE:/Current/openSUSE_13.1/x86_64/libkexiv2-11-4.14.1-1.1.x86_64.rpm

found by Gian Paolo Sanino Vattier it works fine now.  However the versioning of libkexiv2 seems to be  mixed up else I cannot understand that digikam tells me that this new Version is V2.3.1 and the package itself says it contains V4.14.1. 

Anyway it works...

Thanks
Rainer

Thanks for the hint on using "libkexiv2 4.14.1".
Unfortunatly on gentoo linux this package depends on KDE 4.14.1, which is still marked as unstable in gentoo portage. Using this would mean a lot of "accept_keywords"-configuration with great potential of other failure. ;)
So I'm waiting for KDE 4.14.1 becoming stable in "gentoo world". I will report again then.

Following response from Jean Pierre and Krienke, this file sound solved to update libkexiv2.

I close this file now. Don't hesitate to re-open if necessary.

Gilles Caulier