Gradient Transition

The one-line pitch

This is the sibling of Linear Transition in the same pack, and the one you'll actually reach for when a transition needs to look deliberate rather than cut. Same setup - two images in, a sequence of frames out - but instead of a hard-edged curtain, a soft sigmoid blend band sweeps across the frame, so image2 fades in through a traveling zone of partial blend. It's a "traveling crossfade," and it's pure math: no model, no VRAM pressure, nothing to download. Perfect for slideshow fades, moody scene changes, and feeding an image-to-video model a smooth first/last-frame bridge.

transition_width is the whole game

Everything that distinguishes this node from its hard-edge sibling lives in one float: transition_width (0.01–1.0, default 0.2). It controls how wide the soft blending zone is:

• 0.01 - basically a hard edge, you've reinvented LinearTransition.
• 0.2 (default) - a reasonable band; the sweep reads as a gradient rather than a cut.
• 1.0 - a long, gentle blend that's close to a full-frame dissolve sliding across.

Mechanically, each frame places a sigmoid centered at the current sweep position, with transition_width / 2 controlling how steep that sigmoid is, then mixes image1 * (1 - mask) + image2 * mask. Higher width, gentler edge. Lower width, more Linear-like.

The quirk you'll hit (verified, not folklore)

Here's where the pack stops being consistent, and it's the one thing worth memorizing before your first render. I ran the actual node code, and the direction enum behaves differently between the two nodes:

• On the Linear node, all four directions run image1 → image2.
• On this Gradient node, right_to_left and bottom_to_top also run image1 → image2 - but the two "forward-feeling" directions, left_to_right (the default) and top_to_bottom, effectively run in reverse: you open already most of the way into image2 and close on image1.

So the default left_to_right gradient will look like your transition is playing backwards, and no amount of fiddling with transition_width fixes it. The fix is one click: flip direction to right_to_left (or swap which image goes into image1 vs image2). Also, because a sigmoid never quite hits 0 or 1, the first and last frames keep a soft trailing blend on the far edge - with the default width it's a subtle band, not a bug to panic over.

Inputs and outputs

Everything else matches its sibling: image1, image2, frames (2–240), direction, fps, plus the added transition_width. Outputs are frames (an IMAGE batch of frames frames) and fps_int (an INT), wired the same way - frames goes into a video encoder like VHS's CreateVideo or ComfyUI core's SaveVideo, and fps_int saves you a manual float-to-int conversion.

Installing

Shared with the whole pack: ComfyUI Manager → search LinearTransition → install, restart, done. Or:

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

No requirements.txt, no model files - it's one Python file using only torch. Same gotchas as the sibling too: only the first frame of each input image is used, image2 is auto-resized to image1's dimensions, there's no easing (constant-speed sweep), and the output is a batch of stills, not a video file.