OpenStereo: one training and evaluation harness for stereo matching methods

A benchmark that grew into a model zoo

OpenStereo is described in the README as a flexible and extensible project for stereo matching, and the repository title calls it a comprehensive benchmark for stereo matching. The paper behind it, published on arXiv in December 2023, has the longer title OpenStereo: A Comprehensive Benchmark for Stereo Matching and Strong Baseline, and that phrase captures the two halves of the project.

The benchmark half is a common harness for training and testing stereo depth estimators. The model zoo half is a set of reproduced methods and new models, including StereoBase, the baseline the project proposed, and LightStereo, whose paper was accepted at ICRA 2025.

The audience is a researcher or engineer who wants to compare methods on standard data without reimplementing each one's training recipe. Stereo matching is a good candidate for that problem because the field has accumulated a lot of near-duplicate implementations, and a benchmark that runs them all through the same data pipeline, the same augmentation settings and the same evaluation code produces numbers that can be compared. The README states that several state of the art methods were reproduced and that the performance matched or exceeded the original results.

The second audience is anyone who wants to add a model of their own, and the documentation is arranged for that, with a document dedicated to creating a custom model and a guide to advanced usage.

Seventeen datasets behind a directory per dataset

The repository layout is the clearest description of the project's scope.

The top level holds `cfgs/`, which is where the configurations live, `data/` with a directory per dataset, `stereo/` for the modelling code, `tools/` for scripts, `deploy/` for the TensorRT work, `docs/` for the guides, and `misc/` for images. There are also two standalone markdown files at the top level, Stereo_Matching_Paper_List.md and Stereo_Matching_datasets.md, which suggests a reading list and a dataset index maintained alongside the code.

Seventeen stereo datasets are supported, and the list covers both synthetic and real data. SceneFlow, Sintel, Spring, FallingThings, InStereo2K, UnrealStereo4k, CREStereo, TartanAir, VirtualKitti2, DrivingStereo, KITTI12, KITTI15, ETH3D, Middlebury, Argoverse, FoundationStereo and StereoCarla each have their own directory under data/ with a README describing how to prepare them.

That is a lot of data pipelines, and it is the practical cost of this kind of project. Each dataset has different file layouts, different ground truth formats and different evaluation protocols, and a directory per dataset with a preparation README is the minimum viable way to keep that manageable. The documentation links a separate guide for preparing a dataset, which is where the per-dataset specifics live.

The `stereo/` directory is where the models live, and the README links the LightStereo code at stereo/modeling/models/lightstereo. Having the models and the configs in one tree is what lets a single training entry point cover the whole zoo.

Getting started is a chain of documents, not a command

There is no single install command in the README. The project points you at a sequence of documents instead, and the order of that sequence is itself a description of the workflow.

The entry point is docs/0.get_started.md. From there the guides continue with docs/2.prepare_dataset.md for preparing data, docs/3.detailed_config.md for the configuration system, docs/4.how_to_create_your_model.md for adding a model, and docs/5.advanced_usages.md for the advanced paths. The model zoo with its results and checkpoints lives in docs/1.model_zoo.md, and the TensorRT integration has its own deployment documentation in deploy/README.md.

The Python dependencies are listed in requirements.txt at the top level, and the list is short: tqdm, easydict, tensorboard, six, pyyaml, opencv-python, timm, scikit-image, thop and matplotlib. Two entries stand out. timm is pinned to 0.4.12, which is an old pin for a library that provides the vision backbone implementations these models build on, and it is the kind of constraint that decides whether a fresh environment installs cleanly. And PyTorch itself is not in the requirements file, so the framework is expected to be present in the environment already, which matters when you are installing a specific CUDA build that matches your driver.

The `timm` pin and the missing torch entry are the two things to check first when the environment does not come up.

DDP, AMP and TensorRT are the three scaling paths

Three highlighted features determine whether the framework is usable on real hardware, and they are worth separating because they solve different problems.

