Generated banner for Tao Train Depth Anything V2
Generated logo for Tao Train Depth Anything V2

Tao Train Depth Anything V2

NVIDIAOfficialCreated by NVIDIA Corporation

  • Skill
  • Tool integration
  • Data and AI
  • Apache-2.0
  • Medium risk

From the author

Monocular depth estimation using Metric Depth Anything v2 or Relative Depth Anything architectures. Predicts per-pixel depth from single RGB images. Use when training, evaluating, exporting, or running inference for a TAO monocular depth model. Trigger phrases include "train monocular depth", "DepthAnything v2", "metric depth from single image", "monocular depth estimation".
— the description by NVIDIA Corporation

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The tao-train-depth-anything-v2 skill provides a command-line interface for managing the lifecycle of monocular depth estimation models based on the Metric Depth Anything v2 or Relative Depth Anything architectures. It supports training, evaluation, inference, export, and quantization of models that predict per-pixel depth from single RGB images. The skill integrates with the TAO toolkit's AutoML capabilities and requires specific dataset configurations to handle relative or metric depth data.

What it does

  • Trains monocular depth estimation models using Metric or Relative Depth Anything architectures.
  • Evaluates model performance on test datasets using specific metrics like Delta-1 accuracy.
  • Exports trained models to formats suitable for deployment.
  • Supports AutoML for automated hyperparameter optimization during training.
  • Performs inference on single RGB images to generate depth maps.
  • Handles quantization for optimized model execution.

When to use it

  • When you need to train a monocular depth estimation model from scratch or finetune an existing checkpoint.
  • When you have RGB image datasets with corresponding ground truth depth data.
  • When you need to convert trained models for deployment using TensorRT.
  • When you want to leverage AutoML to optimize training hyperparameters for depth estimation.

Advantages

  • Provides a unified interface for the entire model lifecycle within the TAO ecosystem.
  • Supports both relative and metric depth estimation variants.
  • Includes built-in support for AutoML to streamline the training process.
  • Offers flexible configuration for various dataset types and model architectures.

Usage examples

“Train a new relative depth model using my custom dataset.”
The agent will guide you through setting up the annotation file, selecting the RelativeDepthAnything model type, and executing the training command with the appropriate spec file.
“How do I evaluate my trained metric depth model?”
The agent will provide the necessary steps to configure the evaluation spec, point to your test dataset, and run the evaluation action to generate performance metrics.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/nvidia/tao-train-depth-anything-v2/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip tao-train-depth-anything-v2.zip -d .agents/skills

Documentation by NVIDIA Corporation

Depth Net Mono

Standalone install? If this session was not initialized by the TAO skill bank plugin, run the tao-setup skill first (host preflight, credentials, cross-skill discovery).

Monocular depth estimation using Metric Depth Anything v2 or Relative Depth Anything architectures. Predicts per-pixel depth from single RGB images.

Pretrained checkpoint loading varies by model variant and use case — see the Pretrained checkpoint loading — use case matrix in references/parameters.md.

The mono and stereo skills both invoke the unified TAO depth_net CLI inside the container; the mono/stereo family is selected via model.model_type (see references/parameters.md).

For TAO Deploy TensorRT actions (gen_trt_engine, TensorRT evaluate, and TensorRT inference), read references/tao-deploy-depth-anything-v2.md first. The deploy spec template lives in this skill's references/spec_template_deploy.yaml.

PyT actions packaged by this model skill: train, evaluate, inference, export, and quantize. The PyT depth_net entrypoint does not accept a PyT-side gen_trt_engine action in the current TAO image. The gen_trt_engine action metadata must run with the TAO Deploy container, and the deploy workflow remains the deploy-specific entrypoint.

Train Action Policy

