🌊 MI2V Flow Animator

If MI2V Flow Predictor is the plan, MI2V Flow Animator is the execution. It takes that predicted optical flow plus your starting image and renders the actual 16-frame animation - the frames you'd turn into a video. It's the node that costs you the GPU hours, so it's worth understanding exactly what it's doing before you queue it.

What it actually is

Stage two of Motion-I2V, and it's basically AnimateDiff by another name. The animator builds an SD 1.5 UNet with a temporal motion module (the same trick the AnimateDiff era made famous - frozen spatial UNet plus temporal attention), then loads the pack's own DreamBooth-finetuned weights on top: a realisticVisionV51 LoRA plus a personalized UNet checkpoint. So the output has a baked-in photorealistic look before you write a single prompt. It then runs that model forward with your flow as a warp constraint and your IP-Adapter image as an appearance anchor.

Here's the part that trips people up: the ipa_image input is required, not optional. Motion-I2V uses IP-Adapter to tell the model what things should look like when the flow reveals parts of the image that never existed - the README's demo is a man lowering his binoculars, and you feed it a separate face image so the model knows what's behind them. If you don't have a reference, just wire your first_frame in and lower ipa_scale to something like 0.3–0.5. The node runs fine that way; it just has less identity to lean on.

The inputs that matter

• flow (FLOW) - from the Predictor. The whole reason this node exists.
• first_frame (IMAGE) - must match what you predicted flow for.
• ipa_image (IMAGE) - the reference appearance image. Required, see above.
• ipa_scale (FLOAT, default 1.0) - how hard the IP-Adapter pulls toward the reference. Crank it when you want identity, drop it when you want freedom.
• prompt / negative_prompt, seed, num_inference_steps (25), guidance_scale (7).

Outputs

• images (IMAGE) - 16 frames, batch-shaped. Feed them into VideoHelperSuite's VHS_VideoCombine (or any video-save node) with frame_rate around 8–16 to get an actual mp4.

The price of admission

The animator is where this pack's diffusers-wrapper weight really shows. It rebuilds the entire animation pipeline from scratch on every run - tokenizer, text encoder, VAE, the UNet, the motion module, both DreamBooth checkpoints - and there's no keep-model-loaded toggle exposed. That's a slow start every single time, before a single step of sampling. Then you're doing 25 steps across 16 frames on a 3D UNet in fp16, and on top of that the predictor's output has already cost you one pass. The README's own TODO lists "Reduce VRAM usage" - this is that problem, live.

So the workflow discipline matters: run the predictor, check the flow preview colors, and only then connect and run the animator. The pack even ships a Pause node specifically so you can stop and eyeball the plan before paying for the render. The example workflow that ships in examples/ does exactly this - predictors and animators chained so you can inspect flow before committing.

Install

Same pack, same install as the rest of the I2V nodes - ComfyUI Manager, search "IG Motion I2V", or:

cd ComfyUI/custom_nodes
git clone https://github.com/IDGallagher/ComfyUI-IG-Motion-I2V
# restart ComfyUI

Dependencies are diffusers>=0.30.0, cupy-cuda12x>=13.2.0, omegaconf>=2.3.0, plus a hard-required xformers. The ~17.3GB wangfuyun/Motion-I2V checkpoint downloads automatically into ComfyUI/models/diffusers/Motion-I2V the first time the predictor runs - the animator reads the same folder, so no second download.

Gotchas

• VRAM. Two-stage, fp16, SD1.5-era 3D UNets. This is the "I need to close my other tabs" node. If you're on 8GB, this pack is going to be a bad time.
• Slow. Not just sampling - every run reloads everything. Batch your experiments: settle on a prompt and flow first, then render.
• Locked to 16 frames. The animator reads its frame count straight off the flow tensor, and the predictor always emits 16. Don't expect longer clips without chaining.
• cupy/JIT. The frame-warping (softsplat) code compiles CUDA kernels at runtime, which means the CUDA toolkit / nvcc needs to be findable. This pack is Linux-and-CUDA-12 territory, full stop.

Honest verdict: in 2026 this is a legacy tool - Wan 2.2 does general image-to-video better and easier. But if you specifically want drag-drawn motion control, this two-node chain is still the unique thing that does it locally, and the animator is the workhorse that finishes the job.