Magic Animate
The Node That Copies a Dance Onto Your Photo — Locally, No API Key
- magic_animate_model
- image
- pose_video
- IMAGE
The name oversells it slightly and undersells it at the same time. MagicAnimate won't make anything from nothing - it needs a still image of one person and a driving video, and then it does the party trick: your photo's subject performs the driving video's motion, and their identity sticks. No API, no key, no cloud credits. It all happens on your own GPU, which is exactly why this node made the rounds when it shipped in December 2023.
This is the second half of the ComfyUI-MagicAnimate pack, and it's the half that actually generates. The companion MagicAnimateModelLoader builds the ~15GB pipeline; this node runs it. Think of it as identity preservation (the appearance encoder) plus motion transfer (the DensePose ControlNet) plus temporal coherence (the motion module in the SD 1.5 UNet) fused into one shot - same era and family as AnimateDiff, but aimed at "drive one person's pose" rather than "make anything move."
The inputs, and the one that's lying to you
- magic_animate_model - the
MAGIC_ANIMATE_MODELbundle from the loader. Only that. - image - your source photo, and exactly one of them: the code asserts
image.shape[0] == 1. Feeding a batch crashes it. - pose_video - the driving frames as an
IMAGEbatch. This is the input everyone gets wrong. It must be DensePose frames, not regular RGB video. The author's own release notes say it flat out: the video input must be in DensePose format. If you feed a normal clip you'll get melted, ghosting bodies that half-obey the motion. Getting DensePose frames is an upstream step - a preprocessing workflow (the README's linked example does this) - because this node doesn't extract them for you. - seed - a number. Same seed, same result. Nothing fancy.
- inference_steps - integer, defaults to 25. Fewer steps = faster but rougher; 25 is a sensible DDIM default.
What it does under the hood
Every input frame gets resized to 512×512 (so keep your subject roughly centered - the crop isn't kind to off-center photos). The frame count is padded up to a multiple of 16, the internal temporal batch size, and then the pipeline denoises 25 steps (or whatever you set) with a guidance scale fixed at 7.5 in the pack's config - you can't tune that from the node. The output is one IMAGE batch containing the generated frames - exactly as many as you fed in, padding stripped.
Those frames don't assemble themselves into a movie. Run the output into a video-encoding node like VideoHelperSuite's "Video Combine" (or the core save-image nodes if you just want the PNGs) to get your clip.
Installing and the honest caveats
Same story as the whole pack: ComfyUI Manager, search "ComfyUI-MagicAnimate", or:
cd ComfyUI/custom_nodes/
git clone https://github.com/thecooltechguy/ComfyUI-MagicAnimate
cd ComfyUI-MagicAnimate/
python -m pip install -r requirements.txt
First ComfyUI start downloads ~15GB of weights into models/MagicAnimate - let it finish. If your output comes back washed-out white, that's a known bug that was fixed in a later release: update the pack (the README credits the fix, and it's exactly the symptom you'd hit on an old clone).
Now the part nobody wants to hear: MagicAnimate is a 2023 research model and it shows. It's slow - think seconds per frame at 25 steps on a mid-range card - it only handles one person, and the DensePose preprocessing is a whole workflow of its own. Modern open video models like Wan have far surpassed it on quality and speed. But those don't do "copy this specific person's pose onto that photo" as directly, and nothing here phones home. For that specific trick, in a fully local pipeline, this still works - you just have to feed it what it wants.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| magic_animate_model | MAGIC_ANIMATE_MODEL | — | |
| image | IMAGE | — | |
| pose_video | IMAGE | — | |
| seed | INT | — | |
| inference_steps | INT | 25 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | — |