DAP - Moses Yebei

The Problem

Standard depth estimation models fail on equirectangular panoramas because they assume pinhole camera geometry, causing distortion at the poles and inconsistent scale across the field of view. This repo provides a foundation model trained specifically for panoramic depth estimation, handling the spherical-to-planar projection issues that break conventional approaches.

What This Does

DAP is the official implementation of "Depth Any Panoramas," a CVPR 2026 paper. It adapts the Depth-Anything-V2 architecture to panoramic input, with custom dataset loaders for equirectangular imagery (datasets/ contains 10+ dataset adapters including M3D.py, deep360.py, insta23k.py). The repo includes utilities for converting between equirectangular and cubemap projections (depth_anything_utils.py), plus depth-to-point-cloud (depth2point.py) and depth-to-normal (depth2normal.py) conversion scripts.

The core model lives in depth_anything_v2_metric/, which vendors the DINOv2 and DINOv3 backbones. The config/ directory holds inference and test configurations, while test/infer.py and test/eval.py are the primary entry points.

How It Is Wired

Execution starts at test/infer.py, which loads configuration from config/infer.yaml, instantiates the DPT head from depth_anything_v2_metric/depth_anything_v2/dpt.py, and runs inference using the DINOv2 backbone (dinov2.py). The dataset loaders in datasets/ handle equirectangular-to-cubemap conversion via functions like Equirec2Cube, cassini2Equirec, and spherical_uv_to_directions.

The import graph shows 124 edges across 189 modules with no circular dependencies. The most-connected modules are dinov3/hub/backbones (5 importers) and eval/detection/util/misc (7 importers). The depth_anything_v2_metric directory is effectively a second project—a vendored copy of the DINOv3 training/eval suite—that adds substantial complexity but is only loosely coupled to the main inference path.

How To Use It

git clone https://github.com/moses-y/DAP
cd DAP
pip install torch==2.7.1 torchvision==0.22.1
pip install -r requirements.txt
python test/infer.py

Configuration lives in config/infer.yaml (model weights path, input/output directories). The pretrained weights must be downloaded from Hugging Face (Insta360-Research/DAP-weights) and placed where the config expects. The training dataset is also on Hugging Face (Insta360-Research/DAP_data). Evaluation runs via python test/eval.py using config/test.yaml.

Real-World Use

For a 360° camera system needing real-time depth, you would load the pretrained model, feed it equirectangular frames, and get per-pixel metric depth. The depth2point.py utility converts output to 3D point clouds for downstream tasks like obstacle avoidance or 3D reconstruction. The model handles both indoor (Stanford2D3D, Matterport3D) and outdoor (Deep360) panoramic datasets.

Code Health & Issues

Static analysis found 34 issues across 6 categories:

High - Deep nesting (25 occurrences): datasets/util.py, dinov3/data/masking.py, and dinov3/eval/segmentation/models/utils/ops/modules/ms_deform_attn.py reach indentation depth 8, making control flow hard to follow.
High - Duplicated code: 1041 repeated 6-line blocks across 100 files, concentrated in datasets/ loaders. Shared helper extraction is overdue.
Medium - File opened without context manager (3 occurrences): dinov3/data/datasets/decoders.py, dinov3/logging/__init__.py, dinov3/thirdparty/CLIP/clip/simple_tokenizer.py.
Medium - Broad exception handling (3 occurrences): dinov3/checkpointer/checkpointer.py, dinov3/utils/utils.py, and the CLIP tokenizer.
Medium - Oversized file: dinov3/train/ssl_meta_arch.py at 679 lines.
Low - 7 TODO/FIXME markers in dinov3/eval/segmentation/models/heads/pixel_decoder.py.

No CI/CD pipeline, no lockfile, and no Dockerfile are present. The repo includes compiled .pyc files committed to source control, which should be gitignored. A license file exists.

The Bottom Line

This is a functional research implementation with a solid core inference path but heavy vendored dependencies. The depth_anything_v2_metric subtree is a full DINOv3 codebase that inflates the repo to 372 files and complicates maintenance. Use it if you need state-of-the-art panoramic depth estimation and can tolerate the research-code hygiene issues; expect to refactor the dataset loaders before production use.

What the analyser found

