Hi, I'm I am dig in the problem of feature matching.
I conducted the following experiments on MegaDepth-1500 dataset: First I exact some keypoints in image A, and then I warpped them into the paired image B with the groundtruth T and depth map of A. Then I used OpenCV to solve for the pose and calculate the pose error using the relative_pose_error. Some thing strange occurred. For about 98% pairs the pose error is zero, but several cases have a R_err=180. I find that in the relative_pose_error func, the ambiguity of t_err is eliminated by t_err = torch.minimum(t_err, 180 - t_err), however, R_err did not undergo the same operation. Combining my experimental results, I wonder if this could be a bug? (Although I have looked through many related repositories, no one seems to be doing it this way.)
By the way, While testing lightglue, I found that the RANSAC threshold and different RANSAC methods have a significant impact on the results, and they cannot effectively reflect the quality of the match. From the matching results to the AUC, it involves essential matrix computation based on RANSAC, followed by pose recovery. There are too many uncontrollable factors in the process. Is there another indicator that can more directly reflect the quality of matching? Or to put it another way, why use such a indirect method to evaluate the effectiveness of feature matching methods?
Looking forward to your reply!
cc @sarlinpe @Phil26AT
guker
commented
8 months ago
Hi, I'm I am dig in the problem of feature matching.
I conducted the following experiments on MegaDepth-1500 dataset: First I exact some keypoints in image A, and then I warpped them into the paired image B with the groundtruth T and depth map of A. Then I used OpenCV to solve for the pose and calculate the pose error using the relative_pose_error. Some thing strange occurred. For about 98% pairs the pose error is zero, but several cases have a R_err=180. I find that in the
relative_pose_errorfunc, the ambiguity of t_err is eliminated byt_err = torch.minimum(t_err, 180 - t_err), however,R_errdid not undergo the same operation. Combining my experimental results, I wonder if this could be a bug? (Although I have looked through many related repositories, no one seems to be doing it this way.)By the way, While testing lightglue, I found that the RANSAC threshold and different RANSAC methods have a significant impact on the results, and they cannot effectively reflect the quality of the match. From the matching results to the AUC, it involves essential matrix computation based on RANSAC, followed by pose recovery. There are too many uncontrollable factors in the process. Is there another indicator that can more directly reflect the quality of matching? Or to put it another way, why use such a indirect method to evaluate the effectiveness of feature matching methods?
Looking forward to your reply! cc @sarlinpe @Phil26AT