Wan Extract Last Images

This node does exactly one thing: given a batch of images, hand back just the last N of them. It's the pixel-space equivalent of WanAdvancedExtractLastFrames (which does the same job on a LATENT) - same idea, different data type, and which one you need depends on where in your chain you're pulling continuity frames from.

Why you'd want this instead of the latent version

Wan's 5-second native ceiling gets worked around by chaining: generate a clip, carry its tail into the next chunk as a continuity anchor, repeat. The pack's WanAdvancedI2V and WanSVIProAdvancedI2V nodes both accept a motion_frames IMAGE input for exactly this - feeding in the last few frames of your previous chunk's decoded video, as pixels, rather than the raw latent. That distinction matters: if your workflow already decodes each chunk to save previews, upload it, or run it through post-processing before continuing (color correction, upscaling, interpolation - anything that only makes sense on pixels), you want to grab your continuity frames after that processing, not before. This node is what lets you do that: extract from the finished IMAGE batch rather than the pre-decode latent.

If your workflow never touches pixels between chunks - straight latent-to-latent chaining - WanAdvancedExtractLastFrames is the more direct and slightly cheaper path, since it skips a decode/re-encode round trip. Reach for this node specifically when there's real pixel-space work happening between chunks.

Inputs and outputs that matter

Two required inputs, nothing else:

• images (IMAGE) - the decoded frame batch from your previous chunk, after whatever VAE decode and post-processing you've done.
• num_frames (INT, default 9, range 0-81) - how many frames from the end of the batch to keep. The default lines up with the pack's other continuity defaults (WanAdvancedExtractLastFrames also defaults to 9, continue_frames_count on the advanced I2V node defaults to 5) - single digits is the normal range, not dozens.

Output: last_images - an IMAGE batch containing just that trailing slice, sized to feed into motion_frames on WanAdvancedI2V or WanSVIProAdvancedI2V for the next chunk in your chain.

Installing it

ComfyUI Manager: search "ComfyUI-Wan22FMLF". Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/wallen0322/ComfyUI-Wan22FMLF

Restart. No model dependency of its own - it's a pure image-batch slicing utility, so it doesn't care which Wan checkpoint or LoRAs the rest of your chain is using.

Common issues

Confusing this with the latent version. The two extract nodes have near-identical names and near-identical purpose, and it's an easy mix-up in a busy chaining graph. If a downstream node errors on input type, check whether you actually wanted WanAdvancedExtractLastFrames (LATENT in, LATENT out) instead - they are not interchangeable, and ComfyUI will complain about the type mismatch rather than silently converting for you.

Extracting from the wrong batch. In a loop-style multi-chunk workflow it's easy for this node to end up wired to an earlier chunk's images instead of the one you just generated, especially after a refactor. If your chained clip visually jumps backward instead of continuing forward, this is the first wiring to check.

Assembly, not generation, is where long chains actually fail. This holds for the whole pack's chaining path: people successfully generate a dozen-plus chunks and then hit a wall stitching or upscaling them together, sometimes needing to finish that step outside ComfyUI on setups with 16GB VRAM / 64GB system RAM once total footage crosses roughly a minute. This node itself is cheap - the failure shows up downstream, not here.

Using this when nothing between chunks actually needed pixels. If you're not doing any pixel-space processing between generations, this node (and the decode it implies) is pure overhead. Chain latents directly with WanAdvancedExtractLastFrames instead and save the round trip.