Deployment readiness

4/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

372 files

Python189
YAML18
Markdown6
Jupyter Notebook5
C/C++ Header3
C++2

PyTorchTransformersCUDA

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["depth_anything_v2_metr 170 modules"] g1["datasets 6 modules"] g2["networks 6 modules"] g3["(root) 4 modules"] g4["test 3 modules"] g2 -->|2| g0 g4 -->|2| g2 g2 -->|1| g3 g4 -->|1| g1

Module dependencies

The 10 most depended-upon modules of 189, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_ov3_eval_detection_util_misc["misc"] n1_g_v2_dinov3_dinov3_hub_utils["utils"] n2__dinov3_dinov3_hub_backbones["backbones"] n3_inov3_data_datasets_extended["extended"] n4_inov3_data_datasets_decoders["decoders"] n5_networks_models["models"] n6_h_anything_v2_dinov3_adpther["dinov3_adpther"] n7_ric_depth_anything_v2_dinov2["dinov2"] n8_ion_models_position_encoding["position_encoding"] n9_g_v2_dinov2_layers_attention["attention"] n3_inov3_data_datasets_extended --> n4_inov3_data_datasets_decoders n8_ion_models_position_encoding --> n0_ov3_eval_detection_util_misc n2__dinov3_dinov3_hub_backbones --> n1_g_v2_dinov3_dinov3_hub_utils

Dependencies

1 of 21 declared dependencies are a major version behind. Resolved 21 of 21 against the registry.

Package	Declared	Latest	Behind
`gradio`	==4.36.0	6.24.0	2 major

Findings

MediumNo CI/CD pipeline detected - no automated build/test gate .github/ or CI config
LowDependencies declared without a lockfile - non-reproducible builds depth_anything_v2_metric/depth_anything_v2/dinov3/pyproject.toml

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

critical1

high3

medium4

Upgrade the pinned dependency carrying a critical advisorycritical58 occurrences

gradio@4.36.0 CVE-2025-23042 (critical) +57 more

The manifest pins the exact version the advisory covers, so this is not a warning about drift: the vulnerable code is what installs, and a critical rating means it is reachable over the network without credentials or user interaction.

Fix: Upgrade to the fixed version named in the advisory, then commit the lockfile.

Upgrade the pinned dependency carrying a published advisoryhigh18 occurrences

tornado@6.5.2 CVE-2026-49853 (high) +17 more

The pinned version is the one that installs, so a published advisory against it describes this deployment rather than a hypothetical one, and the advisory is also a public description of how to exploit it.

Fix: Upgrade to the fixed version named in the advisory, then commit the lockfile.

Commit a lockfile beside the manifesthigh

depth_anything_v2_metric/depth_anything_v2/dinov3/pyproject.toml

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Add a workflow that builds and tests this repositoryhigh

191 source files, no CI configuration

Every change merges with nobody having run the build once, which across this estate is 499 repositories.

Fix: Add a workflow running the project build and test command on push and pull_request.

Enable Dependabot or Renovatemedium

4 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Strip notebook outputs before committingmedium3 occurrences

depth_anything_v2_metric/depth_anything_v2/dinov3/notebooks/dense_sparse_matching.ipynb

3 notebook(s) over 1MB, 12.4MB total, dominated by stored output

Outputs are where a printed dataframe of customer rows or a traceback containing a connection string ends up, and diff review never reads them.

Fix: Install nbstripout and clear the existing outputs once.

Move large binaries to Git LFS or out of the repositorymedium3 occurrences

assets/teaser.jpg

3 blobs over 5MB: teaser.jpg 8.7MB, depth_teaser2_00.png 6.7MB, dense_sparse_matching.ipynb 6.3MB

One repository here carries twenty blobs over 5MB including a 10.9MB spreadsheet, so every clone and every CI checkout pays for data nobody diffs.

Fix: Track those extensions with LFS, or move datasets to object storage and fetch them in a setup step.

Expand the test suite; it cannot cover this codebasemedium3 occurrences

3 test files against 191 source files (ratio 0.016)

A reviewer reads "has tests" and assumes a safety net that covers two files out of eighty-five, which is how untested paths ship behind a green badge.

Fix: Add tests for the highest fan-in modules first.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.