2
$\begingroup$

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?

| improve this question | |
$\endgroup$
  • $\begingroup$ 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. $\endgroup$ – Libor Feb 16 '13 at 10:28
  • $\begingroup$ 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. $\endgroup$ – Mr.Mountain Feb 16 '13 at 10:51
  • $\begingroup$ 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. $\endgroup$ – Libor Feb 16 '13 at 13:27
  • $\begingroup$ Yes, I think you're right. But I can't find it. I will post, if I got a hint. $\endgroup$ – Mr.Mountain Feb 16 '13 at 15:06
0
$\begingroup$

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. =)

| improve this answer | |
$\endgroup$
0
$\begingroup$

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.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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