[Inference.Core] DWPose Estimator

If you've done any pose-conditioned ControlNet work, you've used DWPose whether you knew the name or not - it's what "OpenPose preprocessor" quietly became once people noticed the classic detector kept mangling hands. DWPose swapped in a better two-stage pipeline and better hand keypoints, and it's now the default most workflows reach for over the original OpenPose. This particular copy ships from LykosAI - the team behind Stability Matrix, the app a lot of people use to install and manage ComfyUI in the first place. The Inference_Core_ prefix on the class name is the tell: this pack is their fork of the classic comfyui_controlnet_aux preprocessor collection, renamed so it doesn't collide with the original if you happen to have both installed.

How it works

DWPose runs in two stages. First a bounding-box detector (YOLOX, by default) finds every person in the frame. Then a pose estimator - a distilled RTMPose model trained on the COCO-WholeBody keypoint set - places keypoints for each detected person: body joints, hand joints, and facial landmarks. That two-stage split, detect-then-estimate, is exactly what makes it better at hands than the older single-network OpenPose: a dedicated hand-focused pass on a cropped region does a lot better than one network trying to cover the whole body at once.

The inputs and outputs that matter

• image - the only required input. Give it a photo or render with people in it.
• detect_hand / detect_body / detect_face - enable or disable each keypoint group independently. If you only want body pose and don't care about mangled hand skeletons throwing off the conditioning, turn hands off.
• resolution (default 512) - the working resolution for detection. Match it roughly to your generation size.
• bbox_detector and pose_estimator - pick the model variant. Both offer a TorchScript option and one or more ONNX options; this choice quietly decides your speed (more on that below).

Two outputs: IMAGE, the rendered skeleton you feed straight into a ControlNet Apply node, and POSE_KEYPOINT, the raw keypoint data as structured JSON - useful if you want to save it (pair with this pack's Save Pose Keypoints node), edit it, or drive some other pose-consuming tool downstream instead of just rendering a picture.

How to install it

ComfyUI Manager: search ComfyUI-Inference-Core-Nodes, install, restart. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/LykosAI/ComfyUI-Inference-Core-Nodes

then either run install.py with ComfyUI's own Python, or pick the pip extra matching your hardware - pip install -e .[cuda12], .[cuda], .[rocm], .[directml], or .[cpu] - which is what actually pulls in a working, accelerated onnxruntime build instead of leaving you with whatever generic one pip resolves to. Restart ComfyUI. The bbox detector and pose estimator weights download from Hugging Face automatically the first time you actually run the node, so the first execution is slower and needs network access.

Common issues & troubleshooting

The single most common DWPose complaint, confirmed by a stream of people hitting the exact same wall on Reddit: a console warning that onnxruntime not found or doesn't come with acceleration providers, followed by DWPose running painfully slowly. This happens because onnxruntime-gpu's CUDA requirements don't match your installed CUDA/PyTorch version, so it silently falls back to CPU. Two ways out: pick the .torchscript.pt variants for both bbox_detector and pose_estimator instead of the .onnx ones (TorchScript doesn't need onnxruntime at all and is fast out of the box), or actually match your onnxruntime-gpu install to your CUDA version by running the install with the right extras flag above.

Second real one: if the whole pack fails to import (ComfyUI Manager shows it "conflicted" or the console shows a module error), that's usually a class-name or dependency collision with another controlnet-preprocessor pack you already have installed - several users report exactly this on Mac in particular, where one of the pack's dependencies pulls in a Windows-only path. Worth checking before you go down a rabbit hole assuming your own setup is broken.

Third, ordinary: detection quality depends on a clean, mostly-unobstructed view of the person. Crowded frames, heavy occlusion, or extreme crops will give you a broken skeleton, and a broken skeleton makes a broken pose ControlNet result - garbage in, garbage out applies here more than almost anywhere else in the pack.