| Summary: | People tags appear duplicated after having moved them in the tag tree, if the tag was already present at /People/ | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | MarcP <iwannaberich> |
| Component: | Faces-Workflow | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | caulier.gilles, iwannaberich, metzpinguin |
| Priority: | NOR | ||
| Version: | 8.4.0 | ||
| Target Milestone: | --- | ||
| Platform: | Appimage | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
MarcP
2020-01-13 18:04:02 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. 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. digiKam 8.5.0 is out with many improvements in face detection and recognition. Please update these entry accordingly with this version. Thanks in advance... https://www.digikam.org/news/2024-11-16-8.5.0_release_announcement/ |