/cdf-defect-image-generation

name: cdf-defect-image-generation
description: Generate synthetic PCB inspection images on Kubernetes with the SMT Defect Image Generation (DIG) DAG in CDF Orchestration. The DAG renders components in simulation, turns the renders into realistic golden images (sim2real), and uses AnomalyGen to add texture defects such as solder bridges, excess solder or missing components. Simulation can also render shift, tombstone and sideflip pose defects. Use it to build DIG payloads, pick a pipeline mode (full, simulation, sim2real or defect-only), check GPU readiness, follow a run, and match each defect image to its golden and simulated source. Not for running Simulation, Augmentation or AnomalyGen on their own.
version: "1.0.4"
license: CC-BY-4.0 AND Apache-2.0
metadata:
  owner: NVIDIA
  service: cosmos-data-factory
  version: "1.0.4"
  reviewed: "2026-10-20"
  author: NVIDIA
  tags:
    - physical-ai
    - cdf-orchestration
    - defect-image-generation
    - smt

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 separat