Image PingPong

A ping-pong loop is the oldest trick in the animation book: play your frames forward, then play them backward, so the end connects smoothly back to the start. No hard cut, no visible jump - just a clip that could loop forever. Image PingPong does exactly that to an image batch, and if you've ever made a GIF or a looping video, you know how much manual frame-bending that normally takes.

The mechanism is dead simple: for each "bounce" it plays the batch forward, then backward. With remove_link_frame on (the default), the duplicated junction frame - the one that appears twice at the turn - is dropped, so the reverse pass doesn't double-play the last frame. That's the difference between a smooth bounce and one that visibly stutters.

The inputs

• image - the frame batch to loop.
• pre_reverse - flips the whole batch before looping. Handy when you want the loop to start at the end and bounce the other way.
• ops_count - how many forward/backward bounces to generate. 0 means "go forever, until frame_count cuts you off."
• frame_count - caps the total output length. 0 means no cap.
• remove_link_frame - true (default) drops the duplicated junction frame at each turn.

So for a 10-frame clip: ops_count=1 gives you the forward pass plus the reverse pass (about 19 frames with the junction removed). ops_count=2 adds another forward-backward cycle, and so on. Output: image, the looped batch, ready for a video save node or a GIF encoder.

The combination that matters

ops_count=0 with a frame_count set is the "make me exactly N frames of seamless loop" mode - the node keeps bouncing until it fills the budget, no matter how long the clip is. That's the one you'll actually want for video work where the target length is fixed. Set ops_count to a specific number instead when you want an exact number of bounces regardless of length.

Why you'd reach for it

Looping is a whole genre in the video-model world - the KB's own history of the field notes that ping-pong looping is precisely the behavior people were asking to keep as they moved from AnimateDiff-era tooling to Wan. It's the fastest way to make an avatar, a texture, a camera-move, or any motion clip read as infinite. There's a catch baked in: it only looks seamless if the first and last frames are close enough that the bounce direction flip isn't jarring - a clip that ends far from where it started will still bounce, it'll just bounce visibly.

Installing it

ComfyUI Manager, search "ComfyUI 1hewNodes", install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/1hew/ComfyUI-1hewNodes

Standard pack note: install pulls the repo's heavy requirements (opencv, rembg, ultralytics...) even though this node is pure tensor reordering.

Gotchas

ops_count and frame_count are both honored, with frame_count trimming the result afterward - set them together and think about which one should win, because if both are positive, the frame count silently caps your bounce count. And keep remove_link_frame on unless you specifically want the repeated frame; off is the mode that produces the stutter people post about. If your loop looks like a rubber band snapping back, your clip's start and end frames just aren't loop-friendly - no node can fix that.