SUMMARY I've observed this occasionally. Sometimes I am going to drag and drop a duplicated person in the People panel, only to realize that immediately, the item count to that tag changes (e.g. from 4 to 0). This is usually a consequence of having updated the database where that tag was already merged or deleted, outside digikam (or by another user). Somehow, the number was not updated until I hovered the mouse or I clicked on it. I am not sure if it only happens in People. I will report if I see it somewhere else. SOFTWARE/OS VERSIONS Ubuntu 18.04 with Gnome and digikam-6.1.0-git-20190404T203330-qtwebkit-x86-64.appimage
7.0.0-beta1 is out with new Face Recognition algorithm based on Deep Learning/Neural Network API from OpenCV https://download.kde.org/unstable/digikam/ Please test and give us a feedback Thanks in advance Gilles Caulier
*** Bug 416180 has been marked as a duplicate of this bug. ***
I would like to work on fixing this bug. I'd be very grateful for any pointers regarding where to look for possible fixes.
Hi Kartik, There is certainly a signal propagation missing between the GUI and the database interface to represh the count of item in tree view. Some pointers in source code : https://invent.kde.org/kde/digikam/-/blob/master/core/app/views/sidebar/peoplesidebarwidget.cpp#L101 This is the instance of the face tree view tags based on keywords tree view. The model is different of course and customized for face tags, even in face tags are regulars tags in database, using special properties. https://invent.kde.org/kde/digikam/-/blob/master/core/libs/tags/widgets/tagfolderview.cpp This is the generic tags folder view implementations based on TagTreeView class. https://invent.kde.org/kde/digikam/-/blob/master/core/libs/album/treeview/tagtreeview.cpp This is the low level Tag album tree view class. https://invent.kde.org/kde/digikam/-/blob/master/core/app/views/utils/dmodelfactory.cpp#L70 This is the model used to managed face in tree view. Look the famous properties about item count : d->tagFacesModel->setTagCount(TagModel::FaceTagCount); Best Gilles Caulier
Thanks for the reply Gilles. I've gone through the files that you mentioned. I understand that the TagFolderView in PeopleSidebar, keeps tracks of tags as TAlbums, which are created based on the name that we assign to the tag (like "Jack" etc.) I can't find where the "new" counter is being stored, and how it's being updated. I don't think it's stored as a property of the tag, is it? Could you please direct me to the files associated with this counter? Thanks in advance.
I'm currently trying to fix the duplicate bug 416180. Confirming/Rejecting a face is dealt by DigikamItemView::confirmFaces() (and rejectFaces()) respectively. Maybe there could be an implementation at the end of these methods to update the new counter of the corresponding tag? I'll need to understand how the new counter is associated with each tag for this matter. Is it something calculated actively for each tag, every time number of unconfirmed results change? Thanks.
That would not be the right way. Check out the CoreDB. After writing or changing information in the database, an event is triggered via the corresponding record changeset and this leads to the models und ItemInfos. Maik
The ImageTagProperties table is important here. If the entries change here, it affects the number of people in the people tree view. Maik
Thanks a lot for the suggestions, Maik. I never checked the libs/database folder, this really improved my understanding. Whenever we confirm/reject face suggestions, the database is written to by CoreDB::addImageTagProperty(). So adding a recordChangeSet() at the end of this function should notify the tag tree view that the count has changed? So, we may do: d->db->recordChangeset(TagChangeset(tagId, TagChangeset::PropertiesChanged)); Is this the correct approach? Thanks Kartik.
The method I proposed does update the new count, however it always trails behind the actual situation by 1 image. For eg. if I had 7 new unconfirmed faces, and I confirmed one, the count will not decrement immediately. It will do so only on a second confirm (or reject), and will decrement to 6 (when it should actually show 5 new, as two confirms have been made). Similarly when I'm left with only one new suggestion and I confirm it, the counter will be stuck at 1 (unless I click on the left sidebar, which was the main issue to begin with) Any suggestions to resolve this would be appreciated. Thanks Kartik.
Update: I have resolved the issue. In CoreDB::AddImageTagProperty I added d->db->recordChangeset(TagChangeset(tagId, TagChangeset::Added)); In CoreDB::removeImageTagProperties I added d->db->recordChangeset(TagChangeset(tagId, TagChangeset::Deleted)); It works as desired, please clarify whether this is the appropriate approach. Thanks Kartik
Yes, that is a solution to this problem. Create a patch and upload it here. So that we can apply the patch and close the bug. Good work. Maik
I have made a merge request. https://invent.kde.org/kde/digikam/-/merge_requests/12 Thanks for all the help Marc , Maik and Gilles :)
The patch is not yet perfect. You add a CMakeLists.txt.user with 8600 lines. Maik
Git commit 61e4cedf49d8fbb5efcd6dc43f47a4e09b3ddd14 by Maik Qualmann. Committed on 15/03/2020 at 13:47. Pushed by mqualmann into branch 'master'. FIXED-IN: 7.0.0 See merge request kde/digikam!12 https://invent.kde.org/kde/digikam/commit/61e4cedf49d8fbb5efcd6dc43f47a4e09b3ddd14
Git commit e4b99936c71f0894fdd448d1cba3007bc4d44417 by Maik Qualmann. Committed on 24/03/2020 at 18:48. Pushed by mqualmann into branch 'master'. add new TagChangeset to update only Related: bug 419171 FIXED-IN: 7.0.0 M +2 -1 NEWS M +1 -0 core/libs/album/manager/albummanager_talbum.cpp M +2 -2 core/libs/database/coredb/coredb.cpp M +1 -0 core/libs/database/coredb/coredbchangesets.h https://invent.kde.org/kde/digikam/commit/e4b99936c71f0894fdd448d1cba3007bc4d44417