DWPose Estimator

DWPose is the pose detector people switched to because OpenPose's hands are bad - better finger detection, whole-body output, and it has been the default in comfyui_controlnet_aux for years. It's also slow, and "slow" is the number one complaint you'll find about it in the wild, usually from someone trying to pose a whole video.

UC_DWPoseEstimator is silveroxides' reimplementation: YOLOX-L for person detection, RTMPose for the 133 whole-body keypoints, run eagerly in PyTorch, batched, with an optional temporal filter for video. Detection and pose crops go through separate batches, and partial batches aren't padded, so the last chunk of a clip doesn't pay for a full batch of empty frames.

How it works

The detector (a converted yolox_l TorchScript checkpoint) runs on each frame at a fixed 640 square, which is why resolution doesn't make it "see more detail" - it only changes the image you get back. Detected person boxes are NMS'd, expanded to crops, and each crop goes through the RTMPose model at 288x384 (the dwpose_ucoco_384 weights), which returns SimCC coordinate distributions that get decoded to 133 keypoints.

The two thresholds do different jobs. detection_threshold (0.45) decides whether a person exists at all; keypoint_threshold (0.45) decides whether an individual body, hand or face point survives. nms_threshold (0.45) is the duplicate-box cleanup - lower it and you can lose people standing close together, raise it and you'll get the same person twice.

One important difference from the OpenPose node in the same pack: detect_hand, detect_body and detect_face are drawing toggles only here. Turning off hands makes the map prettier, not the run faster. Hand and face keypoints still come out on pose_keypoint. Same for hands in the OpenPose node, where the toggle does skip the model - don't assume the two behave alike.

Inputs, outputs, wiring

Beyond the above: image (a batch, or consecutive frames for the temporal options), resolution (0 keeps your dimensions, otherwise the shortest edge), batch_size (5, your VRAM dial), and scale_stick_for_xinsr_cn, which thickens the drawn body lines at larger sizes for Xinsir-style maps. Drawing only; joint coordinates don't move.

The six temporal options run the same as the pack's other pose nodes: temporal_filter off by default, temporal_radius 2, temporal_min_support 2, temporal_max_distance 0.1 of the person's box diagonal, temporal_match_iou 0.3. It deletes joints that neighbouring frames can't vouch for and keeps the person entries. It's flicker removal, not interpolation - nothing gets invented, and pruning spans your batch chunks. Turn it off for unrelated stills.

Outputs: image (the pose map, in order - into your pose ControlNet), pose_keypoint (OpenPose-format, thresholded and filtered), and Pose Overlay Mask, which is white on drawn lines and points so you can composite the map over the original footage.

Install

Manager → search "ComfyUI-UtilsCollection", or:

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

Two models, downloaded on first execution into ComfyUI/models/controlnet/preprocessors (flat filenames, even though the HF repo nests them): dwpose_yolox_l.safetensors and dwpose_ucoco_384.safetensors, from silveroxides/ComfyUI-UtilsCollection-Models. No ONNX Runtime, no MMPose, no TorchScript at runtime - the pack converts the original .pth/TorchScript sources to safetensors and validates keys, shapes, dtypes and values before shipping them. The honest caveat from the README: verified conversion, unverified prediction parity and unmeasured speed. If you're squeezing every percent, benchmark it against the aux preprocessor you're replacing.

Troubleshooting

The pack imports kornia when it loads and kornia is not in its requirements.txt. If another pack hasn't already pulled it in, the entire pack fails to import and every node from it goes missing - pip install kornia in ComfyUI's Python environment fixes it.

If detection is failing on dark clothing, backlit shots or motion blur, detection_threshold at 0.45 is a reasonable default but YOLOX has never loved those frames; drop it to 0.3 first before you go rebuilding the pipeline.

And if your downstream ControlNet isn't a DWPose/OpenPose-trained one, remember you're feeding it a skeleton - pose conditioning is spatial, so the prompt still has to describe the subject.