This model is AutoML-enabled at the model layer. Before handling any train-stage request, read references/skill_info.yaml and resolve the run override from either an explicit automl_policy value or the user's workflow request. Use automl_policy: on by default and only expose on / off in new launch prompts. Treat phrases like "turn off AutoML", "disable AutoML", "no HPO", or "plain training" as automl_policy: off for this run only. When automl_policy: on, automl_enabled: true, and both schemas/train.schema.json and references/spec_template_train.yaml are packaged, route the train action through tao-skill-bank:tao-run-automl by default with this model's skill_dir. Preserve workflow/application overrides for datasets, specs, output directories, GPU/platform settings, parent checkpoints, and automl_policy. Use direct model training only when automl_policy: off or the packaged train schema/template is missing; in the missing-schema case, report that AutoML is enabled but not runnable for this model until schemas are generated.

Non-train actions such as evaluate, inference, export, and deploy flows stay in this model skill. The per-run automl_policy override does not change model metadata.

Workflow

Prerequisites — data accessibility

Your dataset (RGB images + GT depth files) must be reachable from inside the container:

  • SDK runner: place files at the S3 paths the runner resolves (the S3_TRAIN / S3_EVAL placeholders shown in Typical Spec Overrides). The runner handles S3 → container-path mounting transparently.

  • Direct docker run (e.g. local testing): mount the host dataset root read-only at the same in-container path:

docker run ... -v <host_data_root>:<host_data_root>:ro <container> ...

The same accessibility requirement applies to the <output_dir> written by all actions.

Step 1 — Annotation file

Per-line annotation file referenced by data_sources[*].data_file:

ColumnsFormatUse
1<image>Mono inference (no GT)
2<image> <gt_depth>Mono with GT

Do not pass stereo annotation rows such as <left_image> <right_image> <gt_depth> directly to mono train/evaluate/inference. If only a stereo depth dataset is available, derive a mono annotation file by keeping the left image and GT depth columns, then mount or stage the image/depth archive at the same container paths referenced by that derived annotation file.

If you already have one, point to it. Otherwise generate via depth_net convert:

depth_net convert -e <convert_spec.yaml>

convert_spec.yaml template:

results_dir: <directory where generated annotation files are written>
data_root: <directory whose immediate children are scene/sample folders that contain your image+depth files; convert walks data_root recursively but expects per-scene subdirectories at one level below>
image_dir_pattern: [<substring matching left/RGB image paths>]
depth_dir_pattern: [<substring matching GT depth paths>]
image_extension: ''     # optional .endswith filter, e.g. '.jpg'
depth_extension: ''     # optional, swapped during depth derivation, e.g. '.png'
split_ratio: 0.0        # 0.0/1.0 = test-only; 0.8 = 80/20 train+val

convert walks data_root recursively, selects paths whose path-string contains all substrings in image_dir_pattern (AND-filter), then derives the depth path by replacing image_dir_pattern[0] with depth_dir_pattern[0] and image_extension with depth_extension. Inspect your dataset's directory layout and identify the substring distinguishing RGB images from depth files (e.g. rgb_ vs sync_depth_).

data_root must point at the parent that contains the per-scene subdirectories (e.g. for NYU eval, use /data/nyu_v2/eval/test, not /data/nyu_v2/eval/test/bathroom — the latter limits the walk to a single scene). Always include the leading dot in image_extension / depth_extension (e.g. '.jpg' not 'jpg'); the substring swap is form-sensitive and a mismatch silently corrupts derived paths.

Step 2 — Pair model_type and dataset_name based on your data

Default — generic class for each task:

Data categorymodel_typedataset_name
Disparity-encoded data (pixels)RelativeDepthAnythingRelativeMonoDataset
Metric depth (meters)MetricDepthAnythingMetricMonoDataset
Mono inference (no GT, any image)matches train choiceRelativeMonoDataset or MetricMonoDataset

Dataset-specific class — switch when the data needs preprocessing the generic class does not perform:

Special casemodel_typedataset_nameWhat the class adds
NYU sync_depth_*.png (raw uint16 millimetres) — relativeRelativeDepthAnythingNYUDV2Relativemm→m unit conversion + Eigen evaluation crop
NYU sync_depth_*.png (raw uint16 millimetres) — metricMetricDepthAnythingNYUDV2same

