StereoPipeline turns stereo images into terrain, orthos and 3D models

A pipeline of separate tools, not a single program

The Ames Stereo Pipeline is described as a suite of free and open source automated geodesy and stereogrammetry tools for processing stereo images captured from satellites around Earth and other planets, robotic rovers, aerial cameras, and historical images, with and without accurate camera pose information.

The phrase suite of tools is the important part. ASP is not a program with a single entry point and a user interface. It is a set of executables in a bin subdirectory, each doing one job, driven by command line arguments and configuration files, and the documentation includes an entry for each tool along with example processing workflows for many supported sensors. The examples directory in the repository carries per mission sets such as CTX, HiRISE, K10, MER, MOC and a synthetic case, plus a surf_match.patch and a TriangulationError.lut.

The primary language is C++, and the build is CMake with a CMakeLists.txt at the root and a cmake directory. The layout also includes a plugins directory, a conda directory, a docs directory, and a thirdparty directory that matters for licensing.

For a user, this means the learning curve is not about a GUI but about the order of operations between tools, which is what the example workflows in the documentation exist to teach.

Camera models and bundle adjustment are the core competence

ASP supports a wide range of camera models, including linescan, frame, pushframe, optical bar, RPC, and the USGS Community Sensor Model. That list is the practical boundary of what imagery it can ingest, and it covers most of what exists in orbital and aerial archives.

The tool can create cameras from scratch and refine them with bundle adjustment, solving for pose, jitter, lens distortion, and rig calibration. That sentence carries most of the project's value, because it is what lets the pipeline work on imagery with no usable camera pose.

Bundle adjustment here is the standard photogrammetric process: the initial stereo match gives relative geometry, the adjustment then optimises the camera parameters and the 3D points jointly to minimise reprojection error, and out of that come the refined poses, the lens distortion correction, and the rig calibration between sensors. Jitter is the pointing noise in pushbroom and linescan imagers, and handling it is a large part of what makes planetary stereo work, since a Mars rover or a Mars orbiter does not have a mechanically fixed attitude.

The two cited references in the README reflect the two halves of the software. The general ASP citation is Beyer, Alexandrov and McMichael from 2018 on the Ames Stereo Pipeline itself, and the second is Shean and colleagues from 2016 on an automated open source pipeline for mass production of digital elevation models from very high resolution commercial stereo satellite imagery, which is the Earth observation use case. The documentation also asks that you cite the specific version's DOI, since every release and daily build has its own.

The product list runs from DEMs to a GUI shell

On the 3D side, ASP has functionality for terrain creation from stereo, including shallow-water bathymetry, alignment of point clouds, map projection, structure-from-motion, shape-from-shading, GCP generation, and a versatile GUI shell.

Those items are worth separating. Bathymetry means the stereo pair straddles a water surface, which changes the geometry because the refractive index of water is different, and ASP handles that case. Point cloud alignment is the registration of two independently generated terrain patches into a common frame. Map projection is the conversion of the georeferenced 3D product into a projected raster. Structure-from-motion and shape-from-shading are the photogrammetric and radiometric counterparts to stereo matching, for the case where you have more than two images or a single image with lighting information. GCP generation produces ground control points for georeferencing, which is how imagery without positioning metadata gets placed on the Earth or a planet.

The cartographic outputs are digital terrain models, ortho-projected images, 3D models, and bundle-adjusted networks of cameras. The documentation states these products are suitable for science analysis, mission planning, and public outreach.

The GUI shell is listed among the 3D and terrain features rather than as a separate application, which reflects how the project is used: command line tools for the real work, with a graphical front end available for exploring the results.

Precompiled binaries for four platform combinations

Installation is deliberately not a build. Precompiled binaries for Linux on Intel and ARM64, and for macOS on Intel and ARM64, are available for the stable releases and for the current development build. The instruction is to download the appropriate distribution for the operating system and architecture, extract it, and run the executables in the bin subdirectory.

The documentation page for stable releases, daily builds and conda packages is the single place all of those distribution channels are listed, which is worth knowing if you would rather install through conda than download a tarball.

Making the executables permanently available is a PATH edit, and the documentation gives the exact form to add to a shell configuration file such as ~/.bashrc, appending the ASP executable subdirectory to the existing PATH with a line of the form export PATH=${PATH}:/path/to/StereoPipeline/bin.

