Loop

Loop is the strangest node in this pack, and I'll be straight with you: it's a hack, and it's only sort of a loop. It has no inputs and returns a single LOOP-typed value that is literally itself - the node object. All of its logic lives in its two companions, LoopStart_IMAGE and LoopEnd_IMAGE, and what they implement isn't a real loop at all but a feedback mechanism.

ComfyUI graphs are directed acyclic graphs. You cannot draw a wire from a node's output back into its own input; the graph model forbids cycles. So the pack smuggles state through the LOOP object instead. LoopEnd_IMAGE takes the image you want to carry forward and stores it on the loop object as an attribute (loop.next = image). LoopStart_IMAGE, at the start of the next execution, checks whether that attribute exists - if the loop object has a next set, it returns that instead of its first_loop input. A mutable Python object passed around by reference does the job a cycle wire can't.

How the "loop" actually executes

The trick that makes the graph re-run is LoopStart_IMAGE's IS_CHANGED hook, which returns the id() of the stored next image. ComfyUI checks IS_CHANGED to decide whether a node needs re-execution; when the id changes because LoopEnd_IMAGE stuffed a new frame in, the start node is marked changed and the graph runs again. So the "loop" is: run the chain, end node stores the new frame, changed-check fires, chain runs again with the stored frame as input - repeat until you stop the queue.

It's clever, and it's also fragile in the ways you'd expect from state stashed on a Python object. If the loop's stored next doesn't get reset, a later run can pick up a stale frame from a previous execution. It doesn't have an iteration counter, so you can't say "loop 5 times" - you control it by watching and stopping the queue. And because it's single mutable state shared by reference, two loops in one graph will trip over each other.

When to use it

Honestly: only if you specifically want DragNUWA's frame-chaining behavior and you're okay babysitting it. The supported pattern is image-to-video iteration - generate 14 frames, take the last frame (via Get Last Image), feed it back through LoopEnd_IMAGE, and let the loop re-run so the motion continues. For most people, a manual chain of two or three DragNUWA Run nodes with Get Last Image between them is simpler, more predictable, and does 90% of what the Loop rig does without the statefulness. The Loop node is the pack acknowledging that people want iterative animation - just don't expect it to feel like a proper loop construct, because it doesn't.