Eulerian Motion Fluid Animator
The Eulerian Motion Cinemagraph Trick
- image
- animated_frames
Want a waterfall that keeps falling, smoke that keeps curling, or clouds that drift forever - from a single still photo, without dragging a multi-gigabyte video model into the mix? That's the whole pitch of the Eulerian Motion Fluid Animator, and it's a pitch that's gotten a little dusty since 2021. It wraps a CVPR paper from the University of Washington and Meta AI called Animating Pictures with Eulerian Motion Fields, a pre-diffusion answer to the question "how do I make a cinemagraph?" It's not the first node anyone suggests for animating images anymore, but for one narrow job it's still quietly the right tool.
What it actually does
Instead of generating new frames, the underlying model looks at your photo and predicts a motion field - a dense map of which way each pixel should drift over time - plus which parts of the scene are alive (water, smoke, flame) and which are static. It then warps the original photo along that field and plays it on a loop. That's why it's "Eulerian": the motion is described at fixed pixel positions in the image over time, not by tracking particles around. The result is a seamlessly looping animation where the source pixels stay crisp because you never regenerate them. No drift, no morphing into a puddle, no temporal incoherence - the frame content is the frame content, just moved.
It's also fully local and deterministic: no API, no key, no model calls to Meta's servers. This is the same idea class that video-diffusion eventually swallowed whole - the ComfyUI community's go-to for "animate my still image" is now video models like AnimateDiff and its successors - but those regenerate pixels and can wander. This node can't. It just can't do people, either; the learned motion fields are really only at home in fluids.
The inputs that matter
There are only three, and the defaults are sane:
- image - any IMAGE you have. A photo, or a ComfyUI generation of a waterfall or campfire scene.
- num_frames - clip length, 10–240, default 60. More frames means a longer, smoother loop.
- motion_speed - 0.1–5.0, default 1.0. This is the "how fast" knob; it sets how many full motion cycles play across the clip. Keep it near 1.0 and nudge, or you'll get jitter instead of flow.
The single output, animated_frames, is a batch of images. Wire it into VHS_VideoCombine from the VideoHelperSuite, or just SaveAnimatedWEBP/SaveAnimatedPNG, and you have a looping cinemagraph file.
Installing it - and the trap
The pack itself is a single-commit, one-node wrapper. Install it like any custom node - through ComfyUI Manager by searching "Eulerian Motion Fluid Animator", or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/Fatak98/ComfyUI-Eulerian-Motion
then restart ComfyUI. The declared Python deps (numpy, opencv-python, pillow) are harmless. Here's the catch the README never mentions: the node imports the actual model from a subfolder called Eulerian-Motion-Fields, and that subfolder is not in the repo. No submodule, no download script, nothing. Until you put it there, the node does not animate.
cd ComfyUI/custom_nodes/ComfyUI-Eulerian-Motion
git clone https://github.com/zhengqili/Eulerian-Motion-Fields
You also need the pretrained model checkpoint from that repo's instructions, placed where it expects it. It's research code from 2021, so expect old-PyTorch friction - that's a real 20-minute detour, and it's the reason this node stays niche.
Where people get burned
The silent failure. If the model subfolder is missing or anything inside throws, the node doesn't error out in the UI - it returns num_frames copies of your input, i.e. a static image. The only sign is a line in the ComfyUI console ([Eulerian Warning] or [Eulerian Error Details]). You'll happily save a "video" that never moves. If you get still frames, check the console first. On the bright side, the author did ship one real compatibility fix: the node passes an empty arg list to the model's option parser so ComfyUI's startup arguments don't crash it, and it falls back to CPU if you have no CUDA - slow, but it runs.
My honest take: if you have a fluid scene you love and want a guaranteed-looping, pixel-faithful cinemagraph on modest hardware, this is worth the setup. If you just want motion on any image, go play with a video model instead - this one will only ever be a waterfall.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| num_frames | INT | 6010–240 | — |
| motion_speed | FLOAT | 1.00.1–5 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| animated_frames | IMAGE | — |