Incremental SfM pipeline that reconstructs 3D point clouds from images
Working SfM pipeline from scratch, but COLMAP already does this at production scale.
Open source Structure-from-Motion pipeline and More
Former maintainers revived abandoned OpenSfM with C++ rewrite and OpenCL GPU acceleration.
GIS professionals, photogrammetry engineers, drone mapping teams
COLMAP · Meshroom · OpenDroneMap
The original OpenSfM (github.com/mapillary/opensfm), the Structure-from-Motion engine behind OpenDroneMap and WebODM, is no longer maintained. As former maintainers, we couldn't let it go. So we went back to work, and improved it on many fronts : faster, more scalable (a long standing issue was speed) and capable of taking you from raw photos to finished GIS deliverables in a single pipeline.
We focused the v1.0 on aerial and GIS workflows :
- Much faster SfM (from Python to C++ SfM loop, GPU OpenCL matching) and support for very large scenes (randomised bundle adjuster). - More robust SfM in general. - A completely new dense pipeline, on GPU (OpenCL), with PatchMatch + TSDF-on-SVO + Refinement. Produces clean dense clouds quite fast, to LAS/LAZ/PLY exports. However, the mesh is crap (but it's in the works) - On the side of the dense, a new DSM & Orthophoto pipeline, again on GPU (OpenCL). GeoTIFF export (with correct CRS projection warps) - A revamped quality report : clear SfM metrics, GPS/GCP and checkpoint accuracy tables, and DSM/ortho previews. It can be now localized (metric/imperial, 5 languages) and also customised. PDF export.
Hopefully it'll be integrated in WebODM/ODX/ODM soon enough. I had a blast working on this these past two months, I hope the mapping/surveying community will enjoy it.
Ha, and it runs on Linux and macOS. Windows just needs some love (update the conda-locks).
Working SfM pipeline from scratch, but COLMAP already does this at production scale.
2x prefill speedup on 12k+ token contexts by treating GPUs like a production line.
GPU-accelerated pattern mining from protein research repurposed for poker hand analysis.
50x faster than PaddleOCR Python with real TensorRT benchmarks.
Direct2D GPU PDF renderer with CPU fallback, but alpha-stage and Windows-only.
This reads like a GPU engineer's field notes — one ~3,400-line CUDA file implements a full per-thread crypto pipeline (key gen → EC multiply → SHA-256 → RIPEMD-160) and a two-stage bloom+binary-search matcher to check ~3,100 targets at ~100M keys per batch. The article digs into concrete low-level choices (LUT layout, memory hierarchy, __ldg reads, atomicCAS reporting, and per-mode keygen strategies), which is rare in public writeups; downside is it's closed-source and the dual-use/ethical implications should be called out more explicitly.