Using a generic class on data that requires unit conversion (e.g. raw NYU uint16 PNGs) results in an empty valid mask and silent train_loss = NaN. Match the class to your data's encoding.

For relative mono data (RelativeMonoDataset or NYUDV2Relative), leave dataset.min_depth and dataset.max_depth unset or set both to null. Non-null metric depth ranges are passed into the relative dataset constructor and fail with BaseRelativeMonoDataset.__init__() got an unexpected keyword argument 'min_depth'.

Step 3 — Write spec yaml from Typical Spec Overrides

Copy the action block from Typical Spec Overrides (references/spec-overrides.md). Replace:

  • model.model_type from Step 2

  • dataset.<...>.data_sources[*].dataset_name from Step 2

  • data_sources[*].data_file with the path from Step 1 (S3 path under SDK runner, host path for direct docker)

  • For metric finetune: additionally apply the Metric Variant Finetuning Recipe in references/finetuning-recipes.md.

For mono training set train.precision: fp32 (recommended) or bf16 (Ampere SM80+, alternative).

Step 4 — Run

Create writable home/cache directories inside the mounted output path before using --user. Some TAO containers do not have an /etc/passwd entry for the host UID, and PyTorch / matplotlib need writable cache paths when running as that UID.

mkdir -p <output_dir>/home \
         <output_dir>/.cache/matplotlib \
         <output_dir>/.cache/torchinductor \
         <output_dir>/.cache/xdg
docker run --gpus 'device=0' --shm-size 16G --shm-size=8g \
  --user "$(id -u):$(id -g)" \
  -e USER="$(id -un)" \
  -e LOGNAME="$(id -un)" \
  -e HOME=<output_dir>/home \
  -e MPLCONFIGDIR=<output_dir>/.cache/matplotlib \
  -e TORCHINDUCTOR_CACHE_DIR=<output_dir>/.cache/torchinductor \
  -e XDG_CACHE_HOME=<output_dir>/.cache/xdg \
  -v <data_root>:<data_root>:ro \
  -v <output_dir>:<output_dir> \
  <container> \
  depth_net <action> -e <spec.yaml>

Without --user "$(id -u):$(id -g)" the container writes outputs as nobody:nogroup, blocking host-side cleanup and retry.

Step 5 — Verify
  • Container exit code 0

  • status.json kpi block populated

  • For train: inspect per-step train_loss directly — the entrypoint reports Execution status: PASS even when train_loss = NaN (see the Metric Variant Finetuning Recipe → Sanity-run PASS criteria in references/finetuning-recipes.md)

  • For evaluate / inference: artifacts under results_dir

For TAO Deploy TensorRT actions (gen_trt_engine, TensorRT evaluate, and TensorRT inference), read references/tao-deploy-depth-anything-v2.md first. Deploy spec templates live in this skill's references/ folder with the spec_template_deploy_*.yaml prefix.

Training Requirements

  • Valid dataset_name values for mono data_sources (case-insensitive): ThreeDVLM, FSD, NvCLIP, IssacStereo, Crestereo, Middlebury, NYUDV2, NYUDV2Relative, RelativeMonoDataset, MetricMonoDataset. NYUDV2 carries metric depth GT (meters) — pair with MetricDepthAnything; NYUDV2Relative is the same data with relative-depth conventions — pair with RelativeDepthAnything.

  • Monitoring metric: val/d1 (maximize), val/loss (minimize).

  • AutoML metric contract: for AutoML sanity runs on the packaged relative-depth smoke data, use val/d1 as the primary monitor and maximize it. Mono d1 is Delta-1 accuracy: the fraction of valid pixels where max(pred/target, target/pred) < 1.25. Do not apply the stereo d1 error-rate direction to this mono metric. val/loss can be emitted as NaN even when the trainer exits successfully and writes a usable checkpoint, so it is not a reliable AutoML objective unless the run's status metrics show a finite value.

  • Mono AutoML search allowlist: use train.optim.lr and train.optim.weight_decay for the default relative-depth train workflow. Do not search dataset.val_dataset, dataset.test_dataset, or dataset.infer_dataset augmentation fields because they change scoring/non-train behavior rather than training. Do not search model.corr_radius, model.cv_group, or model.volume_dim for mono; those fields belong to the stereo architecture and are inert for RelativeDepthAnything.

