PainterImageFromBatch

Every video workflow in ComfyUI eventually hits the same wall: your video is one big IMAGE tensor where dimension 0 is the frame count, and ComfyUI's built-in ImageFromBatch node only counts from the front. Want the last frame? The last fifteen? You're doing batch_size − 15 arithmetic in your head, and the moment you load a differently-sized video, your index silently grabs the wrong frames. PainterImageFromBatch exists to kill that arithmetic.

It's a friendlier slice of the same pie: the core ImageFromBatch, plus the two things the built-in never got - an end mode that counts from the back of the batch and negative indices. No API, no keys, no model downloads. Just a smarter slice.

Why you'd actually reach for it

The killer use case is frame-looping and frame-extending. People extend WAN i2v generations by ripping out the last frame, upscaling it, and feeding it back in as the next video's start image. Doing that with the built-in node means knowing the exact batch size and hardcoding an index - which breaks the instant your video length changes. Here, "last N frames" is just end, -N, N. Same story for trimming dead tail frames off a batch before you VAE-encode or upscale, or pulling one frame out to preview it. It's the kind of node you install once and stop thinking about.

How it works

The whole thing is roughly thirty lines of PyTorch. It reads image.shape[0] as the batch size, then resolves your start index:

• beginning mode: start_frame = 0 is the first frame; negative values count back from the end, so -1 is the last frame.
• end mode: negative values count back from the last frame, so start_frame = -15 with frame_count = 15 hands you the final 15 frames. Positive values offset from the end.

Then it clamps both the start and end of the slice into bounds and returns image[start:end].clone(). That .clone() matters - it means downstream nodes can't mutate your original batch by accident. And if clipping ever leaves an invalid range, it falls back to the last frame_count frames instead of erroring. The README calls this "always returns at least one valid frame," and it's accurate.

Inputs and outputs

Four inputs, only three you'll touch:

• image - the IMAGE tensor coming from a Load Video / Load Images node or the tail of a previous batch operation.
• start_from - beginning or end. This is the whole point of the node; set it once and forget it.
• start_frame - the starting index, range −4095 to 4095, defaults to 0. Negative means "count from the back."
• frame_count - how many contiguous frames to pull, 1 to 4096, defaults to 1.

One output, IMAGE, with exactly the frames you asked for, ready to wire into an upscaler, a VAE encode, an image model, or another batch node. It behaves like a straight slice, so don't expect any reshaping magic.

Install

Dead simple, because there's nothing to download. Clone it into custom_nodes and restart:

cd ComfyUI/custom_nodes
git clone https://github.com/princepainter/ComfyUI-PainterImageFromBatch

Then restart ComfyUI. ComfyUI Manager also has it - search "ComfyUI-PainterImageFromBatch." There's no requirements.txt and no models to fetch; it's pure torch that ComfyUI already ships. Zero GPU cost, too - a slice is a view, not a compute.

Gotchas and honest caveats

• Fewer frames than you asked for is by design, not a bug. If your batch has 81 frames and you request 15 starting at frame 75, the boundary clipping quietly gives you the 6 that exist. If you need to know you got all of them, check the batch size downstream.
• It lives in the image/batch category and shows up as "PainterImageFromBatch." Can't find it after install? Restart - and make sure your Manager update actually picked up the new pack.
• This is a genuinely tiny, near-zero-impression fork. Princepainter is a small author, the repo has essentially no community footprint, and you should expect it to be frozen. If all you ever do is slice from the front, the built-in node is fine - this earns its place exactly when you need the tail of the batch, and you'll know it because otherwise you're doing subtraction.