Bug 300407 - Tags not written to files properly, old tags left over
Summary: Tags not written to files properly, old tags left over
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Tags-Engine (show other bugs)
Version: 2.5.0
Platform: Gentoo Packages Linux
: NOR major
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-21 19:41 UTC by DrSlony
Modified: 2021-05-05 11:50 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description DrSlony 2012-05-21 19:41:35 UTC
Since I started using digiKam a few years ago my tagging habits changed and I wanted to clean the tags up and make them consistent, so I rearranged them into neat hierarchies and delete the old tags.
I also wanted to recreate digikam.db, to start afresh, but I wanted to keep the db just in case, so I did a Settings > Database Migration. The old db was about 50MB, the migrated one was 21MB. It cleaned some stuff out, good, that was the point.

Now I closed digiKam, deleted digikam.db (the old one, the new one was kept in backup elsewhere) and restarted digiKam. After scanning my photos, I noticed that the old tags were back.
I selected all the photos in each collection (I have 3 collections), in the Captions/Tags tab I selected Information > Template > my new template, and clicked on More > Write metadata to each file.
This took a good hour or two.
I did not enable "write metadata to raw files" so I presume digiKam wrote metadata to all files except my PEFs, whose metadata it stored in the digikam.db file.

Now I closed digiKam, deleted digikam.db, and restarted it. It should only show the new tags since it would read them from the non-raws, and the raw files should have no tags since the db was deleted. Well that's not entirely the case.

I see the new tags, but I also see the old ones. In fact every first photo in every album has the old tags and the new tags. Every other photo has just the new ones.
e.g.:
/media/photos/2012-05-01/001.jpg will have both old and new tags
/media/photos/2012-05-01/002.jpg - 100.jpg will have just the new tags.


digiKam version 2.6.0-rc
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: external shared library
LibExiv2: 0.21.1
LibJPEG: 80
LibJasper: 1.900.1
LibKDE: 4.8.3 (4.8.3)
LibKExiv2: 2.1.0
LibKGeoMap: 2.0.0
LibKdcraw: 2.0.1
LibLCMS: 119
LibLensFun: external shared library
LibLqr: internal library
LibPGF: 6.11.32 - external shared library
LibPNG: 1.5.10
LibQt: 4.8.1
LibRaw: 0.14.4
LibTIFF: LIBTIFF, Version 4.0.1 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc.
Marble Widget: 0.12.97 (0.13 Release Candidate 2)
Parallelized demosaicing: Yes
Database backend: QSQLITE
LibKface: 2.0.0
LibKipi: 1.3.0
LibOpenCV: 2.3.0
Libface: 0.2

Reproducible: Always




I can't use the photos until the old tags are removed, e.g. my old template with my old defunct email address, therefore this is a major bug.
Comment 1 DrSlony 2012-05-21 20:02:05 UTC
Correction, it's not the first photo in every album, but almost always one per album.
Comment 2 DrSlony 2012-05-21 20:24:31 UTC
I've looked at this more closely using exiftool. When I assign a tag to a file and click on "write metadata to image" it shows up when i run that image through exiftool.

Now when I go to the Tags tab and delete a tag, the image is unmodified!
Is this intentional digiKam behavior? If a user deletes a tag, he wants it obviously gone. It should be removed from the XMP/IPTC embedded in the image. How else could I possibly delete all traces of a tag from 20 000 photos in a thousand albums? If this worked as I expected it to, it would have been as easy as deleting that tag and waiting for digiKam to write the change to all the images.
Comment 3 Andrew Goodbody 2012-05-21 20:45:10 UTC
Yes, I don't like this behaviour of digikam. When you edit the tags hierarchy ie when deleting or moving tags, you are not affecting images that already have those tags applied. The workaround that I have when deleting tags is to use the tags search to select all images with the old tag and then I can unselect that tag which will get applied to all those images. When moving tags I have to apply a temporary tag, delete the first tag and then recreate the tag in the new position and finally remove the temporary tag. This is a clumsy way to work and not at all intuitive.
Comment 4 DrSlony 2012-05-21 21:09:08 UTC
I tagged a photo with the following:
kaka, bar, chestnut, test, foo

To remove all XMP and IPTC I ran:
exiftool -XMP:all= -IPTC:all= -overwrite_original 0005.tif

I verified that all XMP/IPTC tags were deleted using:
exiftool -a -G1 -s 0005.tif

or to simplify it:
exiftool -a -G1 -s 0005.tif | grep -i kaka

No "kaka".

In digiKam I clicked
Album > Reread metadata from images
as well as
Images > Reread metadata from selected images

digiKam still shows the deleted tags in the following places in the right metadata panel:
IPTC > keywords (contains the deleted tags "kaka, bar, chestnut, test, foo")
XMP > Microsoft Photo > Last Keyword XMP
XMP > Dublin Core > Subject
XMP > digiKam schema > Tags List
XMP > lr > hierarchicalSubject

I checked the file again using exiv2. Neither exiv2 or exiftool reported any of these tags in the file, so I'm sure the tags digiKam is showing are from its own digikam.db but it shouldn't, because I clicked "reread metadata from images"!
I'm distressed.
Comment 5 caulier.gilles 2012-05-21 21:14:08 UTC
Sound like a duplicates of #268688. Right ?

Gilles Caulier
Comment 6 DrSlony 2012-05-21 21:24:24 UTC
"I'm sure the tags digiKam is showing are from its own digikam.db"
I confirmed this by deleting digikam.db - now the right panel reflects the true contents of the files' metadata.

Yes Gilles, 268688 describes my problem perfectly. I'm happy it's already being addressed, though a little scared that it's a year old and still valid ;]
Thank you for looking into it.

*** This bug has been marked as a duplicate of bug 268688 ***
Comment 7 caulier.gilles 2021-05-05 11:50:54 UTC
Fixed with #268688 and not reproducible with digiKam 7.3.0 and Exiv2 0.27.4