Version: 1.0.0-beta5 (rev.: 1022091) (using 4.3.1 (KDE 4.3.1), Debian packages) Compiler: cc OS: Linux (i686) release 2.6.31-rc8-sidux-686 When I fill the Fuzzy Search Sketch with green colour, I get about 50 pictures showing a blue sky with light clouds. No green at all. Hmmm ... Or when taking a fully saturated orange, the first image is this one: http://de.wikipedia.org/wiki/Datei:Frost_on_birch.jpg Imho that's not the expected behaviour.
Fuzzy search is looking for brightest points of R, G, B and their patterns. If you check carefully your images you will find that those images are similar in that terms.
But still it is wrong :) When I want to search red images, I want to find red images, not green, blue, yellow or black ones. I'm not sure if current duplicates algorithm is capable of being that precise though. Find similar works fine because all channels are involved, but fuzzy search is behaving wrong in this case. Maybe we just need to adjust the fuzzy search instead of re-thinking the whole duplicates algorithm?
http://granjow.net/uploads/bt/digikam-fuzzy-4.jpg http://granjow.net/uploads/bt/digikam-fuzzy-3.jpg http://granjow.net/uploads/bt/digikam-fuzzy-2.jpg http://granjow.net/uploads/bt/digikam-fuzzy-1.jpg @Mikolaj If I check carefully I see that I'm rarely finding what I'm actually searching for. What I remember is colour and shape, but only roughly. I don't care what the brightest point is, as my eye sees colours but not RGB values; I don't even know which they are.
On Sunday 13 September 2009 11:20:50 Simon wrote: > @Mikolaj If I check carefully I see that I'm rarely finding what I'm > actually searching for. Unfortunately in all your examples this is what algorithm finds, it is really confused by pure colors and grays (4), apart from 3rd image in first line everything is OK (3), similar in (2), (1) is more complicated but also fits algorithm mechanism. I wonder if it could be helped not by total rethinking of fuzzy logic but "simply" by adding to fingerprint data about darkest point of image. It should reduce number of really strange hits. Note that this is very similar approach practically it would require almost total rewrite of haar.cpp...
Literatur is available [1]. We have faithfully implemented the algorithm outlined there, only adapted to our storage situation. Remember that for fingerprint generation, the image is transformed to YIQ colorspace and wavelet transformed. Then the coordinates of the 40 largest wavelet coefficients are taken. So unless your mind is accustomed to thinking in frequency domain for images (mine is not) this is _not_ intuitive. For the question here, note that the YIQ color space conversion may be the main cause. Suggestions for superior algorithms are welcome (literature, GPL reference implementation, no patent problems, comparable speed and storage impact) [1]"Fast Multiresolution Image Querying" by Charles E. Jacobs, Adam Finkelstein and David H. Salesin. http://www.cs.washington.edu/homes/salesin/abstracts.html
What about using the esame algorithm again, but with RGB, without color space conversion?
*** Bug 175905 has been marked as a duplicate of this bug. ***
My personal conclusion is that the results of sketch searches are not ever useful. I really don't know much about the subject matter. A quick google returned this discussion: http://stackoverflow.com/questions/843972/image-comparison-fast-algorithm
*** Bug 187293 has been marked as a duplicate of this bug. ***
digiKam 7.0.0 stable release is now published: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Best Regards Gilles Caulier
Maik, about this entry, the fuzzy search gives the best results as it can. It's not perfect but not too bad at all. For me the colors shape searches give at least suitable items, even if few items do not correspond matches the query. Gilles
Maik, Do you seen my previous comment ? Gilles
I don't use this feature often, agree to your Comment 11. I find the results that found but often surprisingly good. There were relatively many comments here who would like a better result, we could make a note of it as a GSOC project. Maik
*** Bug 452878 has been marked as a duplicate of this bug. ***