Configure FeatureDetector.ORB using Java OpenCV 3.3.0

edit

That is, indeed, sad. I might take a look at the source and see if I can contribute a patch. Since I would like to increate nFeatures, I am pondering the following workaround: "gridding" my image by running featureDetector.detect(image, keypoints) and descriptorExtractor.compute(image, keypoints, descriptors) in each quadrant independently, then post-process the resulting "keypoints" and "descriptors" (for example, in the keypoints, adjust keypoint.pt.x and keypoint.pt.y to be translated from the quadrant coordinates to the full image coordinates; not sure if anything needs to be adjusted in the descriptors) combining all keypoints into a single MatOfKeyPoint and descriptors into a single Mat before calling matcher.knnMatch(descriptors1, descriptors2, knnMatches, 2); Would this work?

if you want my 2 ct here: the whole features2d thing in java is still based on the opencv2.4 approach, where it needed manual wrapping cv::Ptr, it seriously needs a general overhaul. (already the division into featureDetector and descriptorExtractor classes is artificial(only in the java legacy), it's the same thing in c++, and you would rather use detectAndCompute(), for not wasting computation effort)

Thank you for the rapid responses. I am pretty green when it comes to OpenCV, so it is taking me a bit to parse your last reply... I gather that there is a desperate need for an overhaul in the implementation as it pertains to this issue; however, I can't tell if your comment regarding "detectAndCompute()" is directed at the efforts for the general overhaul, or if you are suggesting that I could somehow utilize "detectAndCompute()" from Java today to better solve my issue. If it wasn't clear, my immediate issue is that I have some images with "features" that I am interested in, but since the image has so many high frequency components and nFeatures is fixed at 500, I am not getting any features (keypoints/descriptors) in some regions of the image that I am interested in.

aw, sorry, that was more a rant from a c++ perspective, not at all a constructive approach at your current problem ;(

what about using like AKAZE instead of ORB ? should give far more keypoints with the default settings (yea, you pay for that with computation time..)

I choose ORB at the time because it appeared to be a good/"free" alternative to SIFT...I need an algorithm that is somewhat scale invariant, and for the most part ORB is doing quite well. I will read up on AKAZE -- I don't imagine that it would take a lot to make the change from ORB to AKAZE in my code (however, the project is pretty far down a path to be making such a fundamental change at this point...but...if it is the right thing to do). Perhaps some prototyping is in order. Thanks again for your thoughtful responses.