Image Batch Extend With Overlap (Swwan)

Why this node exists

You cannot generate a five-minute clip in one pass. VRAM scales with frames, so the generation end of every serious video workflow is the same trick: generate a short window, then extend it by feeding the model the last few frames of what you already have as the start of the next window, generate more, and stitch them together. The overlap is what stops the seam from being visible.

That's two different jobs - "give me the frames to start with" and "glue the new frames onto the old ones" - and this single node does both, depending on whether you wire its optional input. It's KJNodes' ImageBatchExtendWithOverlap, re-registered by the Swwan pack, and the author's own tooltips describe the two-pass flow: first pass gets the starting frames, second pass does the joining.

Pass one: no new_images

Feed it your existing source_images and an overlap count, and start_images comes out as the last overlap frames of the batch. That's the context you hand your video model. extended_images comes out as a 1×64×64 black placeholder - deliberately empty, per the author's tooltip ("if no new images are provided this will be empty"). Nothing to wire; it's just there so the socket exists.

Pass two: with new_images

Now wire the freshly generated frames into new_images on a second copy of the node, along with the original source_images, and extended_images becomes the joined clip. What happens under the hood: the last overlap frames of the source are dropped, the first overlap frames of the new batch are blended against them, and the rest of the new batch is appended. So the total length is len(source) + len(new) - overlap - not a concatenation, an overlap.

The blend weights walk from source-heavy to new-heavy across the overlap, which means no frame in the seam is ever 100% one or the other. That's the smoothing.

The knobs

• overlap - default 13. How many frames are shared. Too few and the seam pops; too many and the model re-generates content you already had, burning time. The sane value is whatever your video model uses as its context window.
• overlap_side - source (default) or new_images. It decides which set the blend starts from, i.e. the direction of the handoff. Flip it if a seam looks like it's blending backwards.
• overlap_mode - linear_blend (default), ease_in_out, or cut. cut takes no blend at all: it just drops the overlap frames and butts the clips together. Useful when the model already produced a seamless continuation and any cross-fade would double-expose motion.

Outputs are source_images (an untouched pass-through, handy for chaining), start_images, and extended_images.

Install

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

Manager → ComfyUI Swwan, restart, hard-refresh. Base requirements only - this is tensor slicing and blending, no models, no optional dependencies.

Gotchas

If overlap is greater than or equal to the length of your source batch, the node quietly returns the source three times. No warning, no error, just a passthrough. On a short first segment - say a 13-frame clip with overlap = 13 - that's exactly what happens, and it reads like "the extension node didn't extend anything".

Source and new frames must be the same resolution. A mismatch raises Source and new images must have the same shape, which is one of the more legible errors in the pack. It won't resize for you, unlike some of its siblings.

The overlap frames are consumed, not duplicated. Your output is shorter than source + new. If a downstream node assumes a specific frame count, and you tuned it against a concatenation, this is where the count changes.

And the practical one: run pass one and pass two as two nodes, not one node wired into itself. The second pass needs the original source, which only exists before you've generated the extension - that's why the node asks you to make a copy of it rather than looping.