Overlay Pose Keypoints

Here's a node that does no inference at all, and that's the point. UC_OverlayPoseKeypoints takes keypoints you already extracted - from this pack's OpenPose or DWPose estimators - and paints them over whatever images you hand it. No model load, no download, no VRAM.

Two very practical uses. First, QA: overlay the extracted skeleton on the source footage and scrub through it, so you can see exactly which joints the temporal filter pruned or the thresholds dropped, instead of guessing from a black pose map. Second, compositing: your original clip with the skeleton drawn on top is a genuinely useful thing to have for previews and for debug renders when the generated output looks wrong and you need to know whether it was the pose or the sampler.

How it works

The keypoints arrive as POSE_KEYPOINT documents with normalized coordinates, and the overlay rescales them to the background's dimensions. So the poses and the images do not need to be the same size - but they do need to line up in time. pose_keypoint accepts either a single pose frame, which is reused on every image (nice for a fixed pose template dropped over a batch), or exactly one pose frame per image. Anything else is an error, not a silent best-effort: the node checks the count and refuses.

Drawing uses the same renderer as the estimators: body limbs and joints, hand fingers, face landmarks, with the standard colour scheme. What it doesn't do is invent joints. If a point was pruned by the temporal filter or fell under the threshold in the estimator, it stays absent here. That's a feature when you're debugging, and a mild annoyance when you wanted a clean pretty skeleton.

The inputs you'll care about

image is the background - an image or an ordered video-frame batch. The output keeps its dimensions, frame order and alpha channel, so RGBA footage survives the trip.

pose_keypoint is the keypoints. Feed it human OpenPose/DWPose documents. Animal keypoints will not work - the node raises an explicit error on AP10K documents, because joint indices for a quadruped don't mean anything in a human renderer.

draw_body, draw_hands and draw_face all default on and are pure visibility switches; they don't alter the keypoints you passed in. Missing or filtered joints stay missing regardless.

opacity (0–1, default 1) is the blend against the background. 0 leaves the image untouched, 1 fully covers the drawn pixels. For QA work I'd run about 0.6 - you want to see the skeleton and the person it's supposed to be tracking.

drawing_scale (0.1–10, default 1) multiplies line thickness and point radius without moving anything. Bump it for a 4K frame where the default lines are invisible slivers.

Outputs

image - your background with the skeleton on top, in order. And Pose Overlay Mask, which is the drawing coverage multiplied by opacity: black outside the visible pose, same dimensions and frame order as the background. That mask is the interesting second output. Multiply it against the pose map, or use it as an inverted mask to keep the original pixels only where the skeleton isn't - the node gives you the alpha you need to composite the two yourself in either direction.

Install

Manager → search "ComfyUI-UtilsCollection", or:

cd ComfyUI/custom_nodes
git clone https://github.com/silveroxides/ComfyUI-UtilsCollection
# restart ComfyUI

No models, no downloads, nothing to place on disk - this node is pure drawing code. It does share the pack's install fate, though: the collection imports kornia at load time and never lists it in requirements.txt. If you installed it for this one node and nothing from the pack showed up in the node list, pip install kornia is the fix.

Troubleshooting

If the overlay looks shifted, check the source images against the ones you posed. Keypoints are normalized to the frame the estimator processed, so if you posed a resized copy and are now overlaying on the original crop or a different aspect ratio, the skeleton will land somewhere plausible and wrong. Same-resolution, same-crop is the safe path.

If the drawing is empty, your keypoints are probably empty too - the estimator's keypoint_threshold or a temporal_filter run is a more likely culprit than this node, which draws faithfully whatever it's given. Wire the estimator's info-adjacent outputs or just look at its Pose Overlay Mask to confirm there's something to draw before you debug here.