Load Image For Loopback
The trick is knowing when it refuses to update
- loopback_image
The interesting thing about this node isn't the loading - it's the boolean that decides whether the loaded image is allowed to change. Once you understand update_from_cache, you understand why this pack exists at all.
Image-Loopback-Load is the read-back half of leocbehe/image_loopback. It takes the PNG that Image-Loopback-Cache saved and hands it back to you as a normal IMAGE tensor you can plug into anything that accepts an image: the input_image of an img2img pass, a ControlNet reference, a detailer. The classic loop: generate a frame, cache it, load it back, run a second pass seeded from your own output, and iterate until you're happy. ComfyUI has no native "feed my result back into myself" wire, so people fake it with exactly this save-to-disk / load-from-disk pair.
How it works, and the input that matters
cache_path- folder name under the pack's install dir. It must match whatever the Cache node uses, or the Load reads an old file (or nothing) and you'll spend an hour convinced your graph is broken. Defaultloopback_cache.update_from_cache- default true, and here's the whole trick.true: readcached_img.png, copy it tocurrent_img.png, return it.false: ignore the cache and returncurrent_img.png- the previous frame, frozen.
That freeze exists because of how ComfyUI executes graphs: it re-runs a node when its inputs change, and a loopback that hands back a new image every execution changes its own inputs, which re-runs the graph, which hands back a new image... you get the spiral. update_from_cache=false is your "hold steady" switch - it returns the same tensor every run, so re-executions don't cascade and you can nudge other settings without the whole loop thrashing. Meanwhile the Cache node keeps writing fresh frames in the background; you've just told the Load to stop picking them up. That's also why the pack keeps two files instead of one - the second copy is the memory of "what I last handed out," which is what "hold steady" means.
The output
loopback_image - a float 0–1 IMAGE tensor with a batch dimension, same shape ComfyUI expects everywhere, so it drops straight into an img2img or ControlNet input. Nothing exotic to convert.
Install
Via ComfyUI Manager, search "Image Loopback" (pack title image_loopback), install, restart. Or:
cd ComfyUI/custom_nodes
git clone https://github.com/leocbehe/image_loopback
Restart and you're running. No requirements to pip-install, no models to download, no install script - it leans entirely on torch, Pillow and numpy, which ComfyUI already bundles. Fair warning: this is a single-commit, spring-2025 pack with no community footprint, so there's no battle-tested history behind it. For two utility nodes that's fine; just don't assume it's maintained.
Where people get burned
- The repo commits a
loopback_cachefolder with the author's leftover dev images (two ~1.5MB PNGs). Point the defaultcache_pathat it on a fresh install and your "loopback" starts life as somebody else's picture. Use your own folder name, or delete that directory after cloning. - Cache and Load must agree on
cache_path. Same string in both, and give each workflow its own folder - the filename is hardcoded tocached_img.png, so shared folders overwrite each other. - Remember the cache lives inside the pack install dir, not ComfyUI's
output/. A pack update or reinstall wipes your loop state.
The honest take: this node pair is deliberately dumb - save and load, nothing more. No upscaling, no denoise scheduling, no magic. The actual image work (the KSampler denoise, the ControlNet, the detailer) all happens in the part of the graph you build between the Load and the Cache. The pack just closes the loop so you stop re-importing a file by hand every pass.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| cache_path | STRING | loopback_cache | — |
| update_from_cache | BOOLEAN | true | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| loopback_image | IMAGE | — |