[Inference.Core] Unimatch Optical Flow

This one's a different animal from the rest of this pack. Every other preprocessor here takes one image and hands back one map - edges, depth, segmentation. Optical flow needs at least two: it computes, for every pixel, where that piece of the scene moved to in the next frame. Feed it a single still image and there's nothing for it to measure - this node is built for video frame sequences, not single shots.

What it's actually for

Optical flow is the motion primitive underneath a bunch of video-editing tricks: warping one frame's content to match the next for temporal consistency, occlusion detection, flow-guided interpolation, style-transfer passes that need to know what moved where. It's a genuinely useful building block - but be aware it's filed under "ControlNet Preprocessors" here mostly out of pack convention. The actual video-conditioning ecosystem in 2026 has largely moved past classic ControlNet-style flow into architecture-specific systems (Wan's VACE, LTX-2's IC-LoRA adapters). So expect to wire this node's output into a dedicated warping or temporal-consistency node from whatever video pipeline you're building, not into a generic "ControlNet Apply."

The model behind it, Unimatch (and its GMFlow predecessor, which is what the checkpoint names reference), is a unified matching architecture originally built to handle optical flow, stereo depth, and depth estimation with one shared design - this node uses the flow half of that.

Inputs and outputs

• image (required) - your frame sequence.
• ckpt_name (enum, default gmflow-scale2-regrefine6-mixdata.pth) - three checkpoint options, roughly fast-to-thorough: gmflow-scale1-mixdata.pth (single-scale matching, lightest and quickest), gmflow-scale2-mixdata.pth (two-scale matching, better on larger motions), and the default gmflow-scale2-regrefine6-mixdata.pth (two-scale plus six iterative refinement passes - most accurate, and the slowest of the three). Start with the default; drop to scale1 if you're processing long sequences and speed matters more than precision.
• backward_flow (boolean, default false) - computes flow in the reverse direction (where a pixel came from, rather than where it's going) instead of the standard forward direction.
• bidirectional_flow (boolean, default false) - computes both directions and combines them, roughly double the compute, useful when a downstream node wants forward/backward consistency (a common way to detect occluded regions in flow-based pipelines).

Two outputs: OPTICAL_FLOW, a custom type that only nodes built to consume flow fields will accept - check what your downstream warping/interpolation node actually expects before wiring this up - and PREVIEW_IMAGE, a human-readable visualization of the flow field (motion direction and magnitude rendered as color), which is what you'd actually look at to sanity-check the result before trusting the raw flow data to anything.

Installing it

ComfyUI Manager: search ComfyUI-Inference-Core-Nodes, install, restart. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/LykosAI/ComfyUI-Inference-Core-Nodes

Then run install.py, or pick the pip extra for your hardware - .[cuda], .[cuda12], .[rocm], .[directml], .[cpu] - for the dependencies plus accelerated onnxruntime where the pack uses it. Restart ComfyUI. Whichever ckpt_name you pick downloads on first use, not at install time, so the first run per checkpoint choice is slower - switch checkpoints and you'll trigger another download.

Where people get burned

The obvious one first: feed this a single image and you won't get meaningful flow - it needs an actual sequence of frames to compare. If your results look like noise, check that you're actually passing a batch, not a lone frame. Beyond that, this pack shares the same install landmines as its siblings: a ModuleNotFoundError: No module named 'inference_core_nodes' after cloning usually means the install ran against the wrong Python (use the embedded interpreter explicitly on portable ComfyUI builds), and there are scattered reports of the whole pack failing to import on Mac - pip install -e .[cpu] is the extra to reach for there, since none of the GPU-accelerated onnxruntime builds apply on Apple silicon. One more practical note: gmflow-scale2-regrefine6-mixdata.pth, the default, is meaningfully slower than the other two on long sequences - if a batch is taking forever, that checkpoint choice is the first thing to check before you assume something's broken.