Bug 262577 - Scanning collection for new faces (skip already scanned images) does not do anything
Summary: Scanning collection for new faces (skip already scanned images) does not do a...
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Faces-Engine (show other bugs)
Version: 2.0.0
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-08 20:36 UTC by Milan Knížek
Modified: 2019-12-23 15:03 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 7.0.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Knížek 2011-01-08 20:36:05 UTC
Version:           2.0.0 (using KDE 4.5.4) 
OS:                Linux

When new images are added to the collection and face scanning started with option "skip already scanned images", no images are scanned at all.

Reproducible: Always

Steps to Reproduce:
1 Start digikam
2 Scan collection for faces "scan again and merge results" (images are scanned and faces found. The pop-up window about scanning keeps shown as it was reported in other bug. Must be cancelled manually.)
3 Add new images to collection (e.g. drag&drop in nautilus) and make sure they are shown in Album view.
4 Scan collection for faces "skip already scanned images"


Actual Results:  
No images are scanned. (The pop-up window about scanning keeps shown - I think this was reported in some other bug. Must be cancelled manually.)

Expected Results:  
Images are scanned and potentially some faces detected/recognised.

As a workaround, it is possible to scan the complete collection again. Then, the new images are found and faces detected. However, this also results in false positives, which were already marked as "not a face" in earlier run.
Comment 1 Marcel Wiesweg 2011-02-04 21:44:56 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.
Comment 2 Milan Knížek 2011-02-06 08:34:51 UTC
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.)
Comment 3 Marcel Wiesweg 2011-09-27 19:54:22 UTC
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 ***
Comment 4 caulier.gilles 2019-12-23 15:03:21 UTC
Not reproducible with 7.0.0-beta1