This forum is disabled, please visit https://forum.opencv.org
 | 1 | initial version |
Personally, I am using BRISK and have no problem. Still, there is a threshold parameter that influence the number of keypoint retrieved. If you really want a specific number of keypoint, you must iterate this threshold until you detect the required number of keypoint. I think I have read this in the BRISK paper, but I am not sure and can't access it right now...
This said, I think that you should consider a different approach. Since you don't really specify why you want to limit the number of keypoint, I assume that it is because you are getting too much keypoint of low interest (if I am wrong, then it will be of use for someone else I assume).
First, you could simply filter the detected keypoints by keeping say 80% of the keypoints with the highest intensity. But this is arbitrary and you don't know if 80% will get you the correct keypoints. You better wait until you match to keep only the best matches.
The idea that when you match the keypoints between two images, you have to filter the matches to eliminate the ones that are seemingly superfluous. There are a number of ways to do it, and one is to use the ratio test proposed by [Lowe].(http://answers.opencv.org/question/19163/ratio-check-function-with-findhomography/?answer=19165#post-id-19165)
Then, you will have less keypoint/matches to work with. The shortcoming is that you still need to compute more keypoints to be able to reject them instead of never computing them in the first place. But when you think about it (if you have read the BRISK paper or similar binary keypoint descriptor), it seems impossible to know beforehand which keypoints are going to be the best if you don't compare them between themselves.
