Bug 416213 - People tags appear duplicated after having moved them in the tag tree, if the tag was already present at /People/
Summary: People tags appear duplicated after having moved them in the tag tree, if the...
Status: REPORTED
Alias: None
Product: digikam
Classification: Applications
Component: Faces-Workflow (show other bugs)
Version: 8.4.0
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-13 18:04 UTC by MarcP
Modified: 2024-05-06 00:54 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description MarcP 2020-01-13 18:04:02 UTC
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
Comment 1 MarcP 2020-01-13 18:07:36 UTC
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.
Comment 2 MarcP 2020-01-13 20:26:43 UTC
I am sorry, in Step 5, I meant to say: "5. Start again the FIRST digikam,".
Comment 3 Maik Qualmann 2020-01-13 20:35:12 UTC
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
Comment 4 MarcP 2020-01-13 20:39:05 UTC
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.
Comment 5 Maik Qualmann 2020-01-13 21:10:42 UTC
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
Comment 6 Maik Qualmann 2020-01-13 21:48:18 UTC
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
Comment 7 MarcP 2020-01-13 21:54:51 UTC
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)
Comment 8 Maik Qualmann 2020-01-13 22:07:33 UTC
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
Comment 9 MarcP 2020-01-13 22:10:20 UTC
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.
Comment 10 Maik Qualmann 2020-01-13 22:15:04 UTC
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
Comment 11 MarcP 2020-01-13 22:19:48 UTC
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.
Comment 12 MarcP 2020-01-27 21:34:15 UTC
I just realized that this behavior is likely the cause of Bug 392008. Maybe they can be even considered duplicates.
Comment 13 caulier.gilles 2020-08-04 08:26:11 UTC
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
Comment 14 MarcP 2020-08-04 09:39:31 UTC
This problem still exists, but has a difficult solution because face rectangles cannot store a hierarchy.
Comment 15 caulier.gilles 2020-08-04 11:30:21 UTC
Thanks for the feedback Marc
Comment 16 caulier.gilles 2023-05-04 02:47:31 UTC
@MarcP

digiKam 8.0.0 is out. This entry still valid with this release ?

Best regards

Gilles Caulier
Comment 17 MarcP 2023-05-05 15:51:42 UTC
Yes, this is still relevant.
Comment 18 caulier.gilles 2024-04-20 03:23:01 UTC
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
Comment 19 MarcP 2024-05-05 23:59:47 UTC
Hi. Yes.