🍒LoadImage_Metadata / 加载workflow图片

LoadImage_Metadata answers a very specific question: "what's written inside this image file?" It takes a file path - not a connected image tensor - opens the file with PIL, and hands back everything PIL found in the file's metadata as a dict. That's the ComfyUI workflow blob, the A1111/Civitai Parameters string, any text chunks, whatever the file carries. If you've ever downloaded an image and wanted to know whether the workflow is still in it before you trust it or re-share it, this is the node.

This matters more than it sounds. The whole workflow-sharing culture runs on PNG metadata - the graph that produced an image gets embedded in the file, and drag-the-image-back-in reconstructs the pipeline. But metadata is fragile: it survives a save in the same tool, and gets silently stripped by most photo editors, image hosts, or even a re-compress. So the node's real use is a verification step: confirm a file still has its generation data before you build a workflow around it.

How it works

The mechanism is embarrassingly simple, which is the point. It reads PIL.Image.open(image_path) and returns image.info - the raw metadata dict PIL parsed from the file's chunks. No API, no model, no key. It doesn't decode the pixels at all, so it's fast even on huge files, and it works on PNG, JPEG, WebP, whatever PIL can open. The output is a single DICT (labeled 输出元数据, "output metadata").

The one input

• image_path (STRING) - the path to the image file on disk. It's a text field, not a ComfyUI image input, so you'll type or wire an absolute path like C:/ComfyUI/output/shot_001.png or /home/you/ComfyUI/output/shot_001.png.

Installation

Part of ComfyUI_KimNodes, so it arrives with the whole pack:

cd ComfyUI/custom_nodes
git clone https://github.com/wjl0313/ComfyUI_KimNodes

Restart ComfyUI. Zero extra dependencies - it's PIL and the standard library.

Common issues

The big one: if the path doesn't exist, the node raises a FileNotFoundError and returns None instead of a dict. Any node downstream that expects a real dict will then error cryptically - so check your path first. Second, this node only reads metadata; it won't show you the pixels (there's a separate Load Image node for that), and by design there's no image preview here. Third, some chunks come back as binary bytes, not text - a compressed workflow blob can show up as a bytes object, and if you try to feed that raw dict into a node that expects strings, you'll trip over it. Usually you want to extract the Parameters or workflow keys and work with those, often by passing the dict into this pack's Add_ImageMetadata or a text display node. It's a small, honest utility: give it a path, read the file's life story.