OpenMVS: turning camera poses and a sparse cloud into a textured mesh
open Multi-View Stereo reconstruction library
At a glance
- What is it?
- OpenMVS is the dense reconstruction half of a photogrammetry pipeline: it takes camera poses plus a sparse point cloud and produces a dense cloud, a refined mesh and a texture. This article covers what each stage does, how to build it, and where it stops being the right tool.
- Who is it for?
- Adopt OpenMVS if you already have camera poses and a sparse cloud from a Structure-from-Motion stage and you need the dense, meshed, textured output that OpenMVS provides. Do not adopt it as a standalone photogrammetry tool: it does not recover poses, so it needs an upstream SfM step, and it is not a drop-in replacement for a GUI-driven reconstruction product.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- 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 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The gap OpenMVS was written to fill
OpenMVS is aimed at computer-vision scientists, and the README is explicit about the audience and the scope. Structure-from-Motion pipelines such as OpenMVG already recover camera poses and a sparse 3D point cloud from a set of images. What they do not do is finish the job. The README states that while mature open-source projects target SfM pipelines, there are none addressing the last part of the photogrammetry chain, and OpenMVS exists to fill that gap.
So the contract is narrow and clear. Input: a set of camera poses plus the sparse point cloud. Output: a textured mesh. Everything between those two points is the project's territory, and the README lists four topics it covers: dense point-cloud reconstruction, mesh reconstruction, mesh refinement and mesh texturing. Each of those is a separate algorithm and, in practice, a separate stage you run and inspect.
This matters when you are choosing a tool. If you have no poses and no sparse cloud, OpenMVS is not your starting point, and no amount of configuration will make it one. If you already have them, the alternative is usually writing your own dense matching and surface reconstruction, which is the work this project has already done.
Dense cloud, mesh, refinement, texture: the four stages
The pipeline is a chain of transformations, and each link has a distinct failure mode worth understanding before you run it.
Dense point-cloud reconstruction takes the sparse cloud and the poses and produces a dense cloud. The README describes the goal as obtaining a complete and accurate as possible point-cloud. Completeness and accuracy pull against each other here: aggressive matching fills holes but adds outliers, and conservative matching leaves gaps that the mesh stage then has to bridge.
Mesh reconstruction estimates a surface that explains the input point-cloud as well as possible. The README's phrasing is that the mesh explains the best the input point-cloud, which is a useful way to think about it. The mesh is a hypothesis about the surface, not a measurement, and where the dense cloud is thin the hypothesis is weakly constrained.
Mesh refinement then recovers fine details. This is the stage that turns a plausible but soft surface into something with actual relief. It is also the stage most sensitive to noise in the dense cloud, because refinement will happily sharpen an artefact if the points support it.
Mesh texturing computes a sharp and accurate texture to color the mesh. Release v2.3.0, dated 2024-01-07, added multi-texture support to mesh texturing, which matters for large scenes where a single texture atlas would lose resolution. Release v2.4.0, dated 2026-01-20, is described as ROI estimation and a new Viewer, so the viewing and region-of-interest tooling has also moved since the older releases.
Building OpenMVS on Linux, Windows or macOS
The README does not carry build instructions inline. It points to a building wiki page and states that Windows, Ubuntu and MacOS x64 have continuous integration status tracked through a GitHub Actions workflow. It also notes that automatic Windows x64 binary builds can be found for each commit on the Artifacts page, which is the shortest path if you are on Windows and do not want to compile.
For a source build, the repository ships a CMakeLists.txt at the top level, a vcpkg.json manifest, and a docker/ directory, so both a manifest-driven dependency install and a container path exist in the tree. The README does not document the exact CMake invocation, so treat the wiki building page as the authority rather than guessing flags.
A reasonable starting sequence on a Linux machine, following the layout of the repository, is to clone, configure with CMake, and build:
git clone https://github.com/cdcseacave/openMVS.git
cd openMVS
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
cmake --build . -jThe vcpkg.json file in the repository root is the manifest to use if you prefer vcpkg to supply dependencies. The README does not list the dependency names, so check the wiki page before assuming a package is optional.
If you would rather not build at all, the docker/ directory in the repository is the container route, and the Windows Artifacts page provides per-commit binaries. Neither is described in the README beyond its existence, so verify what each one expects to be mounted or installed.
From poses to mesh: a first run
The README points to a usage example on the wiki rather than reproducing commands, so the exact interface belongs to that page. What the README does establish is the shape of the input and output, and that is enough to plan a first run.
You need camera poses and a sparse point cloud from an SfM stage. OpenMVG is the project the README names as an example of the upstream half of the chain, and the related searches show people pairing the two by name. Once you have that scene, OpenMVS consumes it and emits a textured mesh.
The repository layout shows an apps/ directory, which is where the command-line applications live, and the README's own example link is the usage wiki page. Because the README does not spell out the binary names or flags, the honest instruction is to open that usage page and follow it, rather than to invent an invocation here.
One practical point the README does make: the output is a textured mesh, and v2.4.0 added a new Viewer. If your goal is to inspect the result rather than to feed it into another program, that Viewer is the intended surface, and it is newer than most tutorials you will find online.
Where OpenMVS is the wrong tool
The clearest limitation is structural, not incidental. OpenMVS does not recover camera poses. The README frames the whole project as the part of the photogrammetry chain that SfM projects leave undone, which means an input without poses is not a supported input. If you have only images, you need an SfM stage first, and that is a separate project with its own failure modes.
The second limitation is the build. The README delegates building to a wiki page and lists no dependencies inline. That is a signal about where the maintenance burden sits: you are expected to read external documentation before you can compile, and the CI matrix covers Windows, Ubuntu and MacOS x64, not every platform. A reader on an unlisted platform is on their own.
The third is licence. OpenMVS is AGPL-3.0, which is a strong copyleft licence and materially different from the permissive licences many C++ libraries carry. That shapes what you can do with a product built on it, and the COPYRIGHT.md file is the place the README directs you for the details.
Finally, the README does not document rollback, version pinning or a migration path between releases. If you need a stable, contractually specified upgrade story, that is not something the README offers.
OpenMVS against the alternatives
The obvious comparison is with the SfM side of the chain. OpenMVG recovers camera poses and a sparse cloud; OpenMVS takes those and produces the dense surface. The README describes them as complementary rather than competing, and the related searches suggest users arrive looking for exactly that pairing. Choosing between them is a category error unless you know which half of the pipeline you are missing.
The more interesting comparison is with an end-to-end reconstruction tool that handles both halves in one program. The difference in approach is real: a single application can tune its dense matching against the poses it just estimated, sharing intermediate state and error models, while OpenMVS must accept whatever poses it is handed. That coupling is an advantage for the integrated tool and a constraint for OpenMVS. The trade is that OpenMVS stays a library, so you can swap the SfM front end, script the stages, and embed the reconstruction in a larger system.
The release history supports reading OpenMVS as a project that keeps expanding its own surface rather than absorbing the upstream one. v2.3.0 added multi-texture support, v2.4.0 added ROI estimation and a new Viewer. Those are all improvements to the dense and output stages, not moves into pose estimation.
Licence and the cost of staying current
OpenMVS is licensed AGPL-3.0. The README does not summarise the terms; it points to COPYRIGHT.md. For a library that you link into a larger application, the AGPL is a significant choice, and it is the kind of thing to check against your distribution model before you build a product around it. This is not legal advice, and the COPYRIGHT.md file plus your own counsel are the sources that matter.
On maintenance, the repository is not archived, and the last push was on 2026-09-16. The most recent release listed is roma2-model, dated 2026-09-09, which is an ONNX model artefact rather than a tagged library version. The last tagged version release is v2.4.0 from 2026-01-20, described as ROI estimation and a new Viewer. That gap between model artefacts and version tags is worth noting if you pin dependencies: the thing you consume and the thing that gets versioned are not always the same.
Upgrade cost is hard to estimate from the README alone, because the README does not document a migration path between releases. The wiki is the place to look for build and usage changes, and the CI workflow is where you would confirm that a given platform still builds.
Editorial conclusion
Adopt OpenMVS if you already have camera poses and a sparse cloud from a Structure-from-Motion stage and you need the dense, meshed, textured output that OpenMVS provides. Do not adopt it as a standalone photogrammetry tool: it does not recover poses, so it needs an upstream SfM step, and it is not a drop-in replacement for a GUI-driven reconstruction product. Before committing, verify the AGPL-3.0 terms against how you plan to distribute your application, and check the wiki build page for the platform-specific dependency list, since the README itself only points there.
Frequently asked questions
What is OpenMVS?
OpenMVS is an open Multi-View Stereo reconstruction library written in C++, aimed at computer-vision scientists and the MVS community. It takes camera poses plus a sparse point cloud as input and produces a textured mesh as output.
What is multi-view stereo (MVS)?
The README does not define the term directly, but it places MVS as the part of the photogrammetry chain that follows Structure-from-Motion, covering dense point-cloud reconstruction, mesh reconstruction, refinement and texturing. In OpenMVS the input is poses plus a sparse cloud and the output is a textured mesh.
How do I install OpenMVS?
The README does not give inline build steps; it points to a building wiki page. It also notes that Windows x64 binaries are published per commit on the Artifacts page, and the repository contains a vcpkg.json manifest and a docker/ directory.
How do I use OpenMVS?
The README points to a usage example on the wiki rather than listing commands. The pipeline consumes camera poses and a sparse point cloud and produces a textured mesh, with dense reconstruction, meshing, refinement and texturing as separate stages.
OpenMVS vs OpenMVG: what is the difference?
They cover different halves of the pipeline. OpenMVG is named in the README as an example of a Structure-from-Motion project that recovers camera poses and a sparse point cloud; OpenMVS takes those as input and produces the dense surface and texture.
What can I use as an alternative to OpenMVS?
The README does not name an alternative. It does describe the split with SfM projects such as OpenMVG, which handle pose recovery instead of dense reconstruction, so the alternative depends on which half of the chain you are missing.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/cdcseacave-openmvs)