Version: 0.10.0-beta6 (using 4.1.80 (KDE 4.1.80 (KDE 4.2 Beta1)), Gentoo) Compiler: x86_64-pc-linux-gnu-gcc OS: Linux (x86_64) release 2.6.26-tuxonice the search results are practically not usable and don't match remotly the sketch. E.g. painting a filled green circle returns images with no green in it, no circular geometry in the image and so on. The fuzzy search really needs some love until its usable.
Sketch often fails because fuzzy matching is done on very simple method (note: not programmer so I could misunderstood the code). There are taken pixels with brightest values of R, G and B, their relative position is calculated and that is fingerprint. Such "simple" method gives astonishingly good results with normal pictures but fails with sketches where you have large areas of the same colour. Note: astonishingly good doesn't mean perfect. I wonder if adding eg. darkest points would improve results without sacrificing too much performance.
Yes it seems to look only at one channel, this explains why you also get pure black & white images in the result although you painted a red blob in the sketch window.
i didn't do any research on this, just googled a bit, and it seems that the functionality of http://www.imgseek.net/ is very close to the one targeted here. imho it would be a waste of energy to implement a too simplistic solution for this complex topic as only a implementation which produces proper results in most cases will be actively used. Furthermore as digicam aims to be a professional solution, it should be true to its claim and present a state of the art proximity search for images, which of course would involve a lot of reading and nontrivial coding of this topic
#3 digiKam solution is ported from imgSeek AFAIK :)
The result is difficult to understand becaus ethe relevant of search result in percents is not displayed to iconview, as imgseek do. It's planed to add this feature later 0.10.0 when we port iconview to pure Qt4 Model/View Note the algorithm use to perform Fuzzy search is the same than imgseek (same code + port to C++ + speedup improvement + adaptation to digiKam database) Gilles Caulier
I will close this one as DUPLICATE. A newer report exists, talking about the same problem, but with a little bit more discussion going on... *** This bug has been marked as a duplicate of bug 207188 ***
Simon, The digiKam 8.2.0 pre-release for Windows is available for testing : https://files.kde.org/digikam/ Problem still reproducible on your computer ? Thanks in advance Gilles Caulier