I am presently stretching a picture library accustomed to classify images and i wish to find duplicate images, changed images, and pictures which contain or are found in other images.
I've examined the SIFT implementation from OpenCV and delay pills work perfectly but could be rather slow for multiple images. Too speed up I figured I possibly could extract the characteristics and save these questions database as many other image related meta information is already being held there.
What will be the quickest method to compare the characteristics of the new images towards the features within the database?
Usually comparison is performed calculating the euclidean distance using kd-trees, FLANN, or using the Pyramid Match Kernel which i present in another thread here on SO, but haven't looked much into yet.
Since I'm not sure of a method to save and check a kd-tree inside a database effectively, I am presently only seeing three options:
* Let MySQL calculate the euclidean distance to each feature within the database, although I am certain which will take an uncommon time for over a couple of images.
* Load the whole dataset into memory at the start and make the kd-tree(s). This could most likely be fast, but very memory intensive. Plus all of the data will have to be moved in the database.
* Saving the produced trees in to the database and loading these, will be the quickest method but additionally generate high levels of traffic just like new images the kd-trees would need to be reconstructed and send towards the server.
I am while using SIFT implementation of OpenCV, but I am not dead set onto it. If there's an element extractor more appropriate with this task (and roughly equally robust) I am glad if a person could suggest one.
And So I essentially did something much like mtss is a couple of years back. The formula you need to consider was suggested a couple of years back by David Nister, the paper is: "Scalable Recognition having a Vocabulary Tree". They virtually come with an exact means to fix your condition that may scale to countless images.
This is a connect to the abstract, you'll find a download link by googleing the title. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1641018
The fundamental idea would be to develop a tree having a hierarchical k-means formula to model the characteristics after which leverage the sparse distribution of features for the reason that tree to rapidly find your nearest neighbors... or something like that like this, it has been a couple of years since i have done it. You'll find a ms powerpoint presentation around the authors web page here: http://www.vis.uky.edu/~dnister/Guides/guides.html
A couple of other notes:
I wouldn't make use of the pyramid match kernel, it is more for enhancing object recognition than duplicate/changed image recognition.
I'd not store some of this feature stuff within an SQL database. Based on the application it's sometimes more efficient to compute your physical features quickly since their size can exceed the initial image size when calculated densely. Histograms of features or pointers to nodes inside a vocabulary tree tend to be more effective.
SQL databases are not shipped for doing massive floating point vector information. You are able to store things inside your database, try not to utilize it like a tool for computation. I attempted this once with SQLite also it ended very badly.
If you choose to implement this, browse the paper at length and a duplicate handy while applying it, as you will find many minor particulars that are important to creating the formula work effectively.
The important thing, I believe, is that's this is not a SIFT question. It's a question about approximate nearest neighbor search. Like image matching that as well is definitely an open research problem. You can test searching "approximate nearest neighbor search" and find out which kind of techniques can be found. If you want exact results, try: "exact nearest neighbor search".
The performace of these geometric data structures (for example kd-trees) degrade as the amount of dimensions increase, therefore the key I believe is the fact that you may want to represent your SIFT descriptors inside a lower quantity of dimensions (say 10-30 rather than 256-1024) to possess really efficient nearest neighbor searches (use PCA for instance).
After you have this It will end up secondary when the information is saved in MySQL or otherwise.