Save Image Websocket

If you've ever driven ComfyUI programmatically - POST a prompt, listen on the WebSocket, get an image back without ever touching the output folder - you've probably run into the stock SaveImageWebSocket node. It streams the finished PNG straight down the same socket you're already using to watch progress, which is great, except it can't do the one thing regular Save Image does automatically: bake the prompt and workflow into the file. This node fixes exactly that gap. Same job, same wire-once-and-you're-done simplicity, but with an enable_metadata switch that stamps the generation data into the image before it goes out over the wire.

Why that matters: when ComfyUI writes a PNG to disk normally, it embeds the full workflow JSON as metadata - drag that image back into the canvas later and the entire graph rebuilds itself. It's become a real community norm ("workflow included" is basically an expectation now). The vanilla websocket-save node throws that away, because it's built for speed, not archival. This node lets you have both: stream the bytes with zero disk I/O, and still get a self-documenting image on the other end if you flip the switch.

How it works

It's a terminal node - plug your decoded image in, nothing comes back out in the graph. When it executes, it converts the tensor to a PNG (optionally with the prompt/workflow chunk written into the metadata) and pushes it as a binary frame over the same client WebSocket connection your app opened to submit the job in the first place. There's no HTTP polling of /history or /view, no output file to clean up later - the image exists only as bytes on the socket, which is exactly what you want for a backend service that just wants the result and doesn't care about ComfyUI's filesystem.

The inputs and outputs that matter

• images (required, IMAGE) - wire this straight from your VAE Decode. Batches work; you'll get one image out per item.
• enable_metadata (optional, BOOLEAN, default False) - turn this on to embed the prompt and workflow into the streamed PNG. Off by default, so if you're expecting a reproducible image on the client side and it's not there, this is the first thing to check.

No outputs - it's an output node (is_output_node: true), same category as Save Image. It's meant to be the last thing in the chain, not something you keep building on.

How to install it

Search ComfyUI-HX-Pimg in ComfyUI Manager and install, or do it by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/huixingyun/ComfyUI-HX-Pimg

Restart ComfyUI. That's genuinely the whole install - the README is three lines, there's no requirements.txt to worry about and no model to download. It's pure Python glue on top of ComfyUI's own image-saving machinery.

Worth knowing going in: the author built this pack for their own internal tool ("pimg," a ComfyUI controller they run), not as a general-audience library. That's not a knock - it works fine and does one clear thing - but don't expect a big README if something's unclear. You're reading the source for anything beyond what's covered here.

Common issues & troubleshooting

Nothing shows up when you run this from the regular UI. That's expected - this node has no preview widget and doesn't write to /output. It's built for a client that's actually listening on the WebSocket and parsing binary frames, not for eyeballing results in the browser. If you just want a preview while building the workflow, use a normal Preview Image node instead and swap this in only once you're wiring up your API client.

Your client can't find the image after the run. People hit this constantly with the stock websocket-save node too - there are three separate ways to get an image out of ComfyUI (poll /history + /view, read binary WebSocket frames, or the browser's live preview), and they don't overlap. If you're using this node, you must be reading binary frames on the same connection you used to submit the job - checking /history afterward won't find anything, because nothing was ever written to disk.

Metadata isn't in the file you received. Check enable_metadata - it defaults to False, so you have to opt in. If you're building something where recipients might want to reload the image as a workflow later (support tooling, a shareable output, debugging a user's run), turn it on; the cost is a slightly larger PNG, not a meaningful one.

Format is whatever the underlying save call does - don't expect a format dropdown. This node family serializes to PNG; there's no exposed toggle for WEBP or JPEG in the schema, so if you need a different container you're converting client-side after you receive the bytes.