cdf-defect-image-generation

Files (14)

• BENCHMARK.md
• SKILL.md
• openai.yaml · agents/
• EVAL.md · evals/
• evals.json · evals/
• test_payload.py · evals/
• airflow-direct-api.md · references/
• outputs.md · references/
• payload-contract.md · references/
• setup-and-preflight.md · references/
• troubleshooting.md · references/
• payload.py · scripts/
• skill-card.md
• skill.oms.sig

SKILL.md (first lines)

# CDF Orchestration — SMT Defect Image Generation

Run `defect_image_generation_smt_dag_k8s`: CDF Simulation renders PCB components,
CDF Augmentation turns the renders into realistic clean (golden) images, and
CDF AnomalyGen adds texture defects. Simulation can also render pose defects
(shift, tombstone, sideflip). One DAG serves every mode; `pipeline_mode` selects
which stages run.

## Requirements

Execution needs an authorized Kubernetes connection, a reachable Airflow 3
controller with the DIG DAG loaded, and storage and model access for the chosen
mode. The payload checker needs a trusted CDF Orchestration checkout and its
Airflow Python environment. Explaining the workflow or drafting JSON needs neither.

Execution readiness also requires the companion script
`skills/cdf-orchestration-preflight/scripts/storage_check.py` in the product
checkout. If it is unavailable, report the missing dependency as a readiness
blocker; do not skip the storage mapping check.

In that checkout, the payload contract is defined by
`airflow/dags/workflows/defect_image_generation_dag/callables/smt/models.py` and
`airflow/dags/workflows/defect_image_generation_dag/callables/smt/config_generation.py`.
The component templates that payload overrides merge into are in
`airflow/dags/workflows/defect_image_generation_dag/configs/smt/`.

## Available scripts

| Script | Purpose |
|---|---|
| `scripts/payload.py` | Check a payload with the DAG's own model and compiler, then print job counts, output paths and effective AnomalyGen staging. Submits nothing and accesses no storage or cluster. |

## Instructions

### 1. Resolve the requested operation and mode

| User intent | `pipeline_mode` | Required stages |
|---|---|---|
| Render PCB components only | `simulation` | Simulation |
| Good (golden) component images from a board scene | `sim2real` | Simulation → image-edit |
| Pose defects (shift, tombstone, sideflip) from a board scene | `sim2real`, with a pose operation in the simulation override | Simulation → image-edit |
| Texture defects (bridge, excess solder, missing) from a board scene | `full` | Simulation → image-edit → AnomalyGen |
| Texture defects on real or prepared clean images | `defect` | AnomalyGen |

Requests that start from a board USD are sometimes called "Day 0", and requests
that start from real or prepared images "Day 1".
[payload-contract.md](references/payload-contract.md) shows how to select the
components a request names, set counts and coverage, and add pose defects.

For a payload-only request, prepare and check it locally, and put the checked
payload JSON in your final answer; do not launch a run.
For status or results, use the named existing run instead of building a payload.
For manual UI entry, set up UI access (step 5) and report the URL; the user
triggers the run.

### 2. Gather only the inputs needed for that mode

Reuse values already supplied in this task and ask for anything missing. Never
invent a location, endpoint or model name.

| Applies to | Inputs |
|---|---|
| All modes | Writable `output_directory`; mode |
| `simulation`, `sim2real`, `full` | `input_scene`; golden configuration IDs and component/camera/render choices |
| `sim2real`, `full` | Internal image-edit replica count, or external image-edit URL and optional served model |
| Pose defects | Operation, magnitudes, and a `count` or `ratio` of components to move |
| `full`, `defect` | Defect configuration IDs, `class+defect` counts, shared assets, recipe and checkpoint locations, AMG model/endpoint settings |
| `full` | Exact `component_type` → AnomalyGen class mapping for every selected type |
| `defect` | Prepared `<class>/clean_image/` dataset root, included alongside shared assets in `staging.fetch.input` |

