FL Image Selector

You generated a batch of 12 variations and only three of them are worth keeping. Rather than manually saving each good one and deleting the rest downstream, FL_ImageSelector lets you type the indices you want and get a new, smaller batch containing exactly those images, in the order you listed them.

How it works

It's a comma-separated index parser wrapped around a batch slice: you give it a string like 0,3,7, and it pulls those specific images out of the batch, in the order you wrote them (not necessarily the order they appear in the source batch - listing 7,0,3 reorders them). There's also a special last keyword for grabbing the final image in the batch without knowing its numeric index in advance.

The inputs and outputs that matter

Both required:

• images - the batch to select from.
• indices - a string of comma-separated indices, e.g. 0,1,2, or the keyword last.

Output: a single IMAGE batch containing only the selected images, ordered the way you listed them.

How to install it

Ships in ComfyUI_Fill-Nodes. ComfyUI Manager: search ComfyUI_Fill-Nodes, install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI_Fill-Nodes

then restart. Plain string parsing and tensor indexing - no dependencies.

Common issues & troubleshooting

Indices are 0-based, same as everywhere else in ComfyUI. The first image in a batch is index 0, not 1 - an off-by-one here is the most common way to grab the wrong frame. If you're not sure which index maps to which image, preview the batch first (or use FL_ImageBatchToImageList to inspect it) before writing your indices.

Listing an index twice duplicates that image in the output. 0,0,1 gives you a 3-image batch with the first image repeated - that's a real feature if you want a frame repeated (e.g. holding on a frame longer in a simple slideshow), but it's also an easy typo to make by accident.

last is dynamic, numeric indices aren't. If your batch size changes between runs (a variable-length generation, say), last always resolves correctly, while a hardcoded number like 11 silently becomes wrong the moment the batch is smaller or larger than 12 images. Prefer last over guessing the final index when batch size isn't fixed.

Double-check indices after anything upstream shrinks the batch. If a filtering node earlier in the graph (FL_BlackFrameReject, for instance) drops frames conditionally, the batch you're indexing into here can be smaller than you expect on any given run - indices written against the "usual" batch size can end up pointing past the end of a run where more frames got filtered out.