Insert Image Batch By Indexes

This is a niche node with a specific job: it's the put-it-back half of a filter-then-restore workflow. You take a batch, filter some frames out, process only the ones you kept, then use this node to slot the processed frames back into their original positions so the batch comes out whole and in order. The node's own description spells it out - it's designed to pair with FilterZeroMasksAndCorrespondingImages.

If that pairing means nothing to you yet, that's fine - most people meet this node because a workflow they downloaded uses it, not because they went looking. But the pattern it enables is genuinely clever.

Why you'd reach for it

Here's the scenario. You've got a batch of frames, and only some of them have a non-empty mask - maybe a subject only appears in part of a clip. Running your expensive processing (a detailer, an inpaint, a restyle) on the empty frames is wasted work. So you filter: FilterZeroMasksAndCorrespondingImages throws away the frames whose masks are empty and hands you the kept images plus the indices they came from. You process just those. Then InsertImageBatchByIndexes takes your processed images and the remembered indices and rebuilds the full-length batch, dropping each processed frame back into its original slot.

The payoff is you only paid to process the frames that mattered, but you still get a complete, correctly-ordered batch out the other end. That's the whole point of the filter/insert dance.

The inputs and outputs that matter

• images (IMAGE) - the base batch that receives the insertions (the original sequence).
• images_to_insert (IMAGE) - your processed frames, the ones going back in.
• insert_indexes (INDEXES) - where each processed frame belongs. This isn't a string you type; it's the special INDEXES output that the filter node produces. You wire it straight across from the filter, and the two nodes stay in sync automatically.

Output is images_after_insert (IMAGE) - the reassembled batch, original sequence order restored, ready to continue down the graph.

The key thing: insert_indexes is a typed handoff, not free text. It exists so the filter and insert nodes can round-trip without you manually tracking which frame went where.

How to install it

ComfyUI Manager: search KJNodes for ComfyUI, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-KJNodes
pip install -r ComfyUI-KJNodes/requirements.txt

Restart and it's under KJNodes/image. No model downloads.

Common issues & troubleshooting

"Where does insert_indexes come from?" From FilterZeroMasksAndCorrespondingImages (also in KJNodes). This node is one half of a pair - the INDEXES output of the filter feeds the insert_indexes input here. Trying to hand-build that input is the wrong approach; wire it from the filter.

Count mismatch. The number of images_to_insert has to match the number of indices the filter produced. If you dropped or added frames in your processing branch, the counts drift and the insert can't line up. Keep your processing one-in-one-out so every filtered frame comes back.

"I just want to insert frames at positions I type." Then you want a different node. InsertImagesToBatchIndexed takes a plain comma-separated index string and even has a replace-vs-insert mode. Use that one for manual, hand-typed insertion; use this one specifically for the filter round-trip with the INDEXES handoff.

Order came out wrong. As long as you feed the untouched insert_indexes from the filter, order is preserved automatically. A scrambled result almost always means the indices and the processed batch got out of sync somewhere in between.