| Summary: | Faces load sequentially, not showing existing face thumbnails in the database until a previous one has been generated | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | MarcP <iwannaberich> |
| Component: | Faces-Workflow | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | caulier.gilles, iwannaberich, metzpinguin |
| Priority: | NOR | ||
| Version: | 8.2.0 | ||
| Target Milestone: | --- | ||
| Platform: | Appimage | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/graphics/digikam/-/commit/66b43b1031d52c72602ac15af637ba59f0dc2b7f | Version Fixed In: | 8.2.0 |
| Sentry Crash Report: | |||
| Attachments: | Simple diagram to illustrate behavior | ||
|
Description
MarcP
2023-09-03 17:48:51 UTC
I tested it again with a very small collection in order to be able to control the thumbnail database well. We've been creating a face thumbnail for a while now when it's drawn manually and it's automatically detected by launching face detection. It's not created automatically for imported images, but rather through the view. The only way I can explain your problem is that you opened the view during face detection. When we detect a face, it is saved in the core database, this immediately triggers adding in the view, the open view triggers thumbnail creation, thumbnail creation is also done in the face engine. We have a block against creating the same thumbnail at the same time, but it may not always work. Please test once that you have not opened the "Unknown" face view during face detection. After face detection, when you open the "Unknown" face view, do the thumbnails load quickly? Maik Created attachment 161381 [details]
Simple diagram to illustrate behavior
Hello Maik, thanks for your quick response. Iḿ not sure we are talking about the same thing, though. I can verify that the behavior I describe happens even when digikam is not importing or processing anything. I have attached a simple diagram that will help illustrate my point. Image you have tagged the face of a person in 48 photos. These face thumbnails have already been generated and are in the database (thumbnails-digikam.db I presume). When you browse that person's faces, these load immediately. So far, so good. Now, imagine you tag that face in two additional photos. So, 50 in total. Chronologically speaking, the two new pictures are the 13th and 16th respectively. Now you browse to that person's faces, and what you see is the following: 1) faces from 1 to 12 load immediately, but 13 to 50 are invisible. 2) When after a few seconds face 13 is generated, 14 and 15 appears immeidately (since they were already in the database). 16 to 50 still invisible. 3) Next, 16 is generated. Once it's done, the rest of the pictures will be visible again (16-50). So what I'm proposing here: 1) Load faces already in the database first (so 1-12, 14-15, 17-50). 2) Then, start generating the missing ones (13 & 16). I hope I made it clearer this time. Thanks for your time! I already understand the problem. If you scroll down, the thumbnails are requested according to the view model. If there are any in between that are not yet in the DB, they will be generated first and the loading of the other thumbnails will stop. This is of course particularly noticeable on a slow system. However, we cannot start a separate process for each thumbnail, as this would overload memory. There are many image formats that need to be fully loaded. What would be conceivable are 2 processes, one that loads and generates and one that only loads from the DB. Maik (In reply to Maik Qualmann from comment #4) > I already understand the problem. If you scroll down, the thumbnails are > requested according to the view model. If there are any in between that are > not yet in the DB, they will be generated first and the loading of the other > thumbnails will stop. This is of course particularly noticeable on a slow > system. However, we cannot start a separate process for each thumbnail, as > this would overload memory. There are many image formats that need to be > fully loaded. What would be conceivable are 2 processes, one that loads and > generates and one that only loads from the DB. > > Maik Exactly. Yes, being able to immediately see all the available thumbnails, and then sequentially generate the missing ones would be perfect. Currently, when you are browsing faces, the moment you encounter one missing thumbnail, nothing else is shown (even for other people) until that thumbnail finished generating. Git commit a15e63f394fb8e2df283e960f8881456e446fa7c by Maik Qualmann. Committed on 05/09/2023 at 22:15. Pushed by mqualmann into branch 'master'. for a test add a thumbnail thread that only loads from storage Related: bug 395241 M +51 -2 core/libs/database/models/itemthumbnailmodel.cpp M +2 -0 core/libs/database/models/itemthumbnailmodel.h M +5 -0 core/libs/threadimageio/fileio/loadingdescription.cpp M +3 -1 core/libs/threadimageio/fileio/loadingdescription.h M +8 -6 core/libs/threadimageio/thumb/thumbnailcreator.cpp M +5 -3 core/libs/threadimageio/thumb/thumbnailcreator.h M +13 -5 core/libs/threadimageio/thumb/thumbnailloadthread.cpp M +6 -3 core/libs/threadimageio/thumb/thumbnailloadthread.h M +4 -2 core/libs/threadimageio/thumb/thumbnailtask.cpp https://invent.kde.org/graphics/digikam/-/commit/a15e63f394fb8e2df283e960f8881456e446fa7c Hi Marc, it would be good if you could test this patch as soon as possible to see if it brings the desired success. If not, I would go back to the previous code again. Are you using our AppImage? Maik Hi Maik, thanks for your time and effort. Yes, i usually tend to use the lastest appimage available. I will try it as soon as I can and let you know, probably tomorrow. Gilles, can you please create a new AppImage? Best Maik yes, sure, this evening... Gilles Hi Maik, I have been trying the latest appimage (digiKam-8.2.0-20230907T053317-x86-64.appimage) and it is definitely a big improvement. With this change, I can keep scrolling down to a person's list of faces without having to wait the previous ones to generate, making the whole thing much smoother. I still get little freezes in the interface from time to time, particularly when some files are being read or written, like during the initial scan, but this is probably an unrelated issue. In any case, at least in my opinion, now it feels much better to browse faces. Thanks! Git commit 66b43b1031d52c72602ac15af637ba59f0dc2b7f by Maik Qualmann. Committed on 03/10/2023 at 21:51. Pushed by mqualmann into branch 'master'. cleanup thumbnail model FIXED-IN: 8.2.0 M +1 -1 NEWS M +7 -29 core/libs/database/models/itemthumbnailmodel.cpp M +0 -7 core/libs/database/models/itemthumbnailmodel.h https://invent.kde.org/graphics/digikam/-/commit/66b43b1031d52c72602ac15af637ba59f0dc2b7f |