LoopStart_IMAGE

LoopStart_IMAGE is the front half of the pack's feedback rig - the part of the "loop" that decides which image the chain starts with this time around. It takes a starting image and the shared LOOP token, and returns the image that the rest of your pipeline should run on. Its whole trick is picking between the initial frame and the stored result of the previous iteration.

Here's the mechanic in full: the pack's Loop node hands out a LOOP object, and LoopEnd_IMAGE writes the latest output image onto it as loop.next. When this node runs, it checks whether that attribute exists. If a previous iteration stored a next image, LoopStart_IMAGE returns it - so your chain starts from where the last pass ended. If not (first iteration), it falls back to the first_loop input. That's the "loop": a mutable object passed by reference, consulted at the start of every execution.

The sneaky part is IS_CHANGED. This node overrides it to return id(loop.next) - the memory address of whatever image is currently stored. ComfyUI calls IS_CHANGED to decide whether to re-execute a node; a new stored image means a new id means the node is "changed," which forces the downstream graph to run again. The loop keeps going precisely because the stored frame keeps changing. No stored frame, and the whole thing just sits there on the first image.

Inputs and output

• first_loop - an IMAGE, the initial frame for iteration one.
• loop - the LOOP token from the Loop node (carrying the stored state).
• Output: an IMAGE - either the last stored frame or first_loop, depending on whether a previous iteration stashed one.

Where it fits

The intended chain: DragNUWA Run outputs 14 frames → Get Last Image pulls frame 14 → LoopEnd_IMAGE stores it → LoopStart_IMAGE picks it up next run → drag again. Each pass extends the animation by one clip's worth of frames, and you stop it by stopping the queue.

The honest problems

There's no counter, no max-iterations, no reset button. If the loop object retains a next from an earlier graph execution, you can get a stale frame sneaking in at the top of a fresh run. And because the state lives on one shared Python object, two of these rigs in the same graph will stomp on each other's next. If you're looping for real - like, "run until I say stop, cleanly" - you'd be better served by the dedicated loop-and-queue tools in other packs (WAS, efficiency nodes, or the VHS batch approach) than by this. But for the specific job of "keep dragging the same scene past 14 frames," it works, and now you know why it sometimes doesn't. Feed it through Get Last Image on the way back and you've got the full rig.