SUMMARY Ok, this is regarding a possible optimization when loading face thumbnails. Face thumbnails only load when you scroll through them (Bug 395241), and as such, it is pretty common that when you see the faces for a specific person, many thumbnails still need to be generated. Now, the most common scenario will be one in which a person already has many of these thumbnails already generated in the database plus some new thumbnails that still need to be generated (e.g. let's say someone has 40 face regions, 30 with thumbnail in the db and 10 which need to be generated). The issue is the following: Face thumbnails load sequentially. That is, if thumbnail #2 is needs to be generated, but thumbnails 3-15 are already present, thumbnails 3-15 won't show until 2 has finish generating. This is specially relevant when using a NAS or other slow network, since each thumbnail can take 4-5 seconds to generate, so most of the thumbnails for a person won't be visible until the few missing ones have been generated. I think the ideal would be to first show all the available thumbnails, regardless of the order, and then generate the missing ones. Let me know if you need more details or it's not clear what I'm asking. Thanks! STEPS TO REPRODUCE 1. Tag a person tagged with multiple face regions across many pictures. 2. View that person in the Face panel to generate the face thumbnails. 3. Tag some more faces for the same person. 4. View that person in the face panel once again OBSERVED RESULT Notice how the faces tagged in #1, already in the database, don't show the thumbnail until the faces tagged in #3 have their thumbnail generated. EXPECTED RESULT First show the already generated thumbnails immediately, and then generate and show the remaining ones. SOFTWARE/OS VERSIONS digiKam-8.2.0-20230902T115106-x86-64.appimage Linux/KDE Plasma: Kubuntu 22.04 LTE (available in About System) KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION This is related to bug reports bug 395241, bug 461838, bug 444767 (is this a duplicate?), and bug 395241.
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