https://bugs.kde.org/show_bug.cgi?id=523760

            Bug ID: 523760
           Summary: Rebuild Fingerprints skips images sharing an identical
                    uniqueHash — only one image per duplicate content
                    group gets a Haar fingerprint
    Classification: Applications
           Product: digikam
      Version First 9.1.0
       Reported In:
          Platform: Other
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: Database-Similarity
          Assignee: [email protected]
          Reporter: [email protected]
  Target Milestone: ---

DESCRIPTION
When multiple cataloged images have identical file content (and therefore
identical Images.uniqueHash), only one of them receives a fingerprint entry in
ImageHaarMatrix after running Rebuild Fingerprints — even with "Scan for
changed or non-cataloged items" unchecked (full rebuild, not incremental). As a
result, Find Duplicates and Find Similar Images fail to detect these images as
duplicates of each other, despite them being byte-identical files.

STEPS TO REPRODUCE
1. Have three (or more) byte-identical JPEG files cataloged in digiKam, in
different albums/collections
2. Confirm they share the same Images.uniqueHash value
3. Delete similarity.db (with digiKam closed) to force a clean rebuild
4. Reopen digiKam, let it recreate similarity.db
5. Tools → Maintenance → Rebuild Fingerprints → select "for all" (not
incremental) → run to completion
6. Query ImageHaarMatrix for the imageids of the three identical files

OBSERVED RESULT
Only one of the three imageids has a row in ImageHaarMatrix. This was
reproduced across two independent full rebuilds.

EXPECTED RESULT
All three images should have their own fingerprint entry in ImageHaarMatrix,
since fingerprinting should operate per-image, not per-unique-content-hash.
Find Duplicates should be able to identify them as matches.

Supporting evidence (from direct SQLite inspection):
-- All three share identical uniqueHash
SELECT id, name, uniqueHash FROM Images WHERE id IN (119119, 118948, 118878);
-- 118878 | Mponjwane.JPG       | c7336cb1d42f6073215e4f608505fdff
-- 118948 | 153 - Mponjwane.JPG | c7336cb1d42f6073215e4f608505fdff
-- 119119 | 136 - Mponjwane.JPG | c7336cb1d42f6073215e4f608505fdff

-- All three are normal status, correctly cataloged, same available album root
SELECT id, name, status FROM Images WHERE id IN (119119, 118948, 118878);
-- all status = 1

-- But only ONE has a fingerprint after full rebuild
SELECT imageid FROM ImageHaarMatrix WHERE imageid IN (119119, 118948, 118878);
-- returns only: 119119

SOFTWARE/OS VERSIONS
Operating System (available in the Info Center app, or by running `kinfo` in a
terminal window): CachyOS Linux
KDE Plasma Version: 6.7.3
KDE Frameworks Version: 6.28.0
Qt Version: 6.11.1

ADDITIONAL INFORMATION
Ruled out during investigation: collection mount/availability status (confirmed
available in Settings → Collections), album subtree selection bugs (manual
per-album selection gave identical results to parent selection), incremental
scan staleness (full "for all" rebuild used, twice, independently), and file
corruption or unusual encoding (exiftool comparison shows both files identical
in format, dimensions, encoding — baseline JPEG, standard sRGB, no
CMYK/progressive/ICC anomalies).

This report was found via extensive independent troubleshooting that ruled out
every other explanation tested — the shared uniqueHash across affected images
is the only remaining common factor.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to