Summary: | Scanning collection for new faces (skip already scanned images) does not do anything | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Milan Knížek <knizek> |
Component: | Faces-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | caulier.gilles |
Priority: | NOR | ||
Version: | 2.0.0 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 7.0.0 | |
Sentry Crash Report: |
Description
Milan Knížek
2011-01-08 20:36:05 UTC
I cannot reproduce this problem with a simple test. After the first scan, the (internal) Scanned For Faces tag is set, and a test image is skipped subsequently. When I remove this tag to simulate a new image, it is scanned again. I tried again, while checking the internal tag in the database. You're right re. the "Scanned For Faces" tag - it works as expected. The problem is somewhere else - I am not sure if it is a bug or not: 1) When digiKam scans images for faces, it tags them internally in db with "Scanned For Faces". The tag is not written to image. 2) If the user creates a redundant copy of the image (even directly in album view - e.g. copy and paste and name it image_copy.jpg) digiKam immediately recognises the image in the albums view. 3) In digikam4.db, the image_copy.jpg is tagged as "Scanned For Faces" 4) However, image_copy.jpg is not shown in Faces view among those scanned (neither in People/Unknown or elsewhere). Therefore, running the scan for faces again (w/o clearing previous results) does not scan the image_copy.jpg. It seems that digiKam copies internal structure of tags from image.jpg to image_copy.jpg, but the "faces" extension does not include the image_copy.jpg in the results. (I tried to edit the image.jpg in external directory outside of digiKam albums and then copied it back. It was not tagged as "Scanned For Faces" - so it leads me to an assumption that digiKam recognises images based on a file hash.) I believe this bug was fixed with commit 5ec0f4b7 in August. Indeed, copying the face attributes was missing while the tags were correctly copied when digikam recognized a file as identical (by a hash) *** This bug has been marked as a duplicate of bug 280517 *** Not reproducible with 7.0.0-beta1 |