Linear Transition

The one-line pitch

Two images in, a stack of frames out, where a hard-edged wipe sweeps across and image2 is revealed behind it - like a curtain being pulled. That's the whole job of LinearTransition, and it does it in a way that's refreshingly boring: pure tensor math, no model files, no API keys, nothing to download beyond the pack itself. You reach for it when you need a clean scene change in a slideshow video, a title-card cut, or a set of deterministic keyframes to hand to an image-to-video model.

The name is a slight lie

"Linear" here describes the hard edge, not a soft blend. This node produces a binary boundary: every pixel is either image1 or image2, nothing in between, and that boundary marches across the frame at constant speed. If you clicked in expecting a crossfade, you're on the wrong node - the sibling in this pack, Gradient Transition, is the smooth one. The README even labels this the "hard boundary" variant. Knowing that up front saves you a render of mild confusion.

How it works

For each of your frames frames, it builds a linear gradient across the frame along your chosen axis, cuts that gradient with a threshold equal to i / (frames - 1), and blends the two images on either side of the cut. Frame 0 is pure image1; the last frame is image2. The boundary speed is linear in frame index, which means there's no easing - no slow start or settle, just a steady curtain. Fine for most transitions, but if you wanted that "ease-in" feel, you'd feed these frames somewhere that does keyframing instead.

The other niceties are handled automatically: if the two images aren't the same size, image2 gets bilinearly resized to match image1, and fps is passed through so you don't lose it downstream.

Inputs and outputs that matter

Only a handful of knobs, and they're all obvious:

• image1 / image2 - the starting and ending images (both IMAGE).
• frames - how many output frames to generate, 2–240. More frames = smoother sweep, linearly more memory.
• direction - left_to_right, right_to_left, top_to_bottom, or bottom_to_top. The wipe travels along that axis.
• fps - a float, 1–60, mostly for bookkeeping.

Outputs are frames (an IMAGE batch of frames frames) and fps_int (an INT - the author knew video nodes are picky about int fps, and exposed it so you don't have to convert). Wire frames into a video encoder like VHS's CreateVideo or ComfyUI core's SaveVideo and you're done.

Installing

It's on the Comfy Registry, so the easy path is ComfyUI Manager → search LinearTransition → install, then restart ComfyUI. Or clone it by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/yichengup/ComfyUI-LinearTransition

then restart. There's no requirements.txt and nothing to put in models/ - the whole thing is one Python file, so this is about as dependency-free as a custom node gets.

Where people get burned

• Only the first frame of each input is used. If you feed it a video or a batch of images, image1[0:1] and image2[0:1] are what actually transition. Feed it two stills, not a clip.
• The output is a batch of stills, not a video file. You must pass frames to a video-encoding node yourself.
• No easing. Constant-speed sweep, period.
• It's a hard wipe. If the visible seam bugs you, the Gradient Transition node in the same pack is the smooth version - and shares this install.