Depth Anything V2: Monocular Depth Estimation Without a Depth Sensor

What Depth Anything V2 predicts, and for whom

Give it a single RGB image and it returns a depth map: an HxW array where each value orders the scene from near to far. No stereo pair, no LiDAR, no calibration. The README describes the model as a foundation model for monocular depth estimation, and the repository carries four relative-depth checkpoints at 24.8M, 97.5M and 335.3M parameters, plus a 1.3B Giant variant listed as coming soon.

The audience is narrower than the model page suggests. The primary interface is Python: you load a checkpoint with torch.load, build a DepthAnythingV2 object from a config dict, and call infer_image. That fits robotics prototyping, dataset preprocessing, image editing tools and research code where depth is an intermediate signal rather than a product. Someone who wants a depth map from a phone photo and nothing else is better served by the hosted demo than by cloning anything.

The DINOv2-DPT backbone and the inference path

The architecture is a DINOv2 vision transformer encoder feeding a DPT-style decoder, and the README notes that V2 makes a minor modification to that V1 architecture. Each encoder size has its own config: vits uses 64 features with out_channels [48, 96, 192, 384], vitl uses 256 features with [256, 512, 1024, 1024], and vitg uses 384 features with [1536, 1536, 1536, 1536].

The load path is explicit and unforgiving. You pick an encoder key, construct the model with the matching config, load a state dict from checkpoints/depth_anything_v2_{encoder}.pth, move it to a device and call .eval(). The README's example selects the device as cuda if available, then mps, then cpu. infer_image takes a raw image read by cv2.imread and returns a NumPy depth map. Nothing in that chain resizes for you or normalizes output for you; run.py and run_video.py wrap it for batch work, with input size 518 as the default and the README stating that increasing it gives more fine-grained results. The video script exists separately, and the README claims larger models hold temporal consistency better across frames.

Installing Depth Anything V2 and running a first image

The repository installs from source. Clone it, install the requirements file, then fetch a checkpoint. The requirements list is short: gradio_imageslider, gradio, matplotlib, opencv-python, torch and torchvision. Note that torch is unpinned, so you supply the build that matches your CUDA or MPS setup.

git clone https://github.com/DepthAnything/Depth-Anything-V2
cd Depth-Anything-V2
pip install -r requirements.txt

Download one of the checkpoints linked in the README's model table and place it under a checkpoints directory at the repository root. The file name matters because the loading code builds the path from the encoder key, so a Large checkpoint must land as checkpoints/depth_anything_v2_vitl.pth.

For a first real run, point run.py at a directory of images. This is the README's own example, using the Large encoder and writing visualisations to depth_vis.

python run.py --encoder vitl --img-path assets/examples --outdir depth_vis

Expect one depth visualisation per input image in depth_vis. Add --pred-only to drop the side-by-side raw image, or --grayscale to skip the colour palette. The same script accepts a single image path or a text file listing image paths, which is the practical way to process a curated set without moving files around.

If you would rather not clone, the README offers a Transformers route through the depth-estimation pipeline with the model depth-anything/Depth-Anything-V2-Small-hf. It carries two caveats: you need connectivity to Hugging Face and a recent Transformers install, and because the repository uses OpenCV upsampling while Transformers uses Pillow, predictions can differ slightly. The README recommends the repository path over the pipeline for that reason.

Where Depth Anything V2 stops being the right tool

The relative-depth checkpoints do not give you metres. The output is a raw NumPy map with no scale attached, so anything requiring measured distance (collision thresholds, room dimensioning, survey work) needs the metric_depth directory and its separate small and base models, not the main checkpoints. The README does not document how to convert a relative map into metric units, because that is not what these weights do.

Video is the second boundary. run_video.py processes frames, and the README's own claim is comparative rather than absolute: larger models are more temporally consistent. It does not promise flicker-free output, and there is no documented temporal smoothing step. If your application is a moving camera and you need stable depth across frames, the README points to a separate project, Video Depth Anything, for consistent depth on long videos.

Third, the README does not document rollback, checkpoint versioning or a compatibility matrix between code revisions and weight files. The repository was flagged and removed from public view for six days in June 2024, per the news list, which is a reminder that the canonical source can be unavailable. Anyone building a pipeline on a fresh clone should keep their own copy of the weights.

Depth Anything V2 against MiDaS, Marigold and Depth Pro

MiDaS is the older relative-depth baseline that many pipelines still use, and the difference here is the backbone: Depth Anything V2 builds on a DINOv2 encoder with a DPT decoder rather than the earlier convolutional and transformer mix, and the README frames the V1-to-V2 change as a gain in fine-grained detail and robustness. Marigold takes a diffusion approach to depth, which is a different family of model with different inference cost characteristics; the README does not compare against it directly, so treat any speed or quality comparison as something to measure on your own images. Depth Pro is likewise outside the repository's own evaluation. The one comparison the README does make is against SD-based models generally, claiming faster inference, fewer parameters and higher accuracy, and the DA-2K benchmark is published alongside the code if you want the project's own numbers rather than a summary of them.

Licence, maintenance and what an upgrade costs

The repository is Apache-2.0. That is a permissive licence, but it covers the code in this repository; the checkpoints are hosted on Hugging Face under the depth-anything organisation, and the licence terms attached to those weights are a separate question worth reading before commercial use. Nothing here is legal advice.

On maintenance, the last push to main was on 2026-03-24, which is recent enough that the repository is not stale, but the project ships no releases, so there is no versioned artefact to pin. Upgrades therefore mean pulling main and re-checking that your checkpoint still loads against the current DepthAnythingV2 config dicts. That is cheap if you stay on one encoder, and annoying if you have hard-coded the out_channels lists, since those differ per encoder and a mismatch surfaces as a state-dict load error rather than a clear message. The practical upgrade cost is small but manual.

Editorial conclusion

Adopt Depth Anything V2 if you need relative depth from ordinary images and can run PyTorch locally; the small checkpoint is the sensible starting point, and the metric_depth directory is the path to metric output. Do not adopt it if you need absolute distances out of the box, or if you cannot accept the OpenCV and Pillow upsampling difference that makes Hugging Face pipeline output diverge slightly from the repository code. Before committing, verify which encoder your checkpoint matches, confirm the checkpoint file is in the checkpoints directory under the name the loading code expects, and check whether your target platform is one of the ones the project has published a converted model for.

Frequently asked questions

Official sources

1. DepthAnything/Depth-Anything-V2 on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README