Badge Color ID Map Cache Store V1 (DAELab)

What this is for

Generating a Color ID Map costs a real API call. Doing it again because ComfyUI decided to re-execute a downstream node costs the same real money for an identical PNG. This node exists so that never happens: it takes a freshly generated map, writes it to disk under a key that describes exactly how it was produced, and lets the generator check that key next time.

It's filed under DAELab/Badge/App/Internal, and the label is accurate - this is plumbing the pack's own front end wires up, not something you'd typically add by hand. But the mechanism is worth understanding, because it explains a couple of behaviours that otherwise look like caching bugs.

How it works

Two required inputs: generated_map (the image) and cache_key (a string, forced to be a wired input, so it always comes from the generator's own output).

It validates the key - exactly 64 lowercase hex characters, i.e. a SHA-256 digest - and stores the image as <output>/…/<key>.png. The cache_key is passed through unchanged, and a status JSON comes back out saying state: ready, cache: stored, the key, and the path it wrote.

The interesting part is IS_CHANGED. The node's cache invalidation is only the key string; the image itself is deliberately ignored (del generated_map). So if the key doesn't change, ComfyUI considers the node unchanged and skips it, even if you queued again with a new byte-identical tensor. That's the point: the key isn't a timestamp, it's a description.

The key that generates it - from the companion Color ID Map node - digests the master image, the prompt version, the prompt text itself, the model name, the size, the background mode, the quality setting, the seed and a manual map_revision counter. Change any of those and you get a new key, a new file, a new paid generation. Leave them all alone and you get the existing PNG, for free, forever, even across restarts.

The inputs and outputs that matter

In practice you set nothing. generated_map comes from the map generator's color_id_map output, cache_key from its cache_key output. Both are required, and the force-input on the key is intentional: it stops you typing a key that doesn't correspond to an image.

Outputs are color_id_map (the image passed through as float), cache_key (pass-through) and status. Wire the image onward to whatever needs the map; read status when you want to confirm something was actually written.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/TeutonicMepheles/ComfyUI-DAELab-Custom-Nodes-Library.git
# restart ComfyUI

Pure Python plus Pillow; no models, no extra packages. The cache lands under ComfyUI's output directory, so it survives restarts and gets picked up by any backup you already run on output/.

Where people get burned

A hand-typed key. Invalid Color ID Map cache key means the string isn't a 64-character hex digest. That's the guard against pointing a store at a filename you invented.

Expecting a changed map to be picked up. If you go back and edit the master image in a way that produces a different picture but you didn't change the map node's inputs, you get the old cached map. That's what map_revision is for: bump it, get a fresh generation. Same story if you upgraded the pack and the prompt version changed - new key, new call, and the old file stays on disk unused. Nothing deletes old entries for you; periodically clear the cache directory if you care about disk.

Mixing models. The key includes the model name, so silently switching between gpt-image-2 and gpt-image-2.5-sunburst invalidates the cache - the pack's own notes warn that older maps need regenerating after that switch. It's the right behaviour, it just means "why is it charging me again" has an answer: you changed something the key covers.

Assuming this makes the edit calls cheap. It doesn't. Only the map generation is cached; each masked material or semantic edit is still a live, billed call. This node saves you the map, not the work.