https://bugs.kde.org/show_bug.cgi?id=416462
--- Comment #8 from Daniel <daniel-other+kde...@dadosch.de> --- Hi all, so I think they are 2 different cases here (both could theoretically be solved by the same solution, but probably shouldn't), and I don't think the solution (at least for similar pictures, as written at the end) needs to be complicated (maybe I'm naive). A) The image is already correctly oriented before importing, using a set exif orientation flag. If the image is imported (and autorotate is enabled), this flag gets removed and the images is fully rotated (that's my understanding). The solution to this would be to read the orientation flag when doing the fuzzy search. Before running the hash algorith on it, the pictures need to be rotated according the flag. This should be almost trivial. B) The image is rotated after it has been imported, different to the original orientation. The solution to this could be to search the hashes for all 4 (let's ignore mirrors for now) orientations of the search query picture. I don't think this would be difficult or slow (as to my experience the search algorithm is very fast/instant). This could be extended to only search for additional orientations, if no result is found. If it is technically not possible, maybe someone can explain to me why :) Ok, this would have one major drawback: It could only find similar pictures, not duplicate entries. But if you assume all images are correctly rotated in the digikam collection, finding duplicates wouldn't be a problem anymore… Daniel -- You are receiving this mail because: You are watching all bug changes.
