https://bugs.kde.org/show_bug.cgi?id=416462
--- Comment #10 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to Daniel from comment #8) > 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 Hi Daniel, first of all, the similarity search is only quite fast since the fingerprints are computed before searching and excessive caching is used. The computation of the fingerprints is quite slow. Especially for users with >100k images which is not much. We should never forget that. But I think you have a point. The orientation flag could help. I see two possible ways: 1) For every image, two fingerprints are generated - one with current orientation and one with original orientation. And the user can select for the search whether he wants to search by original or current orientation. This has drawbacks, although in most cases not grave ones. First, in many cases, both fingerprints of the image will be identical which is a waste of memory (but this could be optimised). And second, the database scheme needs to be adopted (not really a problem). And not to forget, the fingerprint generation will be slower - it is hard to estimate how much, since the degree of rotated images differs from user to user. But the user can decide depending on the situation, which is good. This could be a solution. 2) The user decides in the fingerprint generation configuration whether fingerprints shall be generated for the current orientation or the original one. In this case, there is no additional memory consumption and rotated images should be recognised as similars. One drawback is that if the user changes the configuration, the fingerprints partially need to be regenerated. But this drawback can be reduced. Here, we also have a possible solution. If the fingerprint entry in the DB gets an additional orientation flag, we can compare the orientation flag with the current configuration when refreshing fingerprints. So only the fingerprints of the changed and rotated images would be updated. But I must admit that I do not know what information the orientation flag provides. Does it state whether or not the image was rotated or does it give the angle (90/19/270°)? Regards, Mario -- You are receiving this mail because: You are watching all bug changes.
