ComfyUI Node

ControlNext GetPoses

Turning your footage into the skeleton frames ControlNeXt actually wants (ControlNext GetPoses)

By kijai·Created 2 years ago·Updated 2 years ago· 189
ControlNext GetPoses
  • ref_image
  • pose_images
  • poses_with_ref
  • pose_images
include_bodytrue
include_handtrue
include_facetrue

Before ControlNeXt-SVD can animate anything, it needs pose skeleton frames - the stick-figure drawings of a body that tell the video model what motion to produce. ControlNext GetPoses is the node that makes them, and it's the one piece of this pack you use no matter which path you're on. Both the diffusers wrapper and the native ControlNext SVD Apply workflow start here, and the example workflows load your source video through it before anything else.

What it does

It runs DWPose - the improved pose detector the ControlNet community moved to for better hand and body tracking than classic OpenPose - over your input frames and draws stick figures. Two inputs, one job:

  • pose_images - your source frames, one IMAGE batch per frame of the clip you want to animate. If you're copying a dance from footage, this is where the video frames go.
  • ref_image - a single still of the character. It must match the resolution of pose_images or the node asserts.

The three booleans - include_body, include_hand, include_face (all default true) - pick which parts of the pose get drawn. If hands keep coming out mangled on a long shot, dropping include_hand is a legitimate "give the model less to obey" move, because ControlNeXt-SVD's hand fidelity was never its strong suit.

Two outputs:

  • poses_with_ref - the stick-figure batch with the reference image's own pose prepended as the first frame. That's your ready-to-use condition.
  • pose_images - just the pose frames, no reference frame. Feed this one to ControlNext Sampler or ControlNext SVD Apply when you want to control which frames count as the "video" - and remember the ref pose frame is not one of them.

How it works

Under the hood it loads two torchscript models - YOLOX for person detection and a DWPose batch-5 model - downloads them from HuggingFace on first run into the pack's models/DWPose/ folder. Then comes the part that's easy to miss and genuinely clever: it detects the reference person's keypoints, computes a least-squares linear rescale mapping from the source video's detected bodies onto the reference body, and applies that scaling to every frame's keypoints before drawing. That's why the output skeletons track the shape of your reference character instead of the raw size of the source footage - you can retarget a tall dancer's motion onto a smaller character and the skeleton fits.

Installing it

Same pack, same install - ComfyUI Manager (search "ComfyUI-ControlNeXt-SVD") or:

cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-ControlNeXt-SVD
# restart ComfyUI

First run downloads the YOLOX and DWPose torchscript models (a few hundred MB) into the pack's models/DWPose/ directory. No extra manual steps beyond that. The node keeps the detectors resident in VRAM between runs and offloads them after processing, so the second run is faster than the first.

Common issues

  • "ref_image and pose_images must have the same resolution" - a hard assert. Resize one of them (the example workflows use ImageScale or KJNodes' ImageResizeKJ) before the node.
  • Slow first run / model download - the torchscript models grab on demand from hr16/yolox-onnx and hr16/DWPose-TorchScript-BatchSize5. If it stalls, it's a network issue, not a config one; re-run and it picks up where it left off.
  • Nobody detected in frames - very dark or highly stylized footage can make detection miss. The node draws an empty skeleton rather than crashing, which you'll notice as output that ignores your poses.
CategoryControlNextWrapper

Inputs (5)

NameTypeDefaultDescription
ref_imageIMAGE
pose_imagesIMAGE
include_bodyBOOLEANtrue
include_handBOOLEANtrue
include_faceBOOLEANtrue

Outputs (2)

NameTypeDescription
poses_with_refIMAGE
pose_imagesIMAGE