Feature matching initialization appears to match incorrect region

[J-C-Haley]

Hello and thank you again! I have a few questions about how the feature matching initialization works. I'm getting good results on some objects, but on others it appears to be searching the wrong ROI for matches when I go into the .dice folder and find the produced 'fm_initializer_0.png'. Looking at the 'fm_space_filling.png' images, it seems to find matches all over the place, unconstrained by epipolar projection.

So, what I'd like to know is:

• Does the FM attempt to match in a particular ROI in the right image, or does it search globally and then make the 'fm_initializer_0.png' wherever it matches the ROI best?
• Are there any parameters in the feature matching that could be adjusted to get better correspondence? All I see is a tolerance.
• It looks like the akaze method doesn't consider epipolar projection error. As an alternative, I can get good disparity maps from the StereoBM cv algorithm, maybe it would be a good alternative initializer?

[dicengine]

I'm pretty sure that the initializer doesn't restrict the matches to the ROI since the location of the ROI in the right image is not known.

There are several parameters that can be adjusted, but only a few are exposed through actual DICe options. You would have to change the actual code and recompile if you want to explore other options.

My favorite is SURF, which is available in the most recent version of DICe. It does much better than AKAZE in most cases.

[J-C-Haley]

Ok great! Looking forward to the next release then. After artificially blacking out the background, the akaze initializer did work.

So, maybe we can make this into a Feature Request - I'd still love to see an initializer that penalized matches with high epipolar projection error. I could see this being a seperate class with the opencv stereoBM/stereoSGBM (which do unfortunately take some tuning to get working), or perhaps calculating the distance off the epipolar line through the optical centers and adding it as a K dimension in the KDtree lookup. I'll probably try out the SURF first and see how much this is needed.