Vss Generate Video Calibration

Purpose

Run AutoMagicCalib end-to-end on local files, RTSP streams, or the bundled sample dataset and (when needed) deploy the AMC microservice.

Instructions

Follow the routing tables and step-by-step workflows below. Each section that ends in workflow, quick start, or flow is intended to be executed top-to-bottom. Detailed reference material lives in references/; load only the reference needed for the selected input mode.

Examples

Worked end-to-end examples are kept under evals/ (each *.json manifest contains a runnable scenario) and inline in the per-workflow curl blocks below. Run a Tier-3 evaluation with nv-base validate <this-skill-dir> --agent-eval to replay them.

Limitations

• Requires the matching VSS profile / microservice to be deployed and reachable from the caller.
• NGC-hosted models and NIMs may be subject to rate-limits, GPU memory requirements, and license restrictions.
• Concurrency, GPU memory, and storage limits depend on the host hardware and the profile's compose file.

Troubleshooting

• Error: REST call returns connection refused. Cause: target microservice not running. Solution: probe /docs or /health; redeploy via vss-deploy-profile or the matching vss-deploy-* skill.
• Error: HTTP 401/403 from NGC pulls. Cause: missing/expired NGC_CLI_API_KEY. Solution: docker login nvcr.io and re-export the key before retrying.
• Error: container OOM or model fails to load. Cause: insufficient GPU memory for the selected profile. Solution: switch to a smaller variant or free GPUs via docker compose down.

VSS Generate Video Calibration

Run AutoMagicCalib over one of three input sources and drive the calibration through the microservice REST API. The input-resolution work differs per source; everything from verify_project onward is identical and lives in this file. Pick the right input-mode reference and pair it with the Shared Calibration Tail below.

Shared helper references are loaded only when needed:

• Read references/common-steps.md when a mode reference needs the shared create_project, video-upload, or handoff snippets.
• Read references/calibration-tail.md when you need the reusable Python implementation of the verify → calibrate → poll → results tail.

Input Routing

Match the user's request to a mode, then load that mode's reference for input collection, mode-specific API calls, and the full Python script.

Disambiguation rule: if the user is asking to launch / deploy / set up AMC (no calibration verb) → deploy. If they provide RTSP URLs → rtsp. If they mention local files / a videos directory → videos. If they ask to verify install or test the bundled sample → sample-dataset. Combined intents (e.g. "launch AMC and calibrate my videos") → walk deploy first, then the calibration mode. When ambiguous, ask via AskUserQuestion.

Prerequisites (shared across calibration modes)

• AMC microservice + UI running. If not, walk references/deploy-auto-calibration-service.md first.
• Microservice reachable at http://<HOST_IP>:${VSS_AUTO_CALIBRATION_PORT:-8010}/v1/ready → {"code":0,...}.
• Projects directory writable by the container user. If you didn't just deploy (so Step 5 of the deploy reference hasn't run), confirm the write test in references/deploy-auto-calibration-service.md § Step 5 — otherwise the first create_project returns [Errno 13] Permission denied.
• Python 3 with requests installed (each input-mode reference includes a self-healing venv fallback for direct runs).

Mode-specific prerequisites (VIOS for rtsp, sample zip for sample-dataset) live in the respective references.

Shared Calibration Tail

The verify → calibrate → poll → results sequence is identical regardless of input mode. After the mode-specific reference has uploaded videos / ingested RTSP clips / uploaded the bundled sample, run this tail. Use references/calibration-tail.md for the shared Python snippet.

Step A — Verify Project

POST /v1/verify_project/<project_id>

Response: {"project_state": "READY"} — must be READY before calibrating. If not READY, re-check that videos + alignment + layout are present (either via API or via UI manual alignment).

Step B — Start Calibration

Confirm the plan before calibrating. Whether the settings file and detector were auto-detected or asked, present a short summary and confirm via AskUserQuestion before the POST /calibrate. The resolved values are the defaults, so confirming is one click — but the user can switch the detector or skip an auto-detected settings file. Summarize:

• Detector — resnet or transformer (the value to be sent).
• Calibration settings — the file being applied (path), or default parameters (with the option to tune them in the UI first — see below).
• Optional overrides — ground-truth zip and focal lengths, if any.

The sample-dataset install-check run uses a fixed resnet and can proceed without this confirmation.

POST /v1/calibrate/<project_id>
Content-Type: application/json

{"detector_type": "resnet"}   # or "transformer"

detector_type is a separate /calibrate parameter — not consumed by /v1/config/<id>. If the user provided a calibration settings file, parse it for "detector" / "detector_type" and use that value. If the file doesn't specify one, the default (resnet) is the value shown in the confirmation above — the user can switch it there before calibrating. If there's no settings file at all, ask the user via AskUserQuestion:

• resnet — default, fast.
• transformer — slower, better under heavy occlusion.

UI Step 3 (Parameters) does NOT cover detector choice; never assume the user picked one in the UI.

Also when there's no settings file, ask whether to tune the calibration parameters first (AskUserQuestion):

• Proceed with the default parameters — well-suited to typical warehouse scenes; recommended unless the user has specific tuning in mind.
• Adjust parameters in the UI first — open the project, go to Step 3: Parameters, change values, and click Save; then continue.

Wait for the user's choice — and, if they choose to tune, for them to confirm they've Saved — before calling /calibrate.

Step C — Poll for Completion

GET /v1/get_project_info/<project_id>

Poll every 10 s. project_info.project_state:

When calibration starts, surface the project ID, the UI URL (http://<HOST_IP>:${VSS_AUTO_CALIBRATION_UI_PORT:-5000}), and the log endpoint so the user can watch progress while the run proceeds. During RUNNING, emit a progress line at least once a minute with elapsed time so a long run doesn't look stalled. On ERROR, fetch and show the last lines of GET /v1/amc/calibrate/<id>/log before stopping. Live logs can also be streamed via GET /v1/calibrate/<project_id>/log/<type>/stream.

Typical time: 10–60 min (your-own videos), 10–30 min (bundled sample).

Step D — Results

GET /v1/get_project_info/<project_id>                    # project state
GET /v1/result/<project_id>/evaluation_statistics        # only if GT uploaded
GET /v1/result/<project_id>/overlay_image                # visual overlay (PNG)
GET /v1/amc/calibrate/<project_id>/log                   # calibration log

Evaluation response includes Average L2 distance(m) and Average reprojection error 0(px). Evaluation metrics are produced only when a ground-truth GT.zip was uploaded — a missing evaluation_statistics result is normal otherwise and is not the end of result reporting.

After COMPLETED, always give the user a way to review the result for that exact project, regardless of whether metrics exist:

• UI — http://<HOST_IP>:${VSS_AUTO_CALIBRATION_UI_PORT:-5000}; open the project, then the Results page to view the overlay.
• Overlay image on disk — ${VSS_APPS_DIR}/services/auto-calibration/projects/project_<id>/output/multi_view_results/BA_output/results_ba_scaled_world/overlay_img_*.png (single-camera projects use output/single_view_results/cam_00/verification_map_overlay.png).
• Project files — ${VSS_APPS_DIR}/services/auto-calibration/projects/project_<id>/.