Mie Loop State Set Image Batch 🐑

This is the node you reach for when a loop needs to build up a batch of images one pass at a time - generating a frame per iteration and wanting all of them at the end, not just the last one. It's the batch-aware sibling of Set Image: where that node overwrites a single stored image each pass, Set Image Batch is built to accumulate.

How it fits in. MieNodes carries loop state through your graph as a custom object, MIE_LOOP_CTX. Set Image Batch takes that context, a key, and the current pass's image, and returns an updated loop_ctx - plus a second output, count, that isn't on the plain Set Image node. Reading the schema, count is the giveaway: this node is meant to grow a batch under that key rather than replace it outright, and count tells you how many images have piled up so far. That's exactly the number you'd want to check against a target frame count to decide whether your loop should keep running or exit.

Put concretely: generate frame N, feed it into Set Image Batch, get back count = however many frames you've collected total. Wire that into your loop's exit condition ("stop once count hits 60") instead of hard-coding a fixed iteration limit, and the loop naturally handles cases where a frame gets skipped or retried.

Inputs and outputs.

• loop_ctx (required) - from another Loop-category node in this pack; the type is enforced.
• key (default feedback_image_batch) - the label the accumulating batch lives under. Distinct default from Set Image's feedback_image, which is a hint the two are meant to coexist for different purposes (a single "reference" image versus a growing "collected frames" batch) in the same loop.
• image (required, IMAGE) - the frame from this pass to add to the batch.

Outputs: the updated loop_ctx, and count (INT) - how many images are stored under that key after this write.

Installing. ComfyUI Manager: search ComfyUI_MieNodes. Manual: cd ComfyUI/custom_nodes && git clone https://github.com/MieMieeeee/ComfyUI-MieNodes, restart. No models needed - this is pure state bookkeeping over tensors already in memory.

Honest caveat: the Loop category isn't in the README at all, and the accumulate-versus-overwrite behavior described above is inferred from the presence of the count output and the node's naming, not confirmed against author documentation or source. It's the sensible reading of the schema, but if your images come back stacked differently than expected (say, all frames replaced by the newest one instead of appended), that's the assumption to re-check first.

Troubleshooting.

• count doesn't grow as expected. Confirm the loop_ctx flowing into this node each pass is the one actually being updated and carried forward from the previous pass - feeding it a stale or reset context will make the batch look like it's stuck at one image.
• Different image resolutions across passes. If your per-iteration generation step changes output size, batching mismatched resolutions together can break whatever consumes the batch downstream (most nodes expecting an IMAGE batch assume uniform dimensions). Pin resolution across the loop if this matters to you.
• Memory grows the longer the loop runs. A batch that accumulates full-resolution frames for dozens or hundreds of iterations is exactly as expensive as it sounds - keep an eye on VRAM/RAM if you're chaining a long sequence, and consider downscaling frames before they go into the batch if you don't need full resolution until the end.
• loop_ctx type error. Something other than this pack's own context object is wired into that input.