https://bugs.kde.org/show_bug.cgi?id=416462
Mario Frank <mario.fr...@uni-potsdam.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mario.fr...@uni-potsdam.de
--- Comment #6 from Mario Frank <mario.fr...@uni-potsdam.de> ---
(In reply to Daniel from comment #5)
> (In reply to caulier.gilles from comment #4)
> Hi Gilles,
>
> a happy new year too :)
> > Can you check if problem remain with digiKam 7.5.0 pre-release bundle
>
> I just checked and the problem still persists.
>
> To be a more verbose:
>
> If a image A.jpeg is imported which has exif orientation set (for example
> Orientation : Rotate 90 CW), digikam will rotate it and adapt the file (and
> lets say save it to B.jpeg).
>
> If you search with the original image A.jpeg (not touched by digikam) in the
> fuzzy search, the imported image (B.jpeg) is not found. So I think the main
> issue is that the orientation flag isn't adhered to when searching using
> fuzzy search. (Supported by the fact that the orientation of the image
> preview in the fuzzy search box of A.jpeg is wrong (just horizontal))
Hi Daniel,
I am experiencing this flaw for a long time. Solving this is technically
difficult.
For every image, a HAAR fingerprint is calculated. This is comparable to a
heatmap concerning brightness. So every brightness point gets a coordinate
which is calculated on the "current" orientation of the image. If the image was
rotated in digiKam, the rotation flag is set. In this case, it could with some
effort
be possible to compute the heatmap "unoriented". But in some cases the
information
about rotation is missing as the image was imported in this orientation but
without
orientation info.
The HAAR concept is not orientation-agnostic. In order to support rotated
images,
every image would need at least 4 heatmaps (for rotation) and even much more
as the image cold have been mirrored. And even then, it would be necessary to
compare every heatmap of the one image with every respective one of the other
image for similarity. It is possible to implement this. But the similarity
search would
have an unacceptable performance - I already tried that.
So I conclude that I do not think that this issue can be solved with the
current similarity
comparison concept without grave effect on the performance - at least not with
combinatorial comparison. At least, I think this is a bigger project, e.g.
something
for GSoC. There are concepts that may be more appropriate (point distance
comparison
or even machine learning based) and the digiKam database and fuzzy/similarity
search
module in principle support using multiple comparison concepts since after
GSoC2017.
Perhaps Gilles has another idea.
Regards,
Mario
--
You are receiving this mail because:
You are watching all bug changes.
