Bug 188709 - Tag hierarchy not properly restored from files (IPTC)
Summary: Tag hierarchy not properly restored from files (IPTC)
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Iptc (show other bugs)
Version: 0.10.0
Platform: Slackware Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-03 05:44 UTC by Ismael
Modified: 2017-08-13 07:31 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.5.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ismael 2009-04-03 05:44:46 UTC
Version:           0.10.0 (using KDE 4.2.1)
Compiler:          gcc 4.3.3 
OS:                Linux
Installed from:    Slackware Packages

Given the following Tag Hierarchy:

+ Author
--+ Argote
--...

+ USA
--...
--+ Minnesota
-----+ Rochester
-----...

+ Interior
--+ Applebees
--...

I've applied the written out leaves of this listed tag-tree to some images. Then I stopped Digikam, removed ~/.kde/share/config/digikamrc and ~/Pictures/digikam4.db and restarted Digikam. Upon restart it ran the first time wizard... everything was then configured as it was before.

Then I saw that some extra tags appeared (in the Tag view), namely "Argote", "Rochester", "Applebees" (besides "Author/Argote", "USA/Minnesota/Rochester" "Interior/Applebees" which appeared all right).

Upon closer inspection it seems that digikam is saving both, "Interior/Applebees" and "Applebees", into IPTC, and when re-importing them it reads them as different tags, getting both added to the database.

This is different from the 0.9.4 behavior where only "Interior/Applebees" would've been saved (which makes a lot of sense to me and makes it truly a copy of the information present in the database).

Here's a exiv2 -pi -PIk of one of the 0.10.0 tagged pictures with the problem:

Iptc.Application2.Program                    String      7  digiKam
Iptc.Application2.ProgramVersion             String      6  0.10.0
Iptc.Application2.Urgency                    String      1  8
Iptc.Application2.Keywords                   String     23  USA/Minnesota/Rochester
Iptc.Application2.Keywords                   String     18  Interior/Applebees
Iptc.Application2.Keywords                   String     13  Author/Argote
Iptc.Application2.Keywords                   String      6  Argote
Iptc.Application2.Keywords                   String      9  Rochester
Iptc.Application2.Keywords                   String      9  Applebees


And here's one tagged with 0.9.4:

Iptc.Application2.Caption                    String     22  Ranita sin enfocar (2)
Iptc.Application2.Program                    String      7  digiKam
Iptc.Application2.ProgramVersion             String      5  0.9.4
Iptc.Application2.Urgency                    String      1  8
Iptc.Application2.Keywords                   String     23  USA/Minnesota/Rochester
Iptc.Application2.Keywords                   String     14  Interior/House

Using: digikam-0.10.0 (compiled from source using GCC 4.3.3).
digiKam version 0.10.0
Exiv2 can write to Jp2: Yes
Exiv2 can write to Jpeg: Yes
Exiv2 can write to Png: Yes
Exiv2 can write to Tiff: Yes
Exiv2 support XMP metadata: Yes
LibCImg: 130
LibExiv2: 0.18
LibJPEG: 62
LibJasper: 1.900.1
LibKDE: 4.2.1 (KDE 4.2.1)
LibKExiv2: 0.5.0
LibKdcraw: 0.4.1
LibLCMS: 118
LibPNG: 1.2.35
LibQt: 4.5.0-rc1
LibRaw: 0.6.13-Release
LibTIFF: LIBTIFF, Version 3.8.2 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc.
Marble widget: 0.7.1
LibGphoto2: 2.4.4
LibKipi: 0.3.0
Comment 1 Ismael 2009-04-03 06:13:16 UTC
Looking closer into the code (dmetadata.cpp:455 in 0.10.0 source code), it seems that this should've never happened since the files are properly XMP tagged:

