Bug 496238

***
If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports

Please remove this comment after reading and before submitting - thanks!
***

SUMMARY
In many cases, I have multiple instances of a photo in an album, where perhaps the content was merged with one set preprocessed (i.e. converted to another format, or auto contrast adjusted etc) where the similarity detection engine misses these- even with the range set to some absurdly low value (50%)

STEPS TO REPRODUCE
1. As above, just load several variant of an image- maybe a few pixels crop difference, or a contrast change. Not sure of which things the engine is most sensitive to. 
2. Select on, and right click select 'find similar'


OBSERVED RESULT
System may return a subset of the 'duplicate' variants, or all, or none, again depending on whatever variable the system seems to care about most. Photos that are very easily detected via Image Dedup etc are missed. 

EXPECTED RESULT
While I dont have any expectation that the similarity engine will detect things like duplicate images that are mirrored or rotated, I would hope it could detect duplicate images that, for example, have one as original color, and another identical geometrically but with a different compression type. And I would certainly expect that it could catch much more minor variations- just a small % change in contrast or brightness. And where it seems to catch some, there are instances where I have 3-4 variants of the same image which appear to a human as near identical that the system misses, where conventional dedup software like AllDup will find rapidly, and there, something like AllDup doesnt even have the advantage of starting with a known source- it is doing an all-to-all comparison, which is so CPU intensive that the idea of perhaps checking via multiple hash routines would not be feasible for a simple 'find similar' routine for a single photo...

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
(available in the Info Center app, or by running `kinfo` in a terminal window)
Linux/KDE Plasma: 
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
I understand that the position of the devs here may be that this is for true duplicate removal, where the photos are identical but have different names, or where one is raw and another is in a lossless compression conversion. But the reality is that any type of merge of legacy content may bring in stuff that is fundamentally identical to the eye. If the point of a similarity range is to permit variance in color or crop or contrast etc, it seems to not be nearly as effective as it should be. 

I wonder if it might make sense to use several hash types for the initial fingerprinting, where open source modules for pHash, dHash, aHash etc are out there, and where perhaps enabling a search area as full vs center (cropping would be less impactful) could then be user selectable? Since this is a one-to-many test vs a many-to-many test, it would remain quick for the user, but it would be much more capable (read: miss far fewer of what most of us would consider duplicate images).