One dependency is conditional on your data. ISIS users are asked to install the latest USGS ISIS to process NASA non-terrestrial images. Users processing Earth images, such as DigitalGlobe data, satellites with RPC cameras, or various frame and pinhole cameras, do not need to download anything else. And if ASP is installed with conda, it will install ISIS in the same environment as well, though it may not be the latest version, which is a caveat worth checking if you depend on a specific ISIS feature.

The release cadence is visible in the tags. Recent entries are daily builds named for their date, such as 2026-10-20-daily-build and 2026-10-19-daily-build, along with a geoid2.0 tag from 2026-09-26. The last push was on 2026-10-20, so the development branch moves daily while stable releases are cut separately.

Third party code sits outside the Apache licence

The licensing section of the README is unusually careful, and the reason is a distribution practice rather than a legal subtlety.

ASP itself is free software released under the Apache Software License 2.0, with the full text in the LICENSE file, and the copyright statement runs from 2009 to 2026 for the United States Government as represented by the Administrator of the National Aeronautics and Space Administration.

But the distribution may include some bundled third party software as a convenience to the user. That software lives in the thirdparty directory of the source code release, and it is explicitly not covered by the Apache distribution agreement or copyright. Binary releases distribute third party software in both the bin and lib directories, and the user is directed to the included documentation or to the THIRDPARTYLICENSES file for the detailed copyright and licence information.

There is a second, subtler clause. Various pieces of ASP depend on additional third party libraries that the user is expected to have installed. The bundled ones are covered by the THIRDPARTYLICENSES file; the ones you are expected to bring yourself are your own responsibility to track.

This is a solvable problem and not a reason to avoid the software, but it does mean a redistributable product that ships ASP binaries has a compliance task attached, and a team that builds from source has to track the system level dependencies separately.

Where the pipeline stops

Three limits are worth naming.

The first is that stereo photogrammetry needs geometry, not just images. A pair of overlapping frames with texture is the input. If your data is a single image, a non-overlapping set, or an image set with no camera model and no way to solve for one, the pipeline has nothing to work with, and no amount of configuration changes that.

The second is that the outputs are files, not a session. A DEM is a raster, an ortho is a raster, a 3D model is a mesh or point cloud, and a bundle-adjusted camera network is a set of files. If your requirement is to open a point cloud and rotate around it, this is the wrong category of software and you want a viewer and an editor rather than a photogrammetric engine.

The third is that the toolchain is the surface area. Each executable takes its own arguments, workflows are assembled by you, and the documentation has to teach the order of operations for each sensor. That is manageable with a script and a Makefile, and it is a real cost if you expected a single command.

The alternative worth naming is a different class of tool rather than a competitor. Commercial photogrammetry software packages such as commercial satellite DEM producers, and the research tool Pix4D, cover overlapping territory with more polished workflows and paid support, and they are typically restricted to Earth oriented data with commercial licensing. Open source alternatives for Earth stereo include other DEM pipelines, but the distinguishing feature of ASP is the non-terrestrial side: planetary and rover imagery, the USGS Community Sensor Model, and the ISIS input path, none of which those products serve. A team doing planetary stereo has few options; a team doing Earth stereo from commercial imagery has several, and should compare them on workflow and support rather than on capability.

Editorial conclusion

StereoPipeline fits a photogrammetry or planetary science team that has stereo imagery and needs a reproducible, scriptable, academically citable pipeline from raw images to a terrain product, particularly one working with non-terrestrial data where ISIS is the input format. It is the wrong tool for a one off photo or a quick 3D scan of a small object, and it is the wrong tool if you need an interactive point cloud editor, since the output products are files rather than a session. Before adopting it, check three things: that your imagery has usable geometry, since stereo matching needs overlap and a camera model even when bundle adjustment is used to recover one, that your distribution has the executables you need for your platform, since precompiled binaries are provided for Linux and macOS on both Intel and ARM64, and that you have read the third party licensing notes, because the distribution bundles software in a thirdparty directory that the Apache licence does not cover.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. NeoGeographyToolkit/StereoPipeline on GitHub
4. README
5. Releases