SUMMARY Tags that include people can appear duplicated after syncing the metadata, if the tag already exists in People/PersonName and is moved elsewhere in the tag tree in another computer (e.g. People/Family/PersonName), and data is synced. It appears in both places (People/PersonName and People/Family/PersonName). It does not happen with tags that do not contain faces. STEPS TO REPRODUCE 1. Make sure metadata changes are written to files (or sidecars). 2. Tag a face, so it appears under "People" in the tag tree as a keyword. 3. From another installation of digikam, sync that picture, so the tag it also appears under "People". 4. From the second digikam, move the tag to a subfolder and save the changes. 5. Start again the second digikam, re-sync that picture's metadata. OBSERVED RESULT The tag appears both in the subfolder and in "People". EXPECTED RESULT The tag should have been moved to the subfolder only. SOFTWARE/OS VERSIONS digikam-7.0.0-beta1-20191230T120628-x86-64.appimage Ubuntu 18.04LTS with Unity
Of course, if you start from a clean database, and you scan the picture after the tag has been moved, it will only appear in the subtag only. The problem only appears if the tag already exists at the root of /People, that it won't be removed from there, but it will be copied to the subtag too.
I am sorry, in Step 5, I meant to say: "5. Start again the FIRST digikam,".
Without testing it, I suspect that the "old" problem is that we don't delete any tags. You should actually activate the database clean function for this operation. As I said, do not activate this option permanently. We already had the subject. Maik
Oh, that is already with the option "Clean up the metadata from the database when rescan files" activated. I activate it when I want to sync the library in two computers. Regular tags get cleaned up. Tags containing faces do not.
Git commit 1d17e816245a1c3c3244b85f89d0e98002b92f77 by Maik Qualmann. Committed on 13/01/2020 at 21:09. Pushed by mqualmann into branch 'master'. we need the tag ID and not the image ID M +1 -1 core/libs/database/coredb/coredb.cpp https://invent.kde.org/kde/digikam/commit/1d17e816245a1c3c3244b85f89d0e98002b92f77
This is difficult to fix. We cannot just delete the tag, it could be linked to other images. In addition, people names have no path. If the name is found among people tree, it is used. Maik
This is what I thought. In the metadata, people tags have no path. It can use the path of the regular tag, but you can never be sure that the user did not also want to keep that person there, at the root of People, so you cannot remove it from there. This is an unintended consequence of treating regular tags and people tags as the same thing (so I don't think it can be solved if we don't deal with bug 392007 first, but that could open up a can of worms)
The problem is, it's the standard. I have a image here that was processed by Picasa with faces. In addition to the metadata entry of the face rectangles with the names of the faces, there is also the tag list with the path + names again. So the way digiKam would do it. Maik
As far as I know, Picasa treats faces and tags separately (I remember having to sync them every time, manually), but it doesn't have any kind of tag hyerarchy, just a flat list for everything. So it's not as advanced as Digikam and does not have these kinds of problems.
Another thing, if you want to separate tags and face tags, you should no longer use sub-tags, because there is no way to save this tag path in the images. But I find a face tag list without sub-tags bad. In your example, I would recommend doing without sub-tags in peoples... Maik
I know. I remember in the GSoC2019 we faced that dilemma. We could leave the hierarchy just for regular tags, and display all People in a flat list, sorted alphabetically (like in Picasa). But a tag tree for People is very convenient for putting people into categories. Anyway, I don't think there is a perfect solution.
I just realized that this behavior is likely the cause of Bug 392008. Maybe they can be even considered duplicates.
digiKam 7.0.0 stable release is now published: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Best Regards Gilles Caulier
This problem still exists, but has a difficult solution because face rectangles cannot store a hierarchy.
Thanks for the feedback Marc
@MarcP digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier
Yes, this is still relevant.
Hi all, The digiKam 8.4.0 Appimage bundle pre-release is now based on last modern frameworks Qt 6.7.0 and KDE 6.2.0. File can be downloaded at usual place : https://files.kde.org/digikam/ Take a care : the bundle is named with the suffix "-Qt6" not "-Qt5". This bundle is compiled under Ubuntu 22.04 and require a Linux with GlibC version >= 2.35 to run. Can you reproduce the dysfonction with this version? Thanks in advance Gilles Caulier
Hi. Yes.