Batch Image Loop Open SunxAI
Your video frames, one at a time
- segmented_images
- FLOW_CONTROL
- current_image
- max_iterations
- iteration_count
- batch_path
If you've ever dragged a video into ComfyUI and tried to restyle every frame like it was one big image, you already know why this node exists. A batch of frames gets denoised as a single tensor, and every frame comes back looking like a slightly different cartoon with no temporal coherence at all. This node's whole job is to stop that: it hands your pipeline one frame at a time and waits for each to finish before the next begins. Frame-by-frame processing, the hard way, made barely less hard.
It's the opening half of a two-node loop pair from upseem/comfyui_sun_nodes, a tiny MIT-licensed pack by a developer going by SunX AI. The README is Chinese-first and the pack ships exactly one feature - this loop - plus an example workflow that is a video-to-anime job: VHS_LoadVideo → this node → your sampler middle → the Close node → VHS_VideoCombine. Two clues tell you what you're actually running: the class name ends in Chen, and the menu category is CyberEveLoop🐰·Chen定制. Translation: this is a customized, renamed fork of the well-known CyberEve loop nodes, with SunX's own fixes bolted on.
How it works
Drop a batch of frames into segmented_images and the node just counts them - that count is max_iterations. On each pass it emits a single frame as current_image and a batch_path pointing at a fresh per-run folder it creates under your ComfyUI output directory (output_dir/batch_id, or loop_batch/batch_id if you leave output_dir empty). You wire current_image into your img2img or style-transfer middle section, then send batch_path, max_iterations and iteration_count across to the Close node. The FLOW_CONTROL output is the trigger that tells Close "one frame done, do the next."
It's strictly serial by design - one full pass through your KSampler per frame, no parallel sampling. That's the point (the README is emphatic about it, and it's what keeps frame N+1 from jumping ahead of frame N), and it's also why a 300-frame video takes 300 times as long as one image. Budget accordingly.
The part everyone misses
The genuinely interesting bit is hidden. On later passes the Close node feeds a previous_image back in, and this node resizes it to match your batch and writes it into the previous frame's slot. So when you enable pass_back on the Close node, your processed frame N becomes the reference for frame N+1. That's how this pack gets the frame-to-frame consistency its README brags about - and it's exactly the thing r/comfyui users get stuck on with the plain CyberEve nodes, where the Open node keeps handing back the original, unprocessed frame no matter what you feed the Close side.
Installation
ComfyUI Manager (search "SunxAI" or "comfyui_sun_nodes"), or:
cd ComfyUI/custom_nodes
git clone https://github.com/upseem/comfyui_sun_nodes.git
Then restart ComfyUI. No model downloads, no heavy dependencies - pyproject.toml declares zero runtime deps, so this is a pure-python drop-in.
Watch out
The loop is synchronous by design, so don't assume it's hung - watch the console for [chen] Loop iteration: N prints and it's clearly grinding through frames. If your processed frames never reach the next pass, pass_back isn't on (that switch lives on the Close node, not here). And keep the FLOW_CONTROL wire running Open → Close: no wire, no loop, it just runs the body once. Be aware the pack is brand new with essentially zero community footprint - treat it as a young utility, not battle-tested infrastructure.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| segmented_images | IMAGE | — | |
| output_dir | STRING | — |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| FLOW_CONTROL | FLOW_CONTROL | — |
| current_image | IMAGE | — |
| max_iterations | INT | — |
| iteration_count | INT | — |
| batch_path | STRING | — |