(deforum) Load Cached Image

A Deforum render is a loop, and loops have a problem: by the time a later node needs something from an earlier frame, that frame's tensors have already gone out of scope. The cache nodes are the pack's answer - a scratchpad where the loop can drop an image, a latent, or a string under a numbered slot, then pull it back out when needed. This node is the "read" half of that for images.

Its display name - Load Cached Image - tells you exactly what it does: it fetches the image (and its mask) that a Cache Image node wrote to slot cache_index earlier in the run. If you've ever wanted "use frame 5 as the init for frame 40" without re-encoding or file juggling, this is the plumbing.

Inputs and outputs

The only input is cache_index, an integer from 0 to 16. Slots beyond 16 simply don't exist in this pack, so if you need more scratch space, change your workflow rather than the number.

It outputs two things:

• IMAGE - the cached image tensor, detached and cloned so later nodes can't mutate what the cache holds.
• MASK - the alpha channel of that same image. Convenient if you cached an RGBA image and want the transparency as a mask for compositing.

How it behaves

The cache is in-memory and global to the pack (gs.deforum_cache), not per-node. That's the trap to watch: the cache isn't tied to the workflow that wrote it, so stale values from a previous run can linger. There is one safety valve - if the pack's global reset flag is set, this node returns None for both outputs instead of serving stale data. If you're getting empty outputs after changing a video or resetting a run, that flag is usually why.

Installation

Part of the Deforum Nodes pack:

cd ComfyUI/custom_nodes
git clone https://github.com/XmYx/deforum-comfy-nodes.git

Restart ComfyUI, or install "Deforum Nodes" by XmYx from ComfyUI Manager. Note that this read-side node has no real use without a Cache Image node upstream, so you'll be deep enough in the pack to want the full backend installed (Python 3.10 plus the deforum[comfy] packages) before relying on it.

Practical notes

• Pair it with a frame_idx-driven selector if you want "cache the frame at index N" rather than "cache the last frame" - the cache is keyed by the index you pass to the write node, and this node just asks for it back.
• Because the cache is a singleton, two separate workflows sharing one ComfyUI session can step on each other's slots. Give each workflow its own cache_index range and you'll avoid a genuinely confusing bug.
• If a run leaves the cache with an image you don't recognize, that's stale data, not corruption - a fresh queue (or a reset) clears the slate.