RsaveImage

You already know ComfyUI's PNGs aren't just pictures - drag one back onto the canvas and the whole workflow rebuilds itself, because the graph is embedded in the file's metadata as text chunks. RsaveImage exploits that same pipe to stash arbitrary data in your saved image's metadata. Not just the node graph: whatever you feed it, from a string to a tensor to a whole batch of encoded images.

Here's the mechanic, grounded in the source. The node takes anything on its anything input (typed *, so any socket works), base64-encodes it as a .npy blob, and injects it into the run's extra_pnginfo under a ResourcesSave key. ComfyUI's SaveImage writes that whole dict into the PNG's text chunks, so the blob rides along in the file. It also returns a throwaway placeholder image - a 1-pixel-tall strip decoded from a hardcoded WebP - and you wire that into a SaveImage node so there's actually a file to hold the metadata. The node even jacks up Pillow's max text-chunk memory to 12 GB, a hint that the author expects some chunky payloads.

Why you'd bother

Data that rides inside a PNG travels with the file and doesn't clutter your output folder with loose .npy files. Pair it with the companion ComfyUI-ResourcesLoad pack and you can stash, say, the exact latent that produced an image, then pull it back out of the PNG later - the image file becomes the envelope. Feed it the output of RsaveImageC and you can embed small encoded images (webp bytes, quality 100) inside the metadata instead of as separate files.

The placement warning is real

The README is blunt about it: RsaveImage must sit at the end of the workflow. Because extra_pnginfo is a bag shared by every output node in that queue, the moment RsaveImage injects its key, other SaveImage nodes in the same run can pick up the metadata too - your earlier, innocent output PNGs end up carrying a blob you didn't mean to give them. Put it last, right before the save you actually want to tag.

The honest trade-offs

This is a hack, and it's worth knowing that going in. The placeholder image it returns is a junk strip, not a real thumbnail; the metadata is a base64 blob that no image host or CivitAI parser understands; and base64 inflates everything by about a third, so multi-megabyte tensors make for bloated files and slow reads. Keep payloads small.

And remember the metadata rules from the wider ecosystem: the data is welded into PNG text chunks, so it survives byte-for-byte copies and dies the instant the image is re-encoded - JPEG or WebP conversion deletes it for good, as does most posting-through-social recompression. Conversely, whatever you stash travels with the file wherever you share it. Post that PNG to a host that keeps originals and your embedded data goes public. Small payloads, keep the PNG, mind where you post.

Install

ComfyUI Manager (search ComfyUI-ResourcesSave) or:

cd ComfyUI/custom_nodes
git clone https://github.com/MrFrankHobbidy/ComfyUI-ResourcesSave

then restart. No extra dependencies beyond what ComfyUI ships. If your saved PNG seems suspiciously heavy, you put too much in the metadata. If the data won't come back out, that's what the companion ResourcesLoad node is for - and if the file went through a re-encoding host first, it's gone, and no node will resurrect it.