Batch Image Loop Close SunxAI
The node that actually finishes your loop
- flow_control
- current_image
- result_images
- output_path
The Open node feeds your frames in, but the loop doesn't actually happen until Close says so. This is the other half of the pair from upseem/comfyui_sun_nodes - the collector. It saves every processed frame, keeps the recursion rolling, and hands you a finished batch of images at the end. In the pack's example workflow this is the node VAEDecode pours your processed frames into and VHS_VideoCombine re-encodes back into a video.
How it works
Each pass, Close receives your processed frame as current_image and writes it to the folder the Open node created - batch_path, saved as zero-padded PNGs (00000.png, 00001.png, …). Two things make that smarter than it looks. First, it skips files that already exist, so a crashed run won't clobber the frames it already got right. Second, when iteration_count hits the last frame, it loads every PNG back into a single IMAGE tensor and returns it as result_images along with output_path. If it's not the last frame, it uses ComfyUI's GraphBuilder machinery to clone the subgraph between Open and Close, bump iteration_count, and expand the graph one more round - the same "Recurse" pattern Impact Pack's loop and a few other packs rely on. The loop isn't magic; it's N stitched-together copies of your middle section.
The inputs that matter
Most of what this node takes in comes straight from the Open node, and you never touch it: flow_control (the FLOW_CONTROL output), max_iterations, iteration_count and batch_path. Wire those across, plug your finished frame into current_image, and you're done.
The one input you'll actually toggle is pass_back, a boolean, off by default. Flip it on and each processed frame gets pushed back into the next iteration through the Open node's hidden previous_image input - resized to match and written into the prior frame's slot. That's what makes a frame-by-frame style run keep its look between frames instead of wobbling every single one. If you're processing each frame in isolation with no temporal dependence, leave it off; you'll save memory and time.
The outputs
result_images is a fresh batch of your processed frames in order, at full resolution - wire it into VHS_VideoCombine to re-encode to video, or a SaveImage to dump the stills. output_path is just the folder it all landed in, handy if you want to grab the PNGs directly.
Where people get burned
The classic loop trap: try to feed your processed frame back into the sampler or ControlNet yourself and ComfyUI slaps you with a validation error or an "infinite loop detected" warning. The loop machinery only passes data back through its own previous_image channel - hand-wiring a feedback edge inside the loop body trips validation every time. If you need the previous frame influencing the next, pass_back is the sanctioned route.
Because frames hit disk as it goes, a run that dies on frame 40 of 300 leaves 00000–00039 sitting in the output folder. You can trim your input batch and resume from there, or just grab the PNGs and re-encode. Handy. Install is the same as its sibling: ComfyUI Manager (search "SunxAI"), or git clone https://github.com/upseem/comfyui_sun_nodes.git into custom_nodes, then restart. No models, no dependencies. Just keep expectations level - this pack is brand new, with zero community footprint to lean on when something's off.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| flow_control | FLOW_CONTROL | — | |
| current_image | IMAGE | — | |
| max_iterations | INT | — | |
| iteration_count | INT | — | |
| batch_path | STRING | — | |
| pass_backopt | BOOLEAN | false | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| result_images | IMAGE | — |
| output_path | STRING | — |