Version: 1.0.0-beta5 (rev.: 1022091) (using 4.3.1 (KDE 4.3.1), Debian packages)
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.
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?
@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
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 . 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)
"Fast Multiresolution Image Querying"
by Charles E. Jacobs, Adam Finkelstein and David H. Salesin.
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:
*** Bug 187293 has been marked as a duplicate of this bug. ***
digiKam 7.0.0 stable release is now published:
We need a fresh feedback on this file using this version.