openMVG: a C++ multiple view geometry library for building your own Structure from Motion pipeline
open Multiple View Geometry library. Basis for 3D computer vision and Structure from Motion.
At a glance
- What is it?
- openMVG is an MPL-2.0 C++ library and set of binaries for multiple view geometry and Structure from Motion, with a Docker build path documented in BUILD.md. It is a framework for people who want to read, modify and chain the reconstruction steps, not a one-click photogrammetry app.
- Who is it for?
- Adopt openMVG if you need a readable C++ implementation of feature matching, tracking, camera models and Structure from Motion that you can modify, and you are willing to build it from source and study the Wiki tutorials. Do not adopt it if you want a single command that turns photos into a textured mesh, or if you cannot maintain a C++ toolchain.
- Can I use it commercially?
- Yes, with conditions. MPL-2.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 18 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What openMVG actually solves, and for whom
openMVG is not a photogrammetry product. It is a C++ framework whose stated mission is to extend awareness of 3D reconstruction from images by providing libraries, binaries and pipelines. The README describes three layers: libraries for image manipulation, feature description and matching, feature tracking, camera models, multiple view geometry, estimation methods for noisy data and Structure from Motion algorithms; binaries that solve unit tasks such as scene initialization, feature detection and matching, and SfM reconstruction; and pipelines assembled by chaining those binaries.
The intended user is an engineer or researcher who needs to understand or change the reconstruction steps. The README's credo is "Keep it simple, keep it maintainable", and it says the library is designed to be easy to read, learn, modify and use, with test-driven development and samples intended to support larger systems. That is a different audience from someone who wants to upload a folder of drone images and receive a mesh.
If your problem is that existing SfM code is opaque, or that you need a specific camera model, a specific estimator for noisy matches, or a specific matching strategy inside a pipeline you control, openMVG is aimed at you. If your problem is that you have images and want a result by Friday, the README points you elsewhere in its own pipeline description: it exports reconstructed scenes to other Multiple-View-Stereovision frameworks for dense point clouds and textured meshes.
The library, binary and pipeline split
The architecture is explicit in the README. Libraries provide the algorithms. Binaries solve unit tasks: scene initialization, feature detection and matching, and Structure from Motion reconstruction. Pipelines are created by chaining binaries to compute image matching relations, solve the SfM problem (reconstruction, triangulation, localization) and export the scene.
This means the unit of work is a file-based handoff. A binary consumes an SfM data directory, writes matches or a reconstruction, and the next binary reads it. The README links a Wiki page on OpenMVG data structures, which is where the directory layout and the JSON or BIN formats are described. That is the contract you build against.
The names of the published papers behind the components tell you what is inside: AContrario Ransac, AContrario SfM, GlobalSfM and Tracks. The README asks that you cite the whole library with the 2016 paper, or the specific paper if you use only a submodule. That citation list is also the clearest statement of which algorithms are considered stable enough to name.
One consequence is worth stating plainly: because pipelines are chains of executables over files, debugging means inspecting intermediate artefacts. There is no single in-process API that hides the stages, and the README does not present one.
Installing openMVG with the Dockerfile
The repository ships a Dockerfile that builds openMVG on Ubuntu 22.04. The README links BUILD.md for both local and Docker build tutorials. The Dockerfile installs the dependency set with apt, including cmake, build-essential, coinor-libclp-dev, libceres-dev, libjpeg-dev, liblemon-dev, libpng-dev, libtiff-dev and python3, then clones the repository into /opt/openMVG and initializes submodules.
The build step configures CMake in RELEASE mode with an install prefix of /opt/openMVG_Build/install, enables tests, disables examples, and points the COINUTILS, LEMON, CLP and OSI include hints at /usr/include. That is the configuration the project itself uses in CI-adjacent builds, so it is the safest starting point:
cmake -DCMAKE_BUILD_TYPE=RELEASE \
-DCMAKE_INSTALL_PREFIX="/opt/openMVG_Build/install" \
-DOpenMVG_BUILD_TESTS=ON \
-DOpenMVG_BUILD_EXAMPLES=OFF \
-DCOINUTILS_INCLUDE_DIR_HINTS=/usr/include \
-DLEMON_INCLUDE_DIR_HINTS=/usr/include/lemon \
-DCLP_INCLUDE_DIR_HINTS=/usr/include \
-DOSI_INCLUDE_DIR_HINTS=/usr/include \
../openMVG/srcAfter that, the Dockerfile runs make -j 4, then make test, then make install. The image adds /opt/openMVG_Build/install/bin to PATH, so the binaries are callable by name once the container is running. Note the layout detail: CMake is pointed at ../openMVG/src, not at the repository root. Getting that path wrong is the most common way a first build fails.
For a local build, the same CMake variables apply; BUILD.md is the file the README directs you to, and it also covers using openMVG as a third-party CMake dependency. There is a pixi.toml and pixi.lock at the repository root, which indicates a Pixi-based environment is also maintained, though the README does not describe it.
For a first real use, the README points to a Wiki page titled "Using OpenMVG on your image dataset". That page, not the README, is where the concrete sequence of binaries over your own images is written down. Start there rather than guessing the order from binary names.
Where openMVG is the wrong tool
The README is candid about the boundary. Dense point clouds and textured meshes are produced by exporting the reconstructed scene to other Multiple-View-Stereovision frameworks. openMVG itself is the sparse reconstruction and geometry layer. If your deliverable is a dense mesh, you are using half of a pipeline and you need the other half from somewhere else.
The second limitation is the build and integration cost. This is a C++ project with Ceres, Lemon, CLP, OSI and CoinUtils in its dependency list, and a submodule checkout before the build. The README's own Dockerfile exists precisely because assembling that dependency set by hand is tedious. Cross-compiling to Android or iOS, which the README lists as supported platforms, is a further step that the README does not walk through.
The third is version cadence. The most recent tagged release listed is v2.1, dated 2023-12-28; v2.0 is from 2021-10-20 and v1.6 from 2020-05-13. The default branch is develop, and the last push to the repository was on 2026-08-30. So the code moves on develop while the tags are years apart. If you pin a release, you are pinning a 2023 state of the code; if you follow develop, you accept that the README's build instructions may describe a tree that is ahead of the last tag. The README does not document a support policy for either choice, and it does not document rollback or migration between versions.
Finally, if your team has no C++ build capability, a Python-first reconstruction tool will cost you less to operate. openMVG is a library you compile, not a service you call.
openMVG compared with COLMAP
The comparison people search for is openMVG versus COLMAP, and the difference is structural rather than a matter of accuracy claims, which this article does not make for either project.
openMVG's stated design goal is readability and modifiability. The README's credo is "Keep it simple, keep it maintainable", and the project describes itself as easy to read, learn, modify and use, with strict test-driven development and samples as the basis for larger systems. The output of an openMVG run is a sparse reconstruction that the README expects you to hand to a separate Multiple-View-Stereovision framework. Binaries and pipelines are the interface.
COLMAP is not described in the repository's README, so the honest statement of difference is limited to what openMVG documents about itself: it is a C++ framework of libraries and chained binaries with an explicit export step for dense reconstruction, and it publishes the algorithms behind its components as named papers (AContrario Ransac, AContrario SfM, GlobalSfM, Tracks). If you want to change how matching or estimation works, that paper-backed, modular structure is the reason to pick openMVG. If you want one tool that owns the path from images to a dense result, the export boundary in openMVG's own description is a reason to look at a project that does not have it.
Incremental SfM versus global SfM is a real axis here: the README names GlobalSfM as one of the citable components, which means both global and incremental approaches exist in the codebase as distinct pieces you can choose between.
Licence and maintenance cost
openMVG is licensed under MPL-2.0, as stated in the README badge and the LICENSE file at the repository root. The MPL is a file-level copyleft licence: modifications to files covered by it carry obligations, while the wider MPL text governs the details. This article is not legal advice; read the LICENSE file and, if you ship a product, have counsel read it too. The practical point for adopters is that MPL-2.0 is not a permissive licence in the MIT sense, so the compliance question is worth answering before the library is embedded in a shipped binary.
The repository also ships COPYRIGHT.md and AUTHORS, which is where attribution material lives.
Maintenance cost has two parts. The first is dependency drift: the Dockerfile pins Ubuntu 22.04 and installs Ceres, Lemon, CLP, OSI and CoinUtils from apt, so a base-image change can break the build even if openMVG itself has not changed. The second is the release gap described above. With v2.1 from 2023-12-28 as the newest tag and the last push on 2026-08-30, anyone tracking develop is effectively tracking an untagged state. Pin a commit hash rather than a branch if you need reproducibility, and re-run make test after any update, since the Dockerfile's own flow runs the test suite between build and install.
Editorial conclusion
Adopt openMVG if you need a readable C++ implementation of feature matching, tracking, camera models and Structure from Motion that you can modify, and you are willing to build it from source and study the Wiki tutorials. Do not adopt it if you want a single command that turns photos into a textured mesh, or if you cannot maintain a C++ toolchain. Before committing, verify the submodule checkout, whether the default develop branch builds on your platform, and whether the v2.1 release is the version you want to pin, since the last push was on 2026-08-30 and the newest tagged release is from 2023-12-28.
Frequently asked questions
How do you use openMVG?
The README describes three layers: libraries for the algorithms, binaries that solve unit tasks such as scene initialization, feature detection and matching, and SfM reconstruction, and pipelines built by chaining those binaries. For your own images, the README points to the Wiki page "Using OpenMVG on your image dataset" rather than giving the sequence in the README itself.
What is the difference between OpenMVS and openMVG?
The README states that openMVG exports the reconstructed scene to other Multiple-View-Stereovision frameworks to compute dense point clouds or textured meshes. That places openMVG at the sparse reconstruction and geometry layer, with dense reconstruction handled by the framework it exports to.
How do you install openMVG?
The README links BUILD.md for local and Docker build tutorials, and the repository ships a Dockerfile that builds on Ubuntu 22.04 with CMake in RELEASE mode, then runs make, make test and make install. The Dockerfile points CMake at ../openMVG/src and initializes submodules before building.
Does openMVG have a Python interface?
No Python API is documented. The Dockerfile installs python3 as a dependency, and the README describes openMVG as a C++ framework of libraries, binaries and pipelines; the documented integration path is using it as a third-party CMake dependency, which BUILD.md covers.
What platforms does openMVG run on?
The README states that openMVG is developed in C++ and runs on Android, iOS, Linux, macOS and Windows. The provided Dockerfile targets Ubuntu 22.04, and the README does not include per-platform build walkthroughs.
Community notes