Sampler_DisPose
One image, one pose video, a whole new person moving
- pipe
- ref_video
- ref_image
- latent
- ref_image
- poses
This is the node you actually came for. The loader assembles six models into a pipeline, the decoder turns the result into video - but Sampler_DisPose is where a still photo of a person becomes a video of that same person dancing or gesturing exactly like someone in a completely different clip. Give it a reference image for who, a driving video for how, and it produces the latent that becomes your output.
How it works - why DisPose isn't just "ControlNet with extra steps"
The ICLR 2025 DisPose paper is built on one idea: pose guidance for human animation should be disentangled into two signals instead of crammed into a single skeleton image. Watch the sampler's run and you can see it happen:
- DWPose extracts keypoints - body, face, and hands - from every frame of the driving video, then rescales them so the driver's proportions match your reference image's pose.
- A dense motion field is computed - the CMP correspondence model turns those sparse keypoints into smooth optical flow the ControlNet can use.
- Keypoint correspondence comes from SD 1.5 - DIFT features match points between your reference image and each video frame, so the model knows "this wrist in frame 3 maps to that wrist in your photo."
- Denoising runs in sliding-window tiles - the SVD XT 1.1 UNet, guided by the DisPose ControlNet and MimicMotion's pose net, generates the clip tile by tile, overlapping windows so motion stays continuous.
That windowing is why tile_size and tile_overlap exist - and why long clips are a VRAM juggling act rather than one huge sample.
The inputs that matter
Two are non-negotiable and define the whole job:
ref_video(IMAGE) - the driving video. Load it with VideoHelperSuite (VHS_LoadVideo), which the tooltip recommends; the pack's example workflow uses exactly that. It can also be concatenated frames.ref_image(IMAGE) - one image of the person you want to animate, keeping everything but the pose. LoadImage is fine.
Then the settings you'll actually tune:
resolution(default 576, range 256–640) - the short edge. Here's the trap: the README says flat-out that 576 is the only verified resolution, and other values "work very poorly." The aspect ratio is hardcoded to 9:16 - you get 576×1024, 1024×576, or 576×576 depending on your source image's orientation. Don't fight it; run 576.tile_size(default 16) - larger = smoother motion, more VRAM. The original demo used 16 with overlap 6.tile_overlap(default 6) - larger = better motion continuity across tiles, more compute time, same VRAM.cpu_offload(none/model/sequential) - the README's OOM ladder: trymodelfirst (saves VRAM with little slowdown), escalate tosequential(aggressive, slower). If time is no object, the README suggests just runningsequentialand crankingtile_sizeuntil you hit your VRAM ceiling.seed(default 42) - set it and usecontrol_after_generation: fixedif you want reproducibility.noise_aug_strength(default 0) - higher = better motion quality but less faithful toref_image. The classic likeness-vs-life tradeoff.num_inference_steps(25),min_guidance_scale/max_guidance_scale(2 / 2) - standard diffusion knobs; the defaults are sensible. Leave them alone until you know why you're touching them.
The three outputs
latent(LATENT) - the must-have. This is the one that goes intoDecoder_DisPose; without it you have nothing.ref_image(IMAGE) - your reference, cropped and normalized the way DisPose sees it. The README calls it "useless" for the result but great for debugging.poses(IMAGE) - the visualized keypoint video. Also debug material. If you're wondering "why is it moving like that," look here first.
Installing the pack
cd ComfyUI/custom_nodes
git clone https://github.com/bombax-xiaoice/ComfyUI-DisPose
cd ComfyUI-DisPose && pip install -r requirements.txt
ComfyUI Manager: search "ComfyUI-DisPose". Model downloads are handled by the loader on first run - tens of GB across SVD XT 1.1, SD 1.5, DisPose, MimicMotion, DWPose, and CMP, so the first execute sits quietly for a while.
Where people get burned
- Faces. DisPose's base models are SD 1.5 and SVD XT 1.1 - years old by now. The README's own assessment is refreshingly blunt: face, hair, clothes, and physics defects are "still here and there." If face identity matters, plan a repaint pass (FaceDetailer per frame, or a LORA + ControlNet pass) - the community hit the same wall with the underlying MimicMotion, where mushy faces were the top complaint.
- OOM at 576 - work the
cpu_offloadladder before touching resolution. - Expecting more than 576 gives. The quality ceiling is real, but that's a model limitation, not a settings failure.
Set your two inputs, leave 576, and let it run. The first time your reference photo dances exactly like the driving video, you'll forget all of this.
Inputs (12)
| Name | Type | Default | Description |
|---|---|---|---|
| pipe | DisPosePipeline | output from (Down)Loader_DisPose | |
| ref_video | IMAGE | video or concatenated images as reference poses, recommend to use VideoHelperSuite | |
| ref_image | IMAGE | one image as driving image, keeping everything but pose | |
| resolution | INT | 576256–640 | shorter edge pixels, aspect ratio is 16/9 |
| seed | INT | 42 | set control_after_generation as fixed to make result reproducible |
| tile_size | INT | 161–640 | larger size makes better motion quality but requires more vram |
| tile_overlap | INT | 60–64 | larger overlap makes better motion quality but increase processing time, vram remains the same |
| num_inference_steps | INT | 251–100 | — |
| noise_aug_strength | FLOAT | 0.000–1 | larger value makes better motion quality but less alike to ref_image |
| min_guidance_scale | FLOAT | 2.00.1–10 | — |
| max_guidance_scale | FLOAT | 2.00.1–10 | — |
| cpu_offload | COMBO | model | sequence is slowest but consume the least VRAM, model also spare some vram and slightly slower than none |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| latent | LATENT | — |
| ref_image | IMAGE | — |
| poses | IMAGE | — |