AP Load Optical Flow

The pair to APSaveOpticalFlow. Where save writes your flow to disk, this node reads it back and hands you the same AP_FLOW object you'd get from a fresh APGetRAFTOpticalFlow - without paying for the RAFT inference. If you've ever sat through a 20-frame sequence recomputing flow every time you tweak a denoise value, you know exactly why this exists.

The usage is dead simple: save flow once (APSaveOpticalFlow), drop this node into your graph, type the path, and everything downstream (APApplyRAFTOpticalFlow, APFlowOcclusionMask, APFlowComposite) behaves as if the flow were computed live. The README's flow-cache workflow is precisely "write flow_data to .pt in your Comfy output path, reuse it later with AP Load Optical Flow to skip recomputing flow."

The mechanism

APLoadOpticalFlow takes a file_path (default AP_OpticalFlow/flow.pt), resolves it against ComfyUI's output, input, and current-directory paths (so you can also point at a file in your input folder), and torch.loads it to CPU. It validates the payload's ap_optical_flow tag, normalizes the flow tensors into the standard AP_FLOW shape - both directions, height, width, model variant - and hands you the same dict structure the compute node produces. It also renders a flow_visualization from the loaded forward field, so you get the color-motion preview without needing the compute node.

Inputs and outputs

One input, file_path - the path to a .pt saved by APSaveOpticalFlow. That's the whole API.

Two outputs: flow_data (the AP_FLOW object, ready to wire into any apply/occlusion/composite node) and flow_visualization (the color IMAGE of forward motion, for a quick sanity check that you loaded the right file).

Installing it

Same pack-wide install as everything here - ComfyUI Manager (search "AP_OpticalFlow"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/adampolczynski/ComfyUI_AP_OpticalFlow
python -m pip install -r custom_nodes/ComfyUI_AP_OpticalFlow/requirements.txt

Restart. torchvision>=0.15 is the only dependency - and note you don't even need it working for this node, since there's no RAFT inference involved in a load. That's the point.

Where this shines

The big win is iteration speed on long workflows. Compute flow once, save it, then re-run the rest of the graph as many times as you like with APLoadOpticalFlow replacing APGetRAFTOpticalFlow. It also decouples phases: you can compute flow in one batch run, then do the warp/blend passes separately. And it pairs with the compute node's flow_offload=disk_storage, which auto-writes flow to .pt - this node is how you reuse those auto-saved files deliberately.

The two gotchas

First, resolution coupling: the flow was computed at a specific frame size, and the file records it. If you change your video's resolution after caching, the loaded flow won't match the new frames. The apply nodes will resize the flow to fit - but resized flow is an approximation, not the same as flow computed at the target size. Change resolution, recompute.

Second, garbage in, garbage out: this node trusts the file. If you load a stale save from before you re-rendered your source frames, you'll silently warp with flow that describes the old frames. The visualization output is your guard - give it a glance if results suddenly look wrong, because "the flow is from last week" is a very easy silent bug in a load/save workflow.