Distributed Data Parallel is the officially recommended mode, and the README says it is used during both the training and the testing phases. That second part is the unusual detail. A DDP setup for evaluation means you can score a large test set across several GPUs and get consistent numbers, which matters for reproducing leaderboard style results where a single device would take hours.

Auto Mixed Precision is offered as an option, which is the standard way to trade a little numerical precision for a large gain in throughput on recent GPUs. It is available rather than mandatory, so the same configuration can be run with and without it.

TensorRT was integrated in June 2024, and the deployment documentation in deploy/README.md is where that path is described. This is the difference between a research framework and something you would put in front of traffic, and it is the part of the project most likely to be tested by a deployment team rather than a research team.

The logging story is the least glamorous and the most useful in practice. The project uses tensorboard together with the standard logging module, and the README's phrasing is that it logs everything, which for a benchmark means you can compare training curves across methods without writing your own instrumentation.

The extension point is the `cfgs/` directory. The OpenStereo paper's code is linked at cfgs/, so the configurations are treated as first class artifacts of the benchmark rather than as an afterthought.

The non-commercial clause is the real licence

The licence field on the repository is recorded as unknown, and the README closes with a note that has more force than a licence identifier: this code is only used for academic purposes, and people cannot use this code for anything that might be considered commercial use.

That is the single most consequential line in the README for anyone outside a research group. It is not a permissive open source licence with a patent grant and a warranty disclaimer. It is a restriction on use, and a restriction phrased in broad terms, because what counts as commercial use is not defined in the note itself.

Nothing here is legal advice, and the practical point is procedural: if your work is funded by a company, or your output feeds a product, the note needs to be checked by whoever handles licence questions in your organisation before any of this code enters a pipeline. A repository whose licence GitHub cannot classify is a signal to read the file rather than to assume.

The second limitation is more mundane and shows up on day one. The `timm` pin to 0.4.12 is the kind of constraint that ages badly, and a backbone library that old may not install cleanly against a current PyTorch. The absence of PyTorch from requirements.txt is a second friction point, since the framework version is left to the environment and the repository does not state which build it expects.

A third limitation is about the benchmark claim itself. Reproducing a method and getting the same or better numbers is not the same as the original implementation, and a benchmark's numbers inherit the data pipeline, augmentation and evaluation code of the harness, not only the model. The README does not publish a compatibility matrix for the models it reproduces, so treat cross paper comparisons with care.

A publication timeline that the repository has outgrown

The README's news section is a chronology of the project, and reading it explains the current state.

The project was announced in March 2023 and the paper followed in December 2023. In January 2024 the proposed StereoBase model ranked first on the KITTI15 leaderboard. The 2.0 version arrived in May 2024 with an optimized training and testing framework, and TensorRT was integrated in June 2024. FoundationStereo was integrated in June 2025. The StereoCarla dataset paper was made public in September 2025, and LightStereo was accepted at ICRA 2025.

The releases tell a different, slower story. The tagged versions are v1.1-beta in March 2024, v1.2-beta in April 2024 and v1.3-beta in May 2024, all of them beta and all of them from that spring. The default branch is named v2, which lines up with the 2.0 version described in the news section, and the repository is not archived with the last push on 2026-08-13.

So the pattern is a burst of tagged beta releases in 2024, followed by continued work on the v2 branch with new model integrations and new papers but no new tagged release. If you pin a version for reproducibility you are pinning a 2024 beta, and if you follow the default branch you are following an environment that the requirements file has not caught up with. The repository layout also carries a `deploy/` directory and per-model documentation, which is the shape of a project that is still absorbing the models it reproduces.

Editorial conclusion

Adopt OpenStereo if you are comparing stereo depth methods on common datasets and want one training script, one evaluation path and one set of configurations, because that consistency is the entire point of the project. Do not adopt it for a commercial product, since the README states the code is only used for academic purposes and that it cannot be used for anything that might be considered commercial use. Before building on it, read the deployment documentation in deploy/README.md and the get started guide in docs/0.get_started.md, and check the requirements file, where timm is pinned to 0.4.12.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. XiandaGuo/OpenStereo on GitHub