Provide C++/CUDA sources or matching binary for como_backends

[ROUA27]

Hi ,
I’m trying to run CoMo on Python 3.10 + CUDA 12.4 (PyTorch 2.5.1) and hit linker errors in the precompiled como_backends extension:

ImportError: …como_backends.cpython-310-x86_64-linux-gnu.so: undefined symbol: _Z21get_new_chol_obs_infoN2at6TensorES0_S0_S0_S0_fi
It looks like the binary was built with a different PyTorch/CUDA combo. Would you be able to either:

1. Publish the como_backends.cpp (and any .cu) so we can recompile in our environment,
2. Or provide a prebuilt wheel/so matching Python 3.10 + CUDA 12.4?

Thanks a lot for your help,
Roua

[edexheim]

Hi,

The source files are included here https://github.com/edexheim/como/tree/main/como/backend. We do not provide the binaries directly. Can you check if the setup using the command from the readme source install.sh works without any errors? The last command in there should compile the files and would list any errors.

Best,
Eric

[ROUA27]

Hi Eric,

Thanks again for your help and for sharing the backend sources. I’m following up to share the workaround we implemented to successfully run CoMo in a GPU-enabled Docker environment — and to flag a few areas where we had to patch the source code to avoid runtime crashes.

---

Summary of our Docker/GPU Setup

We migrated CoMo into a Docker-based development environment with GPU support (Python 3.10, CUDA 12.4, PyTorch 2.2.1). We compiled como_backends from source using the repo you provided, which resolved the binary mismatch issues.

We also installed paraview and pvserver within the container for visualization, enabling remote reverse-connection rendering through pvserver, since the GUI window inside the container was non-interactive (just black output with no usable input).

---

Required Code Patches

1. DepthCovModule skipped entirely

We encountered the following error on startup:

ImportError: No module named 'pytorch_lightning_version'

As DepthCovModule wasn’t critical for our early testing phase, we bypassed its loading using a try/except block and a warning.

2. samplers.py crash: += on NoneType

During the greedy entropy sampling routine, we got:

TypeError: unsupported operand type(s) for +=: 'NoneType' and 'Tensor'

This occurred because signal_var or fixed_var were None, but still passed to operations like:

K_nn += torch.diag_embed(...)

We resolved this by adding conditionals and setting defaults: signal_var as torch.ones_like(cov_params_img), and fixed_var to small values — just enough to keep the entropy logic functional without crashing.

3. TwoFrameSfm.py missing attribute

Another blocking crash:

AttributeError: 'TwoFrameSfm' object has no attribute 'cov_params_img'

We added fallback initialization for this attribute to ensure it wouldn’t crash during the first frame’s handling.

---

These modifications were essential to get the pipeline working end-to-end, especially inside a clean Docker environment where nothing is preloaded or cached.

---

Final Note

We're currently working on extracting the 3D map and camera trajectories from the CoMo pipeline to visualize them locally (outside the container) and to benchmark the outputs against other GIT projects, as part of a Master’s thesis project.

Since CoMo wasn’t originally intended to run in containerized setups, we ran into several GUI limitations — in particular, the emulated Linux desktop window was non-responsive, making interaction impossible. To work around this, we used ParaView via pvserver for remote visualization, and are now focusing on generating output files (.ply, .vtk, trajectory logs, etc.) to enable analysis beyond the default viewer.

Would you consider adding support for a headless or non-GUI mode that saves these outputs directly? It would really help for reproducible experiments and Docker-based pipelines.

Thanks again for making CoMo open and available.

Best regards,
Roua