(this is with "exiv2 -px")
Xmp.tiff.Software                            XmpText    14  digiKam-0.10.0
Xmp.xmp.CreatorTool                          XmpText    14  digiKam-0.10.0
Xmp.xmp.Rating                               XmpText     1  0
Xmp.dc.subject                               XmpBag      4  Interior, Argote, Rochester, Applebees
Xmp.digiKam.TagsList                         XmpSeq      4  Interior, Author/Argote, USA/Minnesota/Rochester, Interior/Applebees

I'll try to dig deeper, I'm starting to think that it was MY mistake.
Comment 2 caulier.gilles 2009-04-03 08:06:37 UTC
With 0.9.x, only IPTC is supported. tags path are registered to Keywords tags.

IPTC has serious limitations in strings size and Char encoding.

With 0.10.x, XMP metadata are supported. Size limit and char encoding problem disappear. Tags path are recorded now in a dedicated digiKam XMP namespace. IPTC keywords only record tags names (not paths).

For me this bugzilla entry is not valid

Gilles Caulier
Comment 3 Christian Häne 2009-04-22 10:02:26 UTC
I can confirm the reported behaviour. I tested this with the current trunk version (r957440).
I imported a folder of about 1'500 pictures they all had correct xmp data and corrupted iptc data and i also got some tags duplicated in the way it was reported. But interestingly not all tags got duplicated.

What i did exactly with the pictures:
The pictures where originally taged with digikam 0.9.4 and then the xmp data was added with digikam 0.10.0. Adding xmp data i did with the synchonize images with db feature of digikam 0.10.0. Running this synchronization the iptc tags got corrupted. Before the synchronization they all had only the "/Node1/Node2/Leaf" strings in the keywords field of iptc. But after the synchronization the had all "/Node1/Node2/Leaf Leaf" in the iptc.
Then i imported this pictures into the current trunk digikam 0.11r957440. And then the tag duplication happend.
After this i rerun synchronize images with db and then something really strange happend to the iptc keyword field. The "/Node1/Node2/Leaf Leaf" string got duplicated in the iptc field and now i have "/Node1/Node2/Leaf Leaf /Node1/Node2/Leaf Leaf" in the iptc field.

In my opinion there are 2 bugs combined in this bug report.
First bug: The tags are not created correctly from xmp. When importing new pictures that have xmp and iptc data.
Second bug: IPTC keyword field gets corrupted. In my opinion only the /Node1/Node2/Leaf version should be saved in the iptc. I can't see any benefit in saving only Leaf in the IPTC data. The reason why i don't think it is good to save Leaf in the IPTC is because here something is produced that the user never entered into the system. In my opinon the synchonizer should remove any content that was in the keyword field before and should only save the correct representation of the tags.

If you have any questions to my comment please ask.

Christian
Comment 4 Marcel Wiesweg 2009-07-20 18:56:54 UTC
Ismael or Christian, could you please send me a sample image which triggers the reported behavior. If the file is large send it to my private mail address.
Thanks.
Comment 5 caulier.gilles 2011-12-12 20:25:12 UTC
Ismael or Christian,

do you see comment #4 from MArcel ?

Gilles Caulier
Comment 6 Ismael 2011-12-12 20:42:19 UTC
Woa, talk about an old bug.  Sorry I don't see this behavior anymore.
Actually, I kind of remember it went away after I updated something on
my system but my memory is vague about what actually happened. If you
ask me, this can be closed as I don't see this problem anymore in
recent releases.

On Mon, Dec 12, 2011 at 12:25 PM, Gilles Caulier
<caulier.gilles@gmail.com> wrote:
> https://bugs.kde.org/show_bug.cgi?id=188709
>
>
> Gilles Caulier <caulier.gilles@gmail.com> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |caulier.gilles@gmail.com
>
>
>
>
> --- Comment #5 from Gilles Caulier <caulier gilles gmail com>  2011-12-12 20:25:12 ---
> Ismael or Christian,
>
> do you see comment #4 from MArcel ?
>
> Gilles Caulier
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.