Requests often name components by kind ("the passives") or by part number
("0603_H100"); [selecting components](references/payload-contract.md#selecting-components)
maps those to selectors. The simulation template is a preset for the Artix sample
board. Another board needs its own scene settings and component selectors, not
just a different ZIP path; see
[adapting to another board](references/payload-contract.md#adapting-to-another-board).
Upload local inputs only to the user's chosen destination, preserving the scene
assets or class-folder hierarchy.

### 3. Build and check the payload

Read [payload-contract.md](references/payload-contract.md) for collections,
examples, merge rules and per-mode requirements, then build plain JSON with
`api_version: "1.0"`. Keep run-specific asset locations in payload overrides so
the controller does not need a rebuild.

Each component override is handed to a component that validates it against its
own schema. Before writing or changing one, read that component's documentation
for the version the SMT manifest deploys, and do not invent keys or values. The
links point to each component's public GitHub repository, pinned to a commit
whose documentation matches the deployed images; a component skill installed
separately may describe a different version.

| Override | Component image in the SMT manifest | Documentation |
|---|---|---|
| `image_generation` | `nvcr.io/nvidia/cdf-simulation:1.2.0` | [`cdf-simulation` skill][simulation-skill]; [YAML JobConfig reference][simulation-config] |
| `augmentation` | `nvcr.io/nvidia/cdf-augmentation:1.2.0` | [`cdf-augmentation` skill][augmentation-skill]: [configuration schema][augmentation-schema] and [captioning strategies][augmentation-captions] |
| `anomaly_generation` | `nvcr.io/nvidia/cdf-anomalygen:1.2.0` | [`cdf-anomalygen` skill][anomalygen-skill]: [inputs][anomalygen-inputs] and [agentic mask generation][anomalygen-masks]; [`run_pipeline` config reference][anomalygen-config] |

[simulation-skill]: https://github.com/NVIDIA/cdf-simulation/tree/a0af274e6352347a1979be40036efdd33b447272/skills/cdf-simulation
[simulation-config]: https://github.com/NVIDIA/cdf-simulation/blob/a0af274e6352347a1979be40036efdd33b447272/pcb_aoi/config/README.md
[augmentation-skill]: https://github.com/NVIDIA/cdf-augmentation/tree/73c861c43a4952b6060c87265bf39f4abc48199a/skills/cdf-augmentation
[augmentation-schema]: https://github.com/NVIDIA/cdf-augmentation/blob/73c861c43a4952b6060c87265bf39f4abc48199a/skills/cdf-augmentation/references/configuration-schema.md
[augmentation-captions]: https://github.com/NVIDIA/cdf-augmentation/blob/73c861c43a4952b6060c87265bf39f4abc48199a/skills/cdf-augmentation/references/captioning-strategy-guide.md
[anomalygen-skill]: https://github.com/NVIDIA/cdf-anomalygen/tree/63c888cb479e22f6abe343421eaba2ae1847b8f5/skills/cdf-anomalygen
[anomalygen-inputs]: https://github.com/NVIDIA/cdf-anomalygen/blob/63c888cb479e22f6abe343421eaba2ae1847b8f5/skills/cdf-anomalygen/references/inputs.md
[anomalygen-masks]: https://github.com/NVIDIA/cdf-anomalygen/blob/63c888cb479e22f6abe343421eaba2ae1847b8f5/skills/cdf-anomalygen/references/agentic-mask-generation.md
[anomalygen-config]: https://github.com/NVIDIA/cdf-anomalygen/blob/63c888cb479e22f6abe343421eaba2ae1847b8f5/docs/pipeline/config.md

The workflow sets some component keys itself; the contract lists them. Check the
payload with the checkout's Airflow Python environment. The controller image has
these dependencies but the host does not, so create the environment once in the
checkout with `uv` (0.9+), then run the checker with its interpreter:

```bash
REPO_ROOT=/path/to/cdf-orchestration
(cd "$REPO_ROOT" && uv sync --frozen --all-packages --inexact)   # once per checkout
"$REPO_ROOT/.venv/bin/python" /path/to/skill/scripts/payload.py \
  --repo-root "$REPO_ROOT" \

From NVIDIA/skills, CC-BY-4.0 AND Apache-2.0.

More from NVIDIA/skills