Per-Action Dataset Requirements
ActionSpec KeySourceFilesList?
evaluatedataset.test_dataset.data_sourceseval_datasetdata_file: annotations.txt + dataset_nameYes
inferencedataset.infer_dataset.data_sourcesinference_datasetdata_file: annotations.txt + dataset_nameYes
quantizedataset.train_dataset.data_sourcestrain_datasetsdata_file: annotations.txt + dataset_nameYes
quantizedataset.val_dataset.data_sourceseval_datasetdata_file: annotations.txt + dataset_nameYes
quantizedataset.quant_calibration_dataset.images_dirtrain_datasetsimages.tar.gzNo
traindataset.train_dataset.data_sourcestrain_datasetsdata_file: annotations.txt + dataset_nameYes
traindataset.val_dataset.data_sourceseval_datasetdata_file: annotations.txt + dataset_nameYes
Typical Spec Overrides

Data source overrides are mandatory for every action — construct data source paths from the Per-Action Dataset Requirements table above and include them in spec_overrides. Each data_sources entry is a dict with two mandatory fields: data_file and dataset_name. See references/spec-overrides.md for the full per-action override blocks (train, evaluate, export, inference, quantize), the S3_TRAIN / S3_EVAL placeholders, the relative-variant precision recommendation, and the quantize known-issue note.

Eval Dataset

Optional. Val dataset configured via dataset.val_dataset.data_sources (each entry needs data_file and dataset_name).

Important Parameters

See references/parameters.md for the full parameter glossary (model, train, dataset, export, and inference keys with options, defaults, and sources) and the Pretrained checkpoint loading — use case matrix.

Finetuning Recipes

See references/finetuning-recipes.md for:

  • Relative Variant Finetuning Recipe — finetune from a TAO-trained RelativeDepthAnything checkpoint (lr 5e-6, LambdaLR, sanity-vs-convergent guidance, deploy LSQ alignment note).

  • Metric Variant Finetuning Recipe — checkpoint compatibility, required overrides, the dataset normalization block (normalize_depth/min_depth/max_depth) required in train AND export specs, trainer-enforced defaults, precision, the 1-epoch sanity-run override, and the Sanity-run PASS criteria with the NaN-mitigation order.

Multi-GPU / Multi-Node

Launch method: Lightning-managed (single python process, Lightning spawns workers).

Spec KeyDescriptionDefault
train.num_gpusNumber of GPUs1
train.gpu_idsGPU device indices[0]
train.num_nodesNumber of nodes1
train.distributed_strategyddp or fsdpddp
  • ddp with activation checkpointing: find_unused_parameters=False

  • ddp without: find_unused_parameters=True

  • fsdp forces precision to FP16

Multi-node env vars (set by orchestrator): WORLD_SIZE, NODE_RANK, MASTER_ADDR, MASTER_PORT, NUM_GPU_PER_NODE.

Export / TRT Defaults

  • TRT data types: FP32, BF16 (Ampere SM80+). FP16 is not supported for the ViT-L mono backbone.

  • Fresh-install TRT precision: fp32. BF16 is supported on Ampere SM80+ hardware, but keep smoke tests on FP32 unless the user explicitly requests BF16.

Hardware

Minimum 1 GPU(s), recommended 2 GPU(s). 24GB+ VRAM per GPU. ViT-Large encoder is memory intensive. Use fp32 (recommended) or bf16 (Ampere SM80+, alternative) for training. Activation checkpointing is available for larger inputs.

Error Patterns

See references/troubleshooting.md for the full error-pattern catalog (depth range mismatch, relative dataset rejecting min_depth, missing pretrained weights, encoder key location, dataset_name not in struct, depth_net_mono not found, metric variant hyperparameter sourcing, and export ONNX overwrite).

