Tao Train Depth Anything V2
NVIDIAOfficialCreated by NVIDIA Corporation
- Skill
- Tool integration
- Data and AI
- Apache-2.0
- Medium risk
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
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/nvidia/tao-train-depth-anything-v2/downloadUnzip 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-setupskill 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_EVALplaceholders 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:
| Columns | Format | Use |
|---|---|---|
| 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+valconvert 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 category | model_type | dataset_name |
|---|---|---|
| Disparity-encoded data (pixels) | RelativeDepthAnything | RelativeMonoDataset |
| Metric depth (meters) | MetricDepthAnything | MetricMonoDataset |
| Mono inference (no GT, any image) | matches train choice | RelativeMonoDataset or MetricMonoDataset |
Dataset-specific class — switch when the data needs preprocessing the generic class does not perform:
| Special case | model_type | dataset_name | What the class adds |
|---|---|---|---|
NYU sync_depth_*.png (raw uint16 millimetres) — relative | RelativeDepthAnything | NYUDV2Relative | mm→m unit conversion + Eigen evaluation crop |
NYU sync_depth_*.png (raw uint16 millimetres) — metric | MetricDepthAnything | NYUDV2 | same |
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_typefrom Step 2dataset.<...>.data_sources[*].dataset_namefrom Step 2data_sources[*].data_filewith 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/xdgdocker 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.jsonkpiblock populatedFor
train: inspect per-steptrain_lossdirectly — the entrypoint reportsExecution status: PASSeven whentrain_loss = NaN(see the Metric Variant Finetuning Recipe → Sanity-run PASS criteria inreferences/finetuning-recipes.md)For
evaluate/inference: artifacts underresults_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_namevalues for monodata_sources(case-insensitive):ThreeDVLM,FSD,NvCLIP,IssacStereo,Crestereo,Middlebury,NYUDV2,NYUDV2Relative,RelativeMonoDataset,MetricMonoDataset.NYUDV2carries metric depth GT (meters) — pair withMetricDepthAnything;NYUDV2Relativeis the same data with relative-depth conventions — pair withRelativeDepthAnything.Monitoring metric:
val/d1(maximize),val/loss(minimize).AutoML metric contract: for AutoML sanity runs on the packaged relative-depth smoke data, use
val/d1as the primary monitor and maximize it. Monod1is Delta-1 accuracy: the fraction of valid pixels wheremax(pred/target, target/pred) < 1.25. Do not apply the stereod1error-rate direction to this mono metric.val/losscan be emitted asNaNeven 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.lrandtrain.optim.weight_decayfor the default relative-depth train workflow. Do not searchdataset.val_dataset,dataset.test_dataset, ordataset.infer_datasetaugmentation fields because they change scoring/non-train behavior rather than training. Do not searchmodel.corr_radius,model.cv_group, ormodel.volume_dimfor mono; those fields belong to the stereo architecture and are inert forRelativeDepthAnything.
Per-Action Dataset Requirements
| Action | Spec Key | Source | Files | List? |
|---|---|---|---|---|
| evaluate | dataset.test_dataset.data_sources | eval_dataset | data_file: annotations.txt + dataset_name | Yes |
| inference | dataset.infer_dataset.data_sources | inference_dataset | data_file: annotations.txt + dataset_name | Yes |
| quantize | dataset.train_dataset.data_sources | train_datasets | data_file: annotations.txt + dataset_name | Yes |
| quantize | dataset.val_dataset.data_sources | eval_dataset | data_file: annotations.txt + dataset_name | Yes |
| quantize | dataset.quant_calibration_dataset.images_dir | train_datasets | images.tar.gz | No |
| train | dataset.train_dataset.data_sources | train_datasets | data_file: annotations.txt + dataset_name | Yes |
| train | dataset.val_dataset.data_sources | eval_dataset | data_file: annotations.txt + dataset_name | Yes |
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
RelativeDepthAnythingcheckpoint (lr5e-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 Key | Description | Default |
|---|---|---|
train.num_gpus | Number of GPUs | 1 |
train.gpu_ids | GPU device indices | [0] |
train.num_nodes | Number of nodes | 1 |
train.distributed_strategy | ddp or fsdp | ddp |
ddpwith activation checkpointing:find_unused_parameters=Falseddpwithout:find_unused_parameters=Truefsdpforces 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
- ATTRIBUTION.mdAdded by AutoGineer951 B
- BENCHMARK.md7.0 KiB
- LICENSELicence file added by AutoGineer11.2 KiB
- SKILL.md15.3 KiB
- config/skillspector-baseline.yaml1010 B
- evals/evals.json871 B
- references/finetuning-recipes.md7.1 KiB
- references/parameters.md5.4 KiB
- references/skill_info.yaml4.4 KiB
- references/spec-overrides.md4.6 KiB
- references/spec-param-inference.md3.4 KiB
- references/spec_template_deploy.yaml2.1 KiB
- references/spec_template_evaluate.yaml5.6 KiB
- references/spec_template_export.yaml5.6 KiB
- references/spec_template_gen_trt_engine.yaml5.6 KiB
- references/spec_template_inference.yaml5.6 KiB
- references/spec_template_quantize.yaml5.4 KiB
- references/spec_template_train.yaml5.4 KiB
- references/tao-deploy-depth-anything-v2.md7.3 KiB
- references/tao-deploy-depth-anything-v2.skill_info.yaml2.4 KiB
- references/troubleshooting.md2.1 KiB
- schemas/evaluate.schema.json104.5 KiB
- schemas/export.schema.json105.1 KiB
- schemas/gen_trt_engine.schema.json107.0 KiB
- schemas/inference.schema.json104.9 KiB
- schemas/manifest.json29.9 KiB
- schemas/quantize.schema.json101.4 KiB
- schemas/train.schema.json101.4 KiB
- skill-card.md4.9 KiB
- skill.oms.sig10.1 KiB
references/finetuning-recipes.md
Finetuning Recipes
Relative Variant Finetuning Recipe
Relative finetune from a TAO-trained RelativeDepthAnything checkpoint:
| Spec key | Value | Notes |
|---|---|---|
model.model_type | RelativeDepthAnything | |
model.encoder | vitl | matches the released TAO relative checkpoint |
model.mono_backbone.pretrained_path | "" | the full TAO checkpoint already carries the backbone state; setting this is redundant and is overwritten by the full-state load |
train.pretrained_model_path | <TAO relative ckpt> | full Pytorch-Lightning state load |
train.precision | fp32 (recommended) or bf16 (alternative on Ampere SM80+) | |
train.optim.lr | 5e-6 | The released relative checkpoint is already converged; the AdamW default 1e-4 listed in Important Parameters is an order of magnitude too aggressive for finetune from a converged backbone, and degrades the released checkpoint's accuracy on a short adaptation run. Use 5e-6 and a gentle scheduler (LambdaLR) when adapting to a new dataset. |
train.optim.lr_scheduler | LambdaLR | gentle warmup + decay; matches the Metric Variant Recipe |
The dataset block follows Step 2 — Pair model_type and dataset_name in SKILL.md. Use RelativeMonoDataset for generic relative data and NYUDV2Relative for raw NYU sync_depth_*.png data.
If the goal is a sanity check (1-epoch loss-decreasing, exit 0) rather than convergent finetune, use the released checkpoint directly for evaluate / inference / export instead of running train — a 1-epoch finetune at any LR is unlikely to reach the released benchmark and will measure the warmup transient, not skill correctness.
The relative variant emits scale-shift-invariant disparity (unbounded). The deploy-side evaluator runs LSQ alignment + GT disparity inversion; ensure the deploy spec sets model.model_type: RelativeDepthAnything so those paths engage (see references/tao-deploy-depth-anything-v2.md).
Metric Variant Finetuning Recipe
Checkpoint compatibility: The Metric variant only loads checkpoints trained with TAO's MetricDepthAnythingV2 model definition. Public Depth Anything v2 metric checkpoints (e.g., from the Depth Anything V2 GitHub release) use a different head attribute naming convention and will fail with Unexpected key(s) in state_dict: "model.depth_head.*" when passed to train.pretrained_model_path, evaluate.checkpoint, inference.checkpoint, or export.checkpoint. Use a TAO-trained metric checkpoint (or a TAO-converted equivalent) for all metric actions.
Metric finetuning uses a pretrained RelativeDepthAnything ViT-L backbone via model.mono_backbone.pretrained_path, with the metric head (metric_depth_head) initialized from scratch and no full PL state load (train.pretrained_model_path: ""). Because the backbone weights are already well-trained, the optimizer must step gently to preserve those features while the metric head converges; use train.optim.lr: 5e-6 (20× lower than the AdamW default 1e-4 listed in Important Parameters) with LambdaLR.
The TAO repository ships an authoritative reference spec at nvidia_tao_pytorch/cv/depth_net/experiment_specs/experiment_mono_metric.yaml; metric finetuning must mirror its optimizer settings unless the user has empirical evidence to deviate.
Required overrides for metric finetuning from a relative backbone:
| Spec key | Recommended value | Source |
|---|---|---|
train.optim.lr | 0.000005 (5e-6) | experiment_mono_metric.yaml:39 — preserves the pretrained relative backbone while the from-scratch metric head converges. The AdamW default 1e-4 is too aggressive on this backbone-pretrained setup. |
train.optim.lr_scheduler | LambdaLR | experiment_mono_metric.yaml:40 |
model.mono_backbone.pretrained_path | <RelativeDepthAnything TAO ckpt> | experiment_mono_metric.yaml:45 — backbone-only load via parse_lighting_checkpoint_to_backbone; metric head reinitializes |
train.pretrained_model_path | "" | omit a full PL state load to keep the metric head from inheriting any pre-existing head weights |
Dataset normalization block — required in train AND export specs:
dataset:
dataset_name: MonoDataset
normalize_depth: false # NYU-trained metric checkpoint default
min_depth: 0.001
max_depth: 10.0These three fields must mirror the values from the trained checkpoint's training spec in both the train action spec and the export action spec. The export pipeline reads dataset.{normalize_depth, min_depth, max_depth} to build the model graph the ONNX is traced from; omitting them makes the export silently use schema defaults that do not match the checkpoint, producing a serialized graph whose deploy-side evaluator output is non-physical even though the export action itself returns exit 0. Read the authoritative values from the checkpoint's sibling experiment.yaml.
Defaults already enforced by the TAO trainer (do not need to be set):
train.clip_grad_norm: 0.1(clip-by-value at the LightningTrainer(gradient_clip_val=..., gradient_clip_algorithm="value")level —nvidia_tao_pytorch/cv/depth_net/scripts/train.py:94-95).train.optim.warmup_steps: 20(linear LR warmup before the configured scheduler engages).train.optim.weight_decay: 1e-4(AdamW).
Precision: use fp32 for the metric finetune. The from-scratch metric head + low lr combination is fragile under reduced precision; fp32 is the safe default for this Recipe.
Sanity-run override (1-epoch loss-decreasing check on a small NYU subset):
train:
num_epochs: 1
pretrained_model_path: ""
precision: fp32
optim:
lr: 0.000005
lr_scheduler: LambdaLR
model:
model_type: MetricDepthAnything
encoder: vitl
mono_backbone:
pretrained_path: /workspace/models/<relative_ckpt>.pth
use_bn: False
use_clstoken: FalseA 1-epoch run with metric_depth_head random init will not reach released-checkpoint metric quality (that requires multi-epoch training); the recipe's purpose is functional sanity (exit 0 + loss decreasing + no NaN).
Sanity-run PASS criteria — entrypoint Execution status: PASS is not sufficient:
The trainer's Execution status: PASS only signals epoch completion — it does not check for train_loss = NaN. A from-scratch metric head with low learning rate can produce train_loss = NaN; on relative-depth smoke data, val/loss can also be NaN while finite validation accuracies such as val/d1 are still emitted. Inspect the train_loss_step values in the run log directly; PASS means only if the values are finite and decreasing.
Mitigations to try in order if NaN is observed:
Increase
dataset.train_dataset.batch_sizeto 2 or higher (the per-batch variance computation has unstable degrees-of-freedom at batch_size 1).Increase
train.optim.warmup_stepsfrom the default 20 (the LambdaLR factor at step 0 is 0, producing a no-op first update; the second step then sees a head still at random init).If both mitigations fail, fall back to reusing a pre-trained TAO metric checkpoint via
train.pretrained_model_path: <metric_ckpt>and skip the from-scratch metric-head path entirely.
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