Signal Processing Stack Exchange is a question and answer site for practitioners of the art and science of signal, image and video processing. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've developed a large test-system which can use every interest-point-detector and -descriptor. I use it for evaluation of the given algorithms with the standford-image-collection of cd-covers. This post will not go any deeper with any source-code. I only found out that switching to images (no referred as firstImg and secondImg) will create to different results. The Ransac-Threshold is used to compute the homography and epsilon is the reprojection-error. For this example I use the Scale-Invariant-Feature-Transform by David Lowe.

First test with the secondImg as the queue-image creates the following results I've written down:

  • Inliner: "1672"
  • Number_of_Keypoints_FST: "368"
  • Number_of_Keypoints_SND: "1749"
  • Outlier: "77"
  • Ransac: "65"
  • Epsilon: "10"

Here is the saved image.

Now I'm switching the order. The firstImg is the queue.

  • Inliner: "310"
  • Number_of_Keypoints_FST: "1749"
  • Number_of_Keypoints_SND: "368"
  • Outlier: "58"
  • Ransac: "65"
  • Epsilon: "10"

Here is the second result.

Questions: I'm confused that switching the order of the images affects the results. Should the matched keypoints be identical for the matched ones when switching the order of the images? Should the inliner be identical?

share|improve this question
This seems rather like a programming flaw. The matching is basically a high-dimensional nearest-neighbor search, so if you have two sets with very different size, their size difference can play a role in matching if an approximate search algorithm is used (matching to large dataset is less accurate). However, it seems like a rather simpler programming flaw in this case. – Libor Feb 16 '13 at 10:28
This means: The two results should be identical? What about the influence of the perspective transformation of the cd-cover on the table? I'm using a exhausting bruteforce-matcher. So only the exact nearest neighbour is returned. – Mr.Mountain Feb 16 '13 at 10:51
In case of exact NN matching, the results should be indeed the same (unless you have multiple same vectors in one image, or zero vectors or multiple vectors of exactly the same distance from the query vector). The lines in second image look like there is a bug in software. – Libor Feb 16 '13 at 13:27
Yes, I think you're right. But I can't find it. I will post, if I got a hint. – Mr.Mountain Feb 16 '13 at 15:06
up vote 0 down vote accepted

ARGH. I feel ashamed. How about a cross validation? That's the solution. Now there are almost exact matches ... almost. =) Thank you, Libor. The second comment gave me a hint. =)

share|improve this answer
You should accept your own answer in that case. – Andrey Rubshtein Feb 17 '13 at 11:21

Lets say 1st image has 100 keypoints and the 2nd image has 500 keypoints.
For NN search every point in the 1st image finds nearest one among the 500 points But when we reverse image order, each keypoint of 2nd image searches for the nearest one among 100 keypoints.

So basically the search space changes and hence the results.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.