Spec Param / Parent Model Inference

See references/spec-param-inference.md for the model-specific inference mappings (the TAO Core depth_net_mono.config.json action table), checkpoint-file naming under <results_dir>/train/, the dn_model_latest.pth policy, the parent-gen_trt_engine rationale, and the parent_model / parent_job_id resolution rules.

Deployment

Files

references/tao-deploy-depth-anything-v2.md

DepthNet Mono Deploy

DepthNet Mono deploy covers the TAO Deploy actions for an exported monocular depth estimation model. Use the depth-net-mono model skill for training, checkpoint evaluation, quantization, export, or non-TensorRT inference where those actions exist. Use this deploy workflow after export when the input artifact is an ONNX model and the desired output is a TensorRT engine or TensorRT-backed predictions.

Supported actions: gen_trt_engine, evaluate, inference. Direct TAO Deploy command name: depth_net.

Quick Start

Set the deploy container once at the top of the session — every command below uses it:

TAO_DEPLOY_IMAGE=nvcr.io/nvidia/tao/tao-toolkit:7.3.0-deploy  # versions-key: images.tao_toolkit.deploy
Generate TensorRT Engine
docker run --gpus all --rm --shm-size=16g \
  -v /path/to/specs:/specs \
  -v /path/to/export:/models \
  -v /path/to/results:/results \
  "$TAO_DEPLOY_IMAGE" \
  depth_net gen_trt_engine -e /specs/gen_trt_engine.yaml
Evaluate TensorRT Engine
docker run --gpus all --rm --shm-size=16g \
  -v /path/to/specs:/specs \
  -v /path/to/eval:/data \
  -v /path/to/results:/results \
  "$TAO_DEPLOY_IMAGE" \
  depth_net evaluate -e /specs/evaluate.yaml
TensorRT Inference
docker run --gpus all --rm --shm-size=16g \
  -v /path/to/specs:/specs \
  -v /path/to/inference:/data \
  -v /path/to/results:/results \
  "$TAO_DEPLOY_IMAGE" \
  depth_net inference -e /specs/inference.yaml

Deploy action metadata is in tao-deploy-depth-anything-v2.skill_info.yaml. Deploy spec template lives in this references folder:

  • spec_template_deploy.yaml

Deploy Workflow

  1. Train and export with the depth-net-mono skill.

  2. Keep the exported ONNX artifact and any sidecar files together in the mounted model directory.

  3. Build the TensorRT engine with this workflow.

  4. Run TensorRT evaluate or inference from the engine artifact produced by gen_trt_engine.

Direct TAO Launcher spelling is tao deploy depth_net gen_trt_engine, tao deploy depth_net evaluate, tao deploy depth_net inference.

Required Inputs

ActionRequired artifact or dataSpec key
gen_trt_engineExported monocular ONNX modelgen_trt_engine.onnx_file
evaluateTensorRT engineevaluate.trt_engine
evaluateDepth annotation filedataset.test_dataset.data_sources[0].data_file
inferenceTensorRT engineinference.trt_engine
inferenceDepth annotation filedataset.infer_dataset.data_sources[0].data_file

gen_trt_engine.trt_engine is a generated output path, not an input artifact. For direct Docker runs, mount input folders at the same paths used in the spec. For chained jobs, map exported ONNX artifacts into gen_trt_engine.onnx_file and map the engine artifact into evaluate.trt_engine or inference.trt_engine.

Spec Templates

Two model variants are supported. The deploy spec template at spec_template_deploy.yaml covers the relative variant (default). For the metric variant, start from the same template and apply the overrides below.

Relative variant (default)

Copy spec_template_deploy.yaml as a starting point. Override only paths and environment-specific values (data_file, results_dir, trt_engine paths, batch size as needed). No structural overrides required.

Metric variant

Start from the same template, then apply these metric-specific overrides:

