Detect Landmarks (Triton)

@nvidia1 VersionDetect

Crops each box of a [BoundingBox] list from an Image and runs a Triton-served pose checkpoint per box, decoding heatmaps or SimCC into per-detection keypoints emitted as [[Landmark]].

How it fits

Typical backends

Person pose where both detector and pose estimator are Triton-served, keeping the whole vision stage on one inference server.

Body-part routing where a YOLO detector supplies the boxes and keypoints feed a part locator for a downstream crop.

Caveats

CostOne inference call runs per input bounding box, so with N detections the runtime cost scales linearly as N times the per-pose latency.
I/O contractOutput keypoint lists align with input [BoundingBox] order, and an empty box list produces empty output. Coordinates are returned in input-image space, not box-local, rescaled back using the configured model input size and each box's geometry. On the flat [Landmark] arm only the single highest-scoring detection survives.
Parameter interactionsimcc selects coordinate-classification decoding versus heatmap decoding; a value that disagrees with the served network's actual head silently produces wrong coordinates.
Hard constraintoutput_keypoints must equal the network's keypoint count exactly, or the output tensor is truncated or over-read. Tensor names, shapes, normalization (mean, std, rescale_factor), color_model, and change_channel_order must match the served signature.
Hard constraintMisconfiguration against the served model signature is not validated at startup; wrong shape, decoder, channel order, or normalization settings silently yield empty output or garbage coordinates rather than an error.
LimitationAll configuration keys are captured once at startup and are not mutable at runtime; changing any requires a redeploy.
CompatibilityA Triton inference server hosting the pose checkpoint is required; this component cannot run standalone.

Versions

fa3bcb8flatestdefault
Automated release
6/25/2026