Image Info Fallback

Image Info Fallback merges two image_info bundles so that whichever is more complete wins, field by field. The primary image_info keeps everything it has; only the gaps get filled from fallback_image_info. It's inheritance for generation settings - like Image Info Defaults, but instead of falling back to widget values you type, you fall back to another recipe.

The use case, concretely

Say you have a workflow that loads a reference image with Image Reader. The restored image_info carries that image's prompt, model, sampler, and LoRA stack - its whole recipe. But it might be missing things: no negative prompt saved, or no size, or an older model selection you want to override. Meanwhile you have a "house style" bundle - your usual negative, your default sampler settings, your preferred model - sitting in a Defaults node or a saved template.

Image Info Fallback is how you combine them: the reference image's recipe wins wherever it has values, and your house style fills the rest. You get the look of the loaded image with the discipline of your own defaults, without either side overwriting the other.

How the merge behaves

Three details matter, straight from the README:

• Missing fields only. Anything the primary has, the primary keeps. No overwriting of existing values.
• Extras are merged key-by-key. Missing keys come in from the fallback; existing keys are preserved. So the two extras dictionaries combine rather than one replacing the other.
• The LoRA stack has a three-state rule. It's supplemented only when missing or None. An explicit empty list means "no LoRA" and is preserved - the pack's way of distinguishing "not set" from "deliberately empty."

That last rule is the one to remember, because it means you can use an empty list to prevent a fallback LoRA from leaking in, which is exactly the situation that normally drives people crazy with metadata reuse.

The inputs

image_info (required) is your primary recipe - its values win. fallback_image_info (optional) supplies the missing pieces. Output is the merged image_info. Simple enough that the only real question is which side you wire where, and the answer is: primary wins, fallback fills.

A note on workflow design

This node rewards a little thought up front. If every run starts from a reference image, Image Reader → Image Info Fallback → Image Info Context is a natural spine, with your defaults node feeding the fallback socket. Build that spine once, and every reference image you load inherits your workflow's conventions automatically. It's one of those nodes that seems trivial on paper and ends up carrying the whole "reuse" philosophy of the pack.

Installing it

Part of the ComfyUI-Info-Prompt-Toolkit pack. ComfyUI Manager - search "Info Prompt Toolkit" - or:

cd ComfyUI/custom_nodes
git clone https://github.com/kinorax/comfyui-info-prompt-toolkit.git
cd comfyui-info-prompt-toolkit
pip install -r requirements.txt

Restart ComfyUI. No model downloads. Small single-author pack (GPL-3.0) with a modest community footprint - metadata inheritance is its quiet centerpiece.