dataset:
  test_dataset:
    data_sources:
    - dataset_name: NYUDV2              # metric pairs with NYUDV2 (not NYUDV2Relative)
      data_file: /data/annotations.txt
  infer_dataset:
    data_sources:
    - dataset_name: MetricMonoDataset
      data_file: /data/annotations.txt
  # carry the metric variant's NYU-trained normalization (from your train/export spec)
  normalize_depth: false
  max_depth: 10.0
  min_depth: 0.001

Common to both variants:

  • The TAO Deploy command is depth_net for both mono and stereo DepthNet model skills.

  • Fresh-install TRT precision: gen_trt_engine.tensorrt.data_type: fp32. BF16 is supported on Ampere SM80+ hardware, but keep validation smoke tests on FP32 unless the user requests BF16. fp16 is not supported for the ViT-L mono backbone.

  • The current TAO Deploy image interprets gen_trt_engine.tensorrt.workspace_size as GiB. Use 4 for a 4 GiB workspace; values such as 1024 request a 1024 GiB workspace and may fail on ordinary systems.

  • For aspect-preserved inference (matching pyt evaluator on variable-aspect input), set dataset.test_dataset.augmentation.crop_size and dataset.infer_dataset.augmentation.crop_size to the dataset's keep-aspect target shape (e.g., NYU 480×640 → [518, 686] with multiple_of=14). The deploy runtime selects input H/W from augmentation.crop_size, not from evaluate.input_height/input_width; leaving crop_size unset falls back to tao-core's [518, 518] default and silently overrides the engine shape. The engine input shape must match crop_size exactly (mono engines are built static at the trace shape — only the batch axis can be dynamic).

Spec filename invariant

The spec yaml's basename (modulo .yaml) must match the action verb passed on the command line. For example, gen_trt_engine requires the spec at a path ending in gen_trt_engine.yaml; evaluate requires evaluate.yaml. Mismatched filenames produce a non-obvious FileNotFoundError from the hydra config loader before any action work begins.

Job Chain Mapping

ActionSpec fieldParent or output
gen_trt_enginegen_trt_engine.onnx_fileexport job ONNX
gen_trt_enginegen_trt_engine.trt_enginenew engine output path
evaluateevaluate.trt_engineengine job output
inferenceinference.trt_engineengine job output

Outputs

ActionOutput
gen_trt_engineTensorRT engine at gen_trt_engine.trt_engine
evaluateDepth metrics under results_dir (abs_rel, d1/d2/d3 for mono; rmse is N/A for the scale-shift-invariant relative variant)
inferencePredicted depth outputs under results_dir (colorized JPGs by default; inference.save_raw_pfm: True to add raw PFMs)

Common errors

Engine profile mismatch: Runtime batch size for evaluate or inference must fit within the TensorRT min/opt/max profile used during gen_trt_engine. The default profile in the spec template is min=1 / opt=1 / max=4 — adjust if your inference call uses a larger batch.

Aspect-stretched predictions: Forcing the engine input H/W to a static shape that doesn't match the dataset's native aspect distorts the depth field. Mono examples: NYU 480×640 should run at 518×686 (keep-aspect, multiple-of-14), not 518×518. Pick the keep-aspect target at export time (export.input_height / export.input_width) and set dataset.{test,infer}_dataset.augmentation.crop_size: [518, 686] to match (this is what the deploy runtime actually reads). Different datasets with different aspect ratios require separate engines.

INT8 calibration missing: INT8 builds need an extracted calibration image directory, a writable cache path, and enough images for cal_batch_size * cal_batches.

Mounted paths do not exist: TAO Deploy checks local paths inside the container. Make sure every path in the spec has a matching Docker mount or job artifact mapping.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Needs a command-line tool, Needs Python, Needs Node.js

The author says: Requires docker + nvidia-container-toolkit.

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
NVIDIA Corporation
Publisher
NVIDIA (Official)
Source
NVIDIA/skills · skills/tao-train-depth-anything-v2 · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by NVIDIA Corporation or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download tao-train-depth-anything-v2.zip