| Summary: | Faces in the "People" panel load slowly, and only when you scroll through them | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | MarcP <iwannaberich> |
| Component: | Faces-Workflow | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | caulier.gilles, iwannaberich, jose_oliver, kdeb, metzpinguin |
| Priority: | NOR | ||
| Version: | 8.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=466412 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
MarcP
2018-06-11 11:42:55 UTC
Where is the database, also on the NAS? If it is local, MySQL or SQLite? If the face thumbnails were created all for one person, will it take just as long next time? Maik Yes, I've temporarily moved the database (SQLite) to the NAS as well, for testing purposes, and that probably exacerbates the issue. Once the face thumbnails have been generated, loading times are generally much better. But for that, you must have spent a substantial amount of time scrolling through the person's faces in order to pre-load them. 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 This problem is fully reproducible here, and not only under Windows. Amount of people faces detected and not assigned is around 8000 and loading virtual album contents take age... Gilles Caulier 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 behavior is still present. This problem only arises for new faces when face detection is running. The second time they are loaded from the thumbnail database. The problem is that with face detection, CPU, file system, database or network drives are all under full load. It doesn't get any faster if we preloaded the thumbnails in this situation. Maik After running "Detect Faces", "Recognize faces", and "Rebuild Thumbnails" processes the face thumbnails are slow to load. They seem to be generated "on the fly" as I scroll down the Face tag view. When revisiting the Face tag again, it loads much faster. OS: Windows 10 DB: MySQL (data is on an SSD) Version: 7.2.0-rc (6f650d59) Processor: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz I don't know why you keep doing "Rebuild Thumbnails", but it doesn't make any sense. Only the normal thumbnails are currently being recreated. Face thumbnails are not recreated. And that makes sense in order to immediately get a correct thumbnail again when changing the size of the face in manual drawing mode. Maik Ok thanks. I ran "Rebuild Thumbnails" in the off chance it also rebuilds the Face Thumbnails. Hi all, What' the status of this file now ? Best Gilles Caulier Well, my initial report is still valid. Faces in the people panel load as you scroll by them, not in the background. This is inconvenient in slow networks because they can take a while to generate. The rest of the thumbnails in digikam, in contrast, seem to be generated in the background when an album is accessed, so it feels quicker. So, for instance, if a person has 200 face regions, when you click on that person, only the "focused" thumbnails will load (around 20, depending on your screen size and zoom), and once it finishes loading, scroll down and wait for the next batch to be generated. So you have to scroll 10 times until the whole face set thumbnail is generated. I created a new sqlite thubmnail database and ran the "Rebuild Thumbnails" option from Tools -> Maintenance. Full image thumbnails were generated, but once completed I went to the "Faces" view and those had not been generated. The face thumbnails were generated "on the fly" as I scrolled through the faces - I could see the sqlite file increase in size as I did this. Could "Rebuild Thumbnails" also include the face thumbnails as well? digikam 7.5 windows. I can confirm that face thumbnails are built and added to the thumbnail database only when first required for display. Mousewheel scrolling through thousands of blank face thumbnails will queue them all for generation in the background. This used to be much more annoying because any database maintenance used to trash all the face thumbnails and that seems to be fixed. It doesn't bother me much now, but, when you detect a face you already have the file open to do it. Why wouldn't you generate a face thumbnail at the same time? Hi all, digiKam 8.0.0 is out. This report still valid ? Best regards Yes, this is still valid for v8.0. Here the wish is expressed that the face thumbnail is already created during face detection. In fact, that is already the case. The image in the face pipeline that is also used for detection is used for the thumbnail - it is not reloaded. I debugged this and it works perfectly. If I detected a large set of faces but don't have the people view open and after the face detection process switch to Unknown people, the face thumbnails are there immediately and no more are generated. Maik Hi, This is not my experience. After new pictures are found, they are scanned for faces and recognized (I have checked the option to scan them automatically on startup on the settings). Then, I usually go to Unconfirmed o Unrecognized sections in the People panel to tag them. At that point I think the face thumbnails for the new faces area already generated. But then, when you confirm any of these new faces, all the face thumbnails in that picture will need to be recreated, so you have to go to each one of the persons in that picture and scroll through that specific picture to have it generated. My network is rather slow, so that process is very noticeable because it takes several seconds per face. Ideally, the face thumbnails created when the faces are first detected shouldn't need to be recreated unless the image is edited (just modifying the metadata should not trigger the regeneration of the thumbnail). 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 474105 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 @MarcP, This problem still reproducible with the new digiKam 8.2.0 pre-release Windows installer available at usual place: https://files.kde.org/digikam/ This new bundle is based on last Qt framework 5.15.11 and KDE framework 5.110. Thanks in advance Gilles Caulier |