-
Notifications
You must be signed in to change notification settings - Fork 544
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is there a Python binding to libpointmatcher #222
Comments
Clearly not, but I would highly appreciate it ;) |
We starting to work on Python binding. If someone has some inputs, advices or needs. Now is the time to tell us! |
There was the start of an implementation of python bindings. It supported registration, add numpy array as pointcloud input and support extracting the debugging information that are normally in the .vtk output. However, it needs to be clean up, there is a bunch of code that was made specifically for debugging penalized ICP. https://github.com/norlab-ulaval/test_penalized_icp |
@PhiBabin How did you attempt the Python binding in your branch? @pomerlef Two questions:
I previously worked on making the Python bindings of Kalibr build and ship as released software (Debians). They included marshalling for eigen/numpy datatypes, wrappers around classes and function calling directly from Python. Making them work, after managing all the build targets was straightforward. This is a list of solutions taken by different libraries:
Things to take into account:
|
@YoshuaNava Thanks for the informations! I'll take a look at them! 🙂 @PhiBabin I don't have access to the repo you've mentionned. 🙁 |
@YoshuaNava I used boost.python. I only supported the most basic usecase of registering two pointclouds. Only a small subset of the api was implemented. |
Alright! So, after researching about all the Python bindings tools available, here are the ones I consider to have good potential to do the job. These solutions have been selected base on the following criteria : Primary criteria:
Secondary criteria:
The fully automatic solutions :
And the semi-automatic solutions :
List of projects and examples using these tools :
Some more stuff on the subject :
In short...Well, all of the above tools have their strenghs and weaknesses, none of them are perfect. But, I think it's worth trying the fully automatic solutions first, since they are designed with the ease of use and maintenance in mind. On the other hand, AutoWIG generate Pybind11 or Boost.Python bindings, both of whom have extensive of tutorials, documentations and examples available. So, in the event AutoWIG is harder to grasp than Pybind11 or Boost.Python, then I can go with either of these tools. All of these tools are focused on performance, so I'm not worried about that too much. The main struggle being the Python call overhead, except for the PyPy interpreter. cppyy, Pybind11 and Cython are compatible with the PyPy interpreter, although cppy seems to get a bit more out of it than the other ones. FinallyEvery suggestions, comments or advices are welcome. Feel free to suggest anything that could make this project even better, the goal is to be able to provide good bindings for libpointmatcher. Thanks! |
Thanks for the thorough analysis. I guess we can start with AutoWIG. @simonpierredeschenes any concerns? |
Just adding a couple of remarks; feel free to ignore. :) Full disclosure: I'm the author of cppyy, and saw some of my documents referenced above, which is how I landed here. First: "all of the above tools have their strenghs and weaknesses". This is an extremely important point as you have "Performance" on the top of your list. Performance in CPython (and PyPy even more so), from an automatic binder, depends on specializing the paths that you care about. If that is already happening out-of-the-box, then you're golden. If not, you're in for some work. I'm afraid that testing and profiling is the only way to find out. On that point, yes, automatic binders do help a lot with maintenance, but even though they get you 99% of the way, that last bit that they lack is also the hardest part. I.e. compared to a full manual solution, that 1% would be more like 20-30% of the manual effort. Still a gain for sure, but you may be forced to learn more about the tool than you hoped for. For Eigen/NumPy: note that Eigen's layout may differ depending on compiler settings (e.g. if you enable vector instructions), so simply copies may be the only portable way in some cases. As for cppyy, one problem with Eigen is that template expressions are intended to be squashed by the C++ compiler. This does not naturally happen in cppyy in the way that wrappers are generated, so sometimes you end up with massive expressions escaping to Python. I'm working on Eigen-specific module, but this is a WIP. Finally, for PyPy, cppyy there has less functionality than on CPython. It will trivially outperform the other solutions, but it does so because there is builtin support for cppyy in PyPy. The others have to go through the emulated C-API which can be very slow. This builtin cppyy module is being separately maintained and because of the higher demand for CPython support, effort has mainly been going to CPython, so cppyy in PyPy is now lagging. |
Thanks a lot @wlav ! Your inputs are much appreciated. We will continue our analysis, but I guess we need to do some quick tests with those tools to understand a bit more what is going on. |
Yes! Thank you very much @wlav! Your feedback is very much appreciated! |
[WIP] feature/python_module : Adding libpointmatcher's Python bindings (#222)
…fic-gcc-install-requirement--nmo-585 dev-build-add-bionic-specific-gcc-install-requirement--nmo-585 Note: Build [#222](http://132.203.26.125:8111/buildConfiguration/LibpointmatcherBuildSystem_BuildAndTestMultiArchCiBuildAndTestDockerImages/8608?hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandPull+Request+Details=true&expandBuildChangesSection=true&expandBuildDeploymentsSection=false) has passed. The failed build msg was sent by the subsequent build triggered by a doc update commit.
I was wondering if there is a Python binding to libpointmatcher?
The text was updated successfully, but these errors were encountered: