OpenCV4: Should we support easier installation of xfeatures2d in Noetic?

Computer Vision / Perception
1

Hello ROS Perception!

Back in 2015, it was decided by the predecessor to this discussion group (ros-sig-perception) that we create an opencv3 rosdep key for the Indigo and Kinetic distros, since the default opencv at that time for those platforms was opencv2, and, to quote the ROS wiki for the opencv3 rosdep key, “the OpenCV2 version in Debian got rid of contribution modules and things like SIFT got lost.” Further motivating the need for a new custom debian build for the ROS community, it was explained then that “packaging opencv_contrib is difficult as it needs to be compiled with OpenCV sources.”

Today, in 2020 and looking at Noetic + OpenCV4.2, this state of affairs is once again true, and the ROS community does not have a simple rosdep key to rely on for accessing useful algorithms like SURF and SIFT as it did in Kinetic. OpenCV4.2 does not ship the xfeatures2d module directly, and requires you to re-compile opencv sources with the opencv_contrib repo in order to re-gain access to SURF, SIFT, and other highly useful algorithms to the ROS community.

I can see that this is a perennial issue for ROS users – I found a ROS Answers post with this same question but for Melodic, and there the questioner asks:

On ROS Melodic ros-melodic-opencv3 doesn’t exist anymore as e.g. on ROS Kinetic. Instead it is recommended to install libopencv-dev http://wiki.ros.org/melodic/Migration… , however, this package does not contain xfeatures2d, neither does libopencv-contrib-dev.

Unfortunately for them, the response was that from now on since Kinetic, we would have to manually re-compile opencv + opencv_contrib from source to reach parity with Kinetic-era 2D extra feature utilities in OpenCV.

So, for the ROS Computer Vision / Perception community: is there any interest in bringing easier access to the xfeatures2d OpenCV module to Noetic, as we once had for Kinetic? Does anyone know why we stopped the practice after the one time we made the opencv3 custom debian and rosdep key for essentially this purpose?

Thank you!

P.S. As of OpenCV4.4 and onwards, SIFT has been re-integrated into the main opencv codebase, since its patent has expired. But we would still have to create a custom debian distribution for OpenCV4.4+ even to get this benefit, so there may be work to do here either way!

2

From a ROS distribution standpoint, that rebuild of OpenCV 3 for Kinetic caused a lot of headaches. The problems that I remember are:

  1. The packages that depend on the package need to be explicitly updated to use the key. That is, it becomes difficult to have a single branch that supports e.g. Melodic and Noetic, since you need the opencv3 key on one, and the opencv key on the other. And you need to make sure to update it for every new release.
  2. The distribution ends up in a “split-brain” situation. That is, the underlying Ubuntu distribution (and tools) are built against one version of the libraries, and the ROS tools are built against another version of the libraries. So you run into weird ABI issues if you try to use any packages from the distribution that were built against the distribution library.
  3. There wasn’t really enough effort put into the maintainership. There were a lot of people who were interested in using it, but not a lot of people willing to do the grunt work to keep those packages up-to-date and working.

With that said, I know that there are some people who really need the latest OpenCV stuff on their robots. So I would be in favor of an optional, opt-in solution for those who really need it. I’m not entirely sure how that would look, but I want to try to avoid some of the problems associated with the Kinetic key.