OpenMVG splits reconstruction into libraries, binaries and chained pipelines

Libraries, binaries and pipelines are three different things

OpenMVG is written in C++ and describes itself as an end-to-end 3D reconstruction framework from images, compounded of libraries, binaries and pipelines. The three carry different costs for whoever adopts it.

The libraries are the readable part: image manipulation, feature description and matching, feature tracking, camera models, multiple-view geometry, robust estimation and structure-from-motion algorithms. The binaries solve unit tasks a pipeline might require: scene initialization, feature detection and matching, and SfM reconstruction. The pipelines are not separate programs. They are the binaries chained together to compute image matching relations and then solve reconstruction, triangulation and localization.

The mission statement is narrow, extending awareness of 3D reconstruction from images through a C++ framework, and the credo underneath it is one line: keep it simple, keep it maintainable. The project states it runs on Android, iOS, Linux, macOS and Windows.

The container build is the only step-by-step install path in the tree

There is no command block in the README. The README links `BUILD.md` as its local/docker build tutorial, and the `Dockerfile` spells out a complete container build. It starts from `ubuntu:jammy`, with a comment noting Ubuntu 22.04 support until April 2027, then installs cmake, build-essential, graphviz, git, `coinor-libclp-dev`, `libceres-dev`, `liblemon-dev`, `libjpeg-dev`, `libpng-dev`, `libtiff-dev` and python3. It copies the source to `/opt/openMVG`, initialises submodules, and configures from `src/`:

RUN mkdir /opt/openMVG_Build; \
  cd /opt/openMVG_Build; \
  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/src; \
  make -j 4;

The last line runs the suite and installs, and the image had already put that install prefix on `PATH`:

RUN cd /opt/openMVG_Build && make test && make install;

Submodules decide whether your tree configures at all

`.gitmodules` sits in the root, and the container build treats its contents as a required step rather than an optional convenience. Immediately after `ADD. /opt/openMVG` it runs:

RUN cd /opt/openMVG && git submodule update --init --recursive

A clone that skipped the recursive step hands CMake a source tree with unfilled submodule directories, and the failure appears at configure time rather than at the git step. The README does not name which submodules the build expects or what each one contains.

Two more files sit alongside `BUILD.md` for people arriving with their own build system. `CONTRIBUTING.md` is the contribution path, and the tutorial section links straight into `BUILD.md` for using OpenMVG as a third-party library dependency with CMake. The root also carries `pixi.toml` and `pixi.lock`, and neither file is mentioned in the README.

CMake is pointed at system CLP, LEMON and OSI copies

Four of the configure flags are include-directory hints, and they are the interesting part of the build: `-DCOINUTILS_INCLUDE_DIR_HINTS=/usr/include`, `-DLEMON_INCLUDE_DIR_HINTS=/usr/include/lemon`, `-DCLP_INCLUDE_DIR_HINTS=/usr/include` and `-DOSI_INCLUDE_DIR_HINTS=/usr/include`. Three of the four point at the same directory, so the image expects system packages for the Coin-OR and LEMON stack rather than vendored copies, and a self-hosted build has to reproduce that arrangement.

The remaining two flags decide what you get. `-DOpenMVG_BUILD_TESTS=ON` builds the test suite, which is why `make test` can run inside the image. `-DOpenMVG_BUILD_EXAMPLES=OFF` leaves the examples out, so the container is a runtime image for the installed binaries, not a place to browse sample code.

One detail is worth copying if you build by hand: the container caps parallelism at `make -j 4`. That is a container-friendly number, not a statement about your hardware.

The newest tag is from December 2023, and develop has moved since

Three releases are visible, and each is named after a fish: v1.6 Halibut on 2020-05-13, v2.0 Rainbow Trout on 2021-10-20 and v2.1 Sablefish on 2023-12-28. The repository is not archived, and the last push to the default branch `develop` landed on 2026-08-30. The gap is the fact that matters: work has continued on the branch for roughly two and a half years after the most recent tag, so a pin on v2.1 pins December 2023 code.

The README's own links show how easily that split gets missed. The licence and the docker build tutorial point at `blob/master`, while the tutorial for using OpenMVG as a library points at `blob/develop`. The default branch is `develop`, so part of the documentation describes a branch that is not where new work lands.

Nothing here says the project is stalled. It says the tags and the branch tell you different things, which is the part an integrator has to resolve.

Quality gates live in CI configs, not in the library

The repository carries its own review apparatus at the root: `.coveralls.yml` for coverage, a CodeQL workflow named `codeql.yml`, and `.lgtm.yml`. A continuous integration workflow named `compile_and_run_test.yml` covers Linux, macOS and Windows, matching the claim that the framework runs on those systems. The README's credibility argument ties to this: strict test-driven development and samples are named as the reason the library can be trusted inside larger systems.

Documentation splits in two. API reference lives outside the repository at `openmvg.readthedocs.org`, while the tutorials live in the project wiki, with pages for the OpenMVG data structure, using OpenMVG as a library, and running OpenMVG on your own image dataset. The `docs/` and `logo/` directories sit at the root next to them.

The licence is MPL-2.0. For a C++ library consumed as source or as a build dependency, that is a file-level copyleft, so check how you vendor it before shipping it inside a closed product.

OpenMVG stops at sparse points, and the dense half is a second project

The clearest limit is in the README's own description of the binaries. They can export the reconstructed scene to another multiple-view stereovision framework in order to compute dense point clouds or textured meshes. Dense reconstruction is therefore somebody else's job in this arrangement, and the root file list has no viewer application or depth-estimation tool to fill the gap.

OpenMVS is the framework that pairing usually means, and the difference is one of scope rather than quality: OpenMVG owns image matching, camera geometry and the sparse point cloud, and the partner project consumes that scene to produce depth and meshes.

If your goal is a textured mesh from images, budget for two build trees, two sets of dependencies and one conversion step. If your goal is to read, modify or reuse the geometry code itself, that split costs you nothing.

Editorial conclusion

OpenMVG is a good fit when you want readable C++ implementations of camera geometry and structure from motion, or when you need the sparse scene exported into another framework, and the layered design makes the second case easy. It is a poor fit if you need dense point clouds from this repository alone, or if your build system expects a tagged release, because v2.1 dates from 2023-12-28 while the default branch develop took a push on 2026-08-30. Before you pin anything, check that `git submodule update --init --recursive` runs on your clone, since the container build treats it as a required step.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. openMVG/openMVG on GitHub
4. README
5. Releases