ProPainter Outpainting

Here's a rare thing: the author's own README talks you out of expecting much from this node before it tells you how to use it. Straight from the docs: "The authors of the paper didn't mention the outpainting task for their framework, but there is an option for it in the original code. The results aren't very good but I decided to implement a node for it anyway." That's your expectation set correctly - ProPainter Outpainting widens a video's canvas using the same flow-propagation machinery that ProPainter uses for object removal, but outpainting was never what the underlying research was built or trained for. It's a bonus feature bolted onto a framework designed for something else, from daniabib's unofficial ComfyUI port.

Worth being honest about why you'd still try it: it needs no prompt and no diffusion model, so it's cheap to run and it won't invent a scene that clashes with your footage. But if you want a video genuinely extended with plausible new content - a wider frame, more background, not just stretched pixels - this generation's instruction-driven video models are simply better suited to inventing coherent new imagery than a flow-based algorithm that was repurposed for the job.

How it works

Same core mechanism as the inpainting node: it computes optical flow (RAFT - raft_iter iterations) and propagates pixels through the clip, except here the "mask" is the new canvas area outside your original frame rather than an object you painted over. Since there's no real footage to propagate into that new space, ProPainter leans much harder on its transformer to invent the extension - which is exactly the part the README is warning you about. Processing still runs chunked (subvideo_length) with reference frames (ref_stride) and a local temporal window (neighbor_length) for consistency across the clip.

Inputs and outputs that matter

• image - your source video frames. That's it for required footage; there's no separate mask input because the extension region is the mask.
• width_scale (default 1.2) and height_scale (default 1.0) - how much bigger the canvas gets in each dimension. 1.2 width / 1.0 height means: extend sideways by 20%, leave height alone. These are the two settings that actually define what this node does; everything else is tuning.
• width/height (640×360 default) set your working resolution before scaling is applied.

The rest - mask_dilates, flow_mask_dilates, ref_stride, neighbor_length, subvideo_length - carry the same defaults and same purpose as on the inpainting node. One default is different and worth knowing: fp16 defaults to disabled here, the opposite of the inpainting node's default-enabled. If you're tight on VRAM, flip it on; there's no reason it should behave differently node to node just because that's what shipped.

Outputs: IMAGE is the extended clip. OUTPAINT_MASK is the region ProPainter treated as new canvas - useful to preview if the extension looks wrong and you want to see what the algorithm thought it was filling. output_width and output_height hand back the actual final canvas size as INT values, since that's a function of your scale factors and isn't knowable upstream - wire them into any downstream node (a crop, a composite) that needs the real dimensions rather than hardcoding your own math.

Installing it

Via ComfyUI Manager: search "ComfyUI ProPainter Nodes" by daniabib. Manually: cd ComfyUI/custom_nodes && git clone https://github.com/daniabib/ComfyUI_ProPainter_Nodes, pip install -r requirements.txt in that folder, restart ComfyUI. Model weights (RAFT plus ProPainter's own checkpoints) download automatically to a weights folder the first time you run either node in the pack - expect a pause on first execution. Same license note as the inpainting node applies here too: ProPainter's models and code are under the NTU S-Lab License 1.0, non-commercial only, so this isn't the node to build a paid product on.

Common issues

Visible seams or warped-looking extensions are the expected failure mode, not a sign you've misconfigured something - this is the exact weakness the README calls out. If the result isn't holding together, it's worth asking whether you actually need outpainting on a video at all, or whether the honest fix is padding the canvas and running a modern instruction-editing model per-frame, which will simply generate more convincing new content than a propagation algorithm ever will.

VRAM pressure shows up the same way it does on the inpainting node - this pack's other reported crash was an 8GB card choking even at downscaled resolution. Lower width/height, shrink subvideo_length, and turn fp16 on if it's off.

Apple Silicon has the same open question as the inpainting node: PyTorch's MPS backend hasn't reliably supported the Conv3D ops this pipeline depends on, so budget for possible CPU fallback if you're on an M-series Mac.