Even Batch Picker (CRT)

You've got a 300-frame video loaded as a batch of images, and you need maybe six of them - spread out evenly across the clip, not all from the start. That's the Even Batch Picker. It takes an image batch and a count, then samples that many frames at even intervals across the whole thing, keeping the first and last frames.

It's a quiet workhorse in the video-adjacent parts of ComfyUI. The most common use is speed: previewing or prompting off a decimated version of your footage before committing to a full pass over every frame. Run the picker to grab, say, 8 representative frames, feed those to your sampler, and check that the result looks right before you burn the real compute. It's also handy for seeding workflows - take every Nth frame of a long clip to build the keyframe set for interpolation or loop work, or to hand a subsampled "trailer" batch to a node that needs a digest of the whole shot.

How it works

The math is dead simple and deterministic. With a batch of N images and a requested count, it picks indices evenly spaced across the range, always including index 0 and index N-1. The implementation just computes int(i * (N-1) / (count-1)) for each step, then grabs those frames in order. Inputs are images (IMAGE) and count (INT, default 2, up to 4096). Output is a single images batch.

Two edge cases worth knowing:

• If count is 1, you get just the first frame.
• If count is greater than or equal to the batch size, you get the whole batch back unchanged.

So it's safe to wire up before you've decided on a count - you can't ask for more frames than exist and get an error; you just get everything.

Install

It's part of the CRT-Nodes pack:

cd ComfyUI/custom_nodes
git clone https://github.com/PGCRT/CRT-Nodes.git
pip install -r CRT-Nodes/requirements.txt

Restart ComfyUI, or install via ComfyUI Manager by searching CRT-Nodes. The node lives under CRT/Video.

Troubleshooting

There's not much room for failure in a four-line index calculation, but a couple of habits will save you pain. First, remember the output frames are in the same order and timing as the original - evenly spaced indices means evenly spaced time, so a 10-second clip decimated to 5 frames gives you one every 2.5 seconds. If your downstream node assumes the frames are contiguous (a video encoder, say), feed it the decimated batch and it'll happily re-timestamp them as consecutive frames; that's usually what you want for a preview, but don't expect playback speed to match the source.

And if you're decimating to feed a video-load node, check that node's select_every_nth style of input first - some loaders can do the thinning on load, saving you a node. When you need the result after other processing, though, this is the one you'll reach for.