knnMatch/BFHamming bug or not?
I tried to test various OpenCV keypoint matching methods to find image shift and rotation between two not exactly same images (slices of 3D dataset that may not be perfectly aligned). I found this problem: when two images have the same number of keypoints, matches2points_nndr function copied from https://github.com/thorikawa/akaze-op... does not reduce number of matches and estimateAffinePartial2D returns very low number of inliers and sometimes fails. This problem happens all the time with ORB detector with limited number of keypoints and it happens with other detectors/descriptors randomly, because number of keypoints usually differ.
I also tried to use match instead of knnMatch with some sorting for ORB with no success.
Am I doing something wrong? I can't believe that ORB method usually fails (unless target number of keypoint is set very high and never reached) and no one reported bug to OpenCV. And AKAZE fails using parts of it's example code.
My code including test images is here: https://github.com/pavel-perina/cv-bug
Output looks like this (tested in OpenCV 3.3.0 and 4.4.0):
ALGORITHM="ORB2500"
Image=25; keypoints=2500vs2500; matches=2500; inliers=41 (1.64%)
Image=26; keypoints=2500vs2500; matches=2500; inliers=28 (1.12%)
Image=27; keypoints=2500vs2500; matches=2500; inliers=38 (1.52%)
ALGORITHM="AKAZE"
Image=25; keypoints=1670vs1673; matches=1224; inliers=1217 (99.4281%)
Image=26; keypoints=1673vs1673; matches=1673; inliers=69 (4.12433%)
Image=27; keypoints=1673vs1688; matches=1189; inliers=1176 (98.9066%)
AKAZE has very low number of inliers between slices 25&26.