Smart Metadata Reader

The name undersells this node. "Smart Metadata Reader" sounds like the umpteenth SD Prompt Reader clone, and if your images come out of a simple one-click pipeline, that's all it is. But the thing it's actually built for is the workflow you spent a week on: the one where the prompt is assembled by a StringFunction splice, passed through a DeepTranslatorTextNode, cached by ShowText|pysssss, and fed through ControlNet and a detailer before it ever touches a sampler. On that workflow, ordinary readers give you garbage. This one doesn't.

What it actually does

Most prompt readers do one of two things: they parse A1111-style parameters text, or they scan the workflow JSON for every CLIPTextEncode and dump whatever text they find. Both fall apart on modern ComfyUI graphs - the last one especially, because it happily reports the template of an LLM node, a stale branch you disconnected, or a string that never reached the final image. This node reads the metadata as a graph, not a text dump.

Here's the mechanism, grounded in the source: it loads the image via Pillow (PNG, JPEG, WEBP), prefers ComfyUI's embedded prompt metadata because it's closest to the actual executed graph, uses the workflow metadata to supplement UI caches, and falls back to A1111/Forge parameters, JPEG EXIF UserComment, or Civitai metadata. Then it builds an index of the graph and walks backwards from the output nodes to pick the final sampler - not "whatever node happens to be last" - and resolves the positive and negative conditioning chains through adapters for CLIPTextEncode, the pysssss string/showtext nodes, translator nodes, ControlNet passthrough, ConditioningCombine/ConditioningConcat, LoRA loaders, and so on. Anything not wired into that chain - old branches, LLM system_instruction templates, unconnected ShowText caches - is deliberately ignored. That principle is the whole point, and the README is unusually explicit about it.

The inputs that matter

Four of the five knobs have sane defaults; you can leave most alone.

• image - pick from your ComfyUI input directory or upload. That's it.
• parameter_index - which parameter set to use when the A1111/Forge fallback has multiple groups. Keep 0.
• prefer_cached_text (default true) - prefer a cached ShowText result over a node's live text. Leave it on; this is what stops an LLM's prompt template from masquerading as your final prompt.
• include_raw_json (default true) - keep the raw prompt/workflow JSON in the internal parse result.
• max_depth (default 40) - how deep the graph trace goes before it bails on a loop. Bump it only for genuinely enormous workflows.

The outputs

Twelve of them, and you'll mostly use three. positive and negative are the real prompts that hit the final sampler - wire them into a ShowText or a text node and you finally see what your mega-workflow generated. setting is the human-readable summary the author built: filename, model, VAE, LoRA list, seed, steps, CFG, sampler, scheduler, dimensions, status, confidence, and anything unresolved. The rest (image, mask, seed, steps, cfg, width, height, model_name, filename) are the loaded image plus the extracted generation parameters, handy if you want to feed them straight back into a pipeline for an edit or a re-roll.

Installing it

Lightest install in the pack's weight class - it's Python-only with a single dependency:

cd ComfyUI/custom_nodes
git clone https://github.com/CyberShadowX/ComfyUI-Smart-Metadata-Reader.git
cd ComfyUI-Smart-Metadata-Reader
pip install -r requirements.txt

requirements.txt is just Pillow>=10.0.0 - no model downloads, no heavy deps. Or search comfyui-smart-metadata-reader in ComfyUI Manager. Either way, restart ComfyUI and search "Smart Metadata Reader" in the node menu (it lives under the metadata/image category).

Where people get burned

The big one: if the image's metadata is gone, nothing recovers it. Chat apps, image hosts, and "optimizers" strip metadata all the time, and the node will cheerfully report a failed parse - that's physics, not a bug. Second: if it returns PARTIAL, it means an unknown custom conditioning node sits on your final chain and it refused to guess. That's a deliberate design choice (no hallucinated prompts), and the setting output lists the unresolved nodes so you can see what tripped it. Also note it's Phase 1 - Python-only with no in-node text preview yet; the author plans a JS frontend. Minor friction, but reading the setting/positive outputs works fine today.

The honest verdict: if you only ever make simple graphs, a plain reader is enough and this is overkill. If you generate from a complex chained workflow and you're tired of squinting at dumps to figure out which prompt actually made that image, this is the one that gets it right.