PBR Saver (with Metadata)

PBRSaver writes your material maps to disk. PBRSaverWithMetadata writes them to disk with the entire workflow embedded in each PNG. Drag any saved file back into ComfyUI and the whole graph that produced it reconstructs - which is the ecosystem's killer feature (see the "workflow included" norm), applied to material maps instead of generated images.

When does that matter for textures? Two situations. First, reproducibility: a material set built three weeks ago with settings you've forgotten - drag the albedo PNG back in and the exact pipeline is right there. Second, collaboration: someone asks "how did you get that weathered roughness?" and the answer ships inside the file itself. The pack's own pitch: "allows drag-and-drop back into ComfyUI to recover the workflow."

How it works

Everything is inherited from the plain PBRSaver - same pbr_pipe, base_name, output_path, enumeration_mode, starting_number, and the same auto-naming (bricks_albedo_001.png…). The difference is two hidden inputs the node taps into: ComfyUI's PROMPT and EXTRA_PNGINFO, which hold the workflow graph and metadata for the current generation. It embeds those into each saved PNG.

Two honest limits to know up front:

• Metadata only works for PNG. The file_format dropdown is restricted to png and png16 - no jpg, exr, or tiff here, because the workflow embedding is a PNG mechanism. If you need EXR precision for height maps, you'll have to use the plain saver and give up the embedded workflow.
• The output images batch lets you preview what you saved, same as the plain version.

Installing it

Part of TextureAlchemy:

cd ComfyUI/custom_nodes
git clone https://github.com/amtarr/ComfyUI-TextureAlchemy

or ComfyUI Manager (search "TextureAlchemy"), then restart. Under Texture Alchemist → Pipeline. It's an output node like its sibling. No extra dependencies.

Which one should you use?

If the material is destined for a game engine or renderer, the embedded workflow is invisible noise to them - use the plain PBRSaver and save as whatever format the engine wants (including EXR for displacement). If the material is yours to iterate on - a library you'll revisit, a set you'll share with people who might want to tweak it - the metadata version is strictly better, and the only real cost is being locked to PNG. My rule: use the metadata saver for your working library, the plain saver for anything going into a pipeline that needs EXR or specific formats.