Version: (using KDE 4.1.4) Compiler: gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) x86_64 platform OS: Linux Installed from: Fedora RPMs Here is what I did to reproduce this problem along with my observations: - I started digikam with a fresh digikam4.db - quit digikam - created two copies of some image in one of the albums with the 'cp' utility - started digikam - ran a duplicates search - using digikam I deleted the manually created copies of a know image - using digikam I deleted one similar duplicate image which I had in my album originally - did Albums -> Refresh - at this point the item counts are still as they were before I deleted the images (3 and 2 respectively). Also, duplicate reference images still appear in the search results although only one image shows up in the middle panel when I click on either reference image. - then I restart digikam - the duplicate search results still contain images with no existing duplicates as before and the item counts are wrong - rerunning the search while one of the duplicate images is selected brings the search results to the inconsistent state described in bug 182043: - the search results still show the old duplicates and item counts. - clicking on the first duplicate reference image (whose duplicates should have been deleted) shows an unrelated set of duplicate images - screenshot #1. - clicking on another duplicate reference image (which was selected ruing the search and which should have it's duplicate removed) showed a blank middle panel - screenshot #2. This is more general version of bug 182029 and I guess 182043. I'm marking this as a bug since it seems very unintuitive from a user perspective, although technically it could be thought of as a feature (keeping search results as persistent as possible until the search is re-run).
Created attachment 30665 [details] screenshot #1
Created attachment 30666 [details] screenshot #2
*** Bug 182029 has been marked as a duplicate of this bug. ***
*** Bug 182043 has been marked as a duplicate of this bug. ***
Cause and workaround for this are simple: You need to re-create the duplicates search after you removed and added images. The search is done once and then stored by image id. Entries from db can be removed, and new ones added, all this does not touch the duplicates search. It would not be easy to sync the duplicates search everytime a picture is added / removed. We could make this "offline" situation more clear. This affects only the duplicates search, all other searches search "online".
But shouldn't removing images at least update the view? Isn't this possible and logical? When new images are added, it might be obvious that you need to re-run the find duplicates search. But when I delete images (mainly in the duplicates search window), I definitely expect the number to be updated.
>Cause and workaround for this are simple: You need to re-create the duplicates >search after you removed and added images. Perhaps a flag in DB can be used to see if collection is dirty (with images stats as how many images have been added ?). In this case, something can be done when duplicates search is selected by user to ask that duplicates search need to be updated. Also, i'm not sure if haar matrix is recomputed automatically when new images are added to collection (by camera interface, or with Editor) Gilles
No the haar matrix is not recomputed automatically. Haar matrix computation can be orders of size more expensive than just scanning, so this would really slow down things.
Michael, This file still valid using digiKam 2.x serie ? Gilles Caulier
Sorry, I don't have time/ability to reproduce this at the moment.
New digiKam 4.11.0 is available : https://www.digikam.org/node/740 Can you reproduce the problem with this release ?
With digiKam 5.0.0, this problem is not reproducible. I close this file now. Don't hesitate to re-open if necessary. Gilles Caulier