Summary: | All face thumbnails in a picture are recreated after a face is tagged, which is not optimal performance-wise | ||
---|---|---|---|
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.0.0 | ||
Target Milestone: | --- | ||
Platform: | Appimage | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=466412 | ||
Latest Commit: | Version Fixed In: | 8.2.0 | |
Sentry Crash Report: |
Description
MarcP
2022-11-14 20:13:48 UTC
The thumbnails are not recreated, why should they? Yes, they are all reloaded as there has been a metadata change. I've been examining a lot of code in the process of making improvements to digiKam-8.0.0 to see if we can optimize further. No, there aren't many options left. Maik But the thumbnails are reloaded from the picture iself, not from the thumbnail already existing in the database, aren't they? In a NAS, that would mean that a single picture would need to be transferred 20 times if there are 20 faces in it. Or am I getting it wrong? Couldn't all the faces in a picture be refreshed from a single transfer? Anyway, it's a pity. Would it be possible to have two kinds of refresh, one that just refreshes the metadata, and another one that also refreshes thumbnails and face-thumbnails? Ok, I have checked the traffic on my NAS, and yes, a single picture will be transferred as many times as faces there are in the photo (so, 100MB for a 5MB photo with 20 faces on it). Couldn't digikam get the photo just once, and recreate all the face-thumbnails from that info? That would greatly improve the performance. Maik, But we have a large memory cache used to reduce network idle... right ? Gilles Using my small thumbnail database from Bug 474105, I can confirm that we don't create a new thumbnail when the face is tagged. I would close this bug for digiKam-8.2.0. Maik Fixed with #474105 |