K3NK Image Grab

The core trick behind every "infinite" local video workflow is boring and brilliant at once: generate a clip, grab its last frames, and feed them back into the model as the start of the next clip. Wan's I2V is great at continuing from a known frame - that's how people chain 81-frame segments into 30-second-plus takes. K3NK Image Grab is the node that does the grabbing, and it does it with a level of control the stock loaders just don't have.

It's the flagship of the K3NK pack, and the pack exists because of it. K3NK3 is a CivitAI workflow author whose Wan 2.2 "video extend / loop" workflows circulate in the community; this node is the plumbing from those workflows, extracted and generalized. If you've ever downloaded one of those "6-step extend" templates and wondered how the frame-grabbing part worked, this is it.

How it works

Point it at a directory and it globs files by extension (default jpg,jpeg,png,bmp,tiff,webp,latent), sorts them by the number in the filename, and pulls the last num_images of them. frame_stride lets you skip frames between picks - handy when your output is interpolated and every other frame is redundant. It then builds two things you actually wire into a Wan pipeline:

• latent_batch - a 5D latent tensor in WanVideoWrapper's [1, C, T, H, W] layout, with every selected frame concatenated along time. This is what you feed the sampler to continue the video.
• anchor_frame - a single latent frame pulled from the highest-numbered .latent file in the folder (or the lowest, if you flip anchor_from_start). In the WanVideoWrapper workflow this is your I2V reference: the exact frame the next clip starts from.

There's also an image output with the actual loaded frames as tensors, plus filenames, full_paths, and a timestamp (the newest file's mtime) if you want the graph to react to what was grabbed.

The Wan-specific details live in three inputs: batch_start_frame, batch_end_frame, and max_batch_frames. The tooltips spell it out - WanVideoWrapper processes frames in groups of 4, so these operate on frame groups, not individual frames. batch_start_frame=1 drops the first 4 frames; batch_end_frame=1 removes the last 4; max_batch_frames caps the total. Wan's VAE spits out temporal latents in 4-frame chunks, so trimming in groups keeps the math clean. That's the kind of detail you'll only find by reading the source - it's why this node exists instead of a folder loader plus a LatentFromBatch.

The inputs most people set

• directory_path - where the frames live.
• num_images - how many files to grab (default 2).
• frame_stride - skip N between picks (default 5; 0 = every frame).
• reverse_logic - off means grab newest first; on starts from the oldest. Useful when you're iterating and want the start of the sequence instead of the end.

The optional vae input is worth one honest sentence: it exists in the node's schema but the shipped code doesn't actually use it yet. Wire it if you like, but don't expect a decode pass - decode the image output yourself if you need pixels.

Installing it

ComfyUI Manager → search ComfyUI-K3NKImageGrab. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/K3NK3/ComfyUI-K3NKImageGrab

Restart ComfyUI. It needs only Pillow plus what ComfyUI ships. IS_CHANGED returns the current time, so it never caches - every run re-reads the folder, which is exactly what you want in a continuation loop.

Where people get burned

Filename numbering is everything. The node sorts by the last number in the filename, so clip_1_081.png and clip_2_001.png will interleave confusingly - number your segment exports sequentially across the whole take. And if a folder mixes .latent and image files, remember the image output becomes placeholder tensors for the latent files (it can't decode them without a VAE), so size your downstream nodes against the latent_batch output, not image. Keep the anchor and batch logic straight from the start: anchor = where the next clip begins, batch = the frames being continued from.