🖼️ IG Motion Video Frame
Turn a second of video into a motion fingerprint
- video_frames
- colored_motion_image
The IG Motion Video Frame node takes a pile of video frames and squashes them into a single color-coded image that describes how the shot moves. That's the whole job, and it's easy to underestimate. It's the front half of the IG-Motion-Search pack, and it's the node people skip - they feed a normal screenshot into the search node, get garbage results, and blame the pack. The search node is useless without this one. This is the part that makes it work.
The trick: search motion, not pixels
The pack's party trick is that it searches motion, not visual content. The author (IDGallagher, the same person behind the ComfyUI-IG-Motion-I2V node) treats movement as a first-class signal: instead of asking "what looks like this video?", you ask "what moves like this video?". This node is the encoder that makes that question possible - it renders a clip's motion as one distinctive image that the pack's search index was built on.
Under the hood it's more interesting than the name suggests. You hand it a batch of frames, it keeps the first 24 (one second at 24fps), rescales the shorter side to 336px, center-crops to a multiple of 8, then runs a point-tracking model from the 16lemoing/dot research repo - a CVO-RAFT optical flow network plus CoTracker-class point trackers. It computes where every pixel moves relative to frame one, then draws the displacement as a classic Middlebury colorwheel flow map: hue encodes direction, brightness encodes how far things traveled. Out comes one image where a car driving left is a different color than a car driving right, and camera pans look completely different from zooming.
The one input and one output
The schema is a model of restraint. One input, video_frames (IMAGE - a batch of at least 24 consecutive frames from a video loader). One output, colored_motion_image (IMAGE), which you wire straight into the IG Motion Video Search node's image input. That's the intended loop: load video → this node → search node → URLs.
Installing it
It ships in the same pack as the search node, so one install covers both. ComfyUI Manager: search "IG-Motion-Search" (the pack is on the registry as "Motion-Video-Search"). Or the old-fashioned way:
cd ComfyUI/custom_nodes
git clone https://github.com/IDGallagher/MotionVideoSearch
Restart ComfyUI. The catch is what happens on first use: the node auto-downloads roughly seven point-tracking checkpoints into checkpoints/ - several gigabytes total, and that's before any of your own model downloads. A long, quiet first run is normal, not a hang. The declared requirements are light (faiss-cpu, einshape, timm), and everything else it needs - torch, torchvision, requests, tqdm, einops - you already have in a working ComfyUI. The README's long install list (ffmpeg 6, av, mediapy, typer…) is for the CLI indexing tool, not for this node; ignore it unless you're building your own index.
Where people get burned
- Fewer than 24 frames is a hard error. A short or low-fps clip fails outright. Load a full second of video - the shipped workflow uses VHS nodes (VHS LoadVideo / VHS BatchManager) for exactly this.
- Only the first 24 frames count. Feed a minute-long clip and it silently trims to the first second. Trim in the loader instead.
- "OMP: Error #15" is a known-ish crash with this stack; the source sets
KMP_DUPLICATE_LIB_OK=TRUEto suppress exactly that OpenMP duplicate-library conflict. - The DOT model is rebuilt and cached per input resolution, so wildly jumping between video sizes forces reloads. Keep your load dimensions consistent.
Honest take: this is an experimental pack with almost no community footprint and a chunky one-time download. But the colorized motion frame is genuinely cool to look at, and once it's cached this node runs in seconds. Worth an afternoon.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| video_frames | IMAGE | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| colored_motion_image | IMAGE | — |