Superside Save Image

ComfyUI already ships a SaveImage node. So why does this pack bring its own? Because this pack's whole philosophy is that a workflow built entirely from comfyui-superside-nodes should depend on nothing else - not even core's own node set. Superside Save Image is the pack's faithful reimplementation of core SaveImage, with the same contract and the same behavior: write images to ComfyUI's output folder as PNGs with workflow metadata baked in.

How it works

It's a thin but real wrapper around ComfyUI's own folder_paths machinery - the same save path logic core SaveImage uses, so files land in your normal output directory and existing scripts that watch that folder keep working. It writes PNGs, embeds the workflow (and prompt) metadata into the file so you can drag the PNG back into ComfyUI to recover the graph, and returns the images batch through its output so you can keep wiring downstream.

Under the hood there's also a sibling preview variant in the same module, and the class is registered with OUTPUT_NODE semantics - which is the ComfyUI-ese for "this node is a terminal point; run the graph to it." If a graph has nothing that consumes its output, ComfyUI still marks it as complete because a save node always counts as an end.

The inputs that matter

• images - the IMAGE batch to save.
• filename_prefix - the name prefix, default ComfyUI. Files come out as <prefix>_<counter>.png and the counter auto-increments so you don't overwrite prior runs. Set it to something meaningful per workflow (retouch_pass1) and finding your outputs later gets a lot easier.

Output: images, passed through unchanged.

Installing it

It's in the comfyui-superside-nodes pack - install once and restart:

cd ComfyUI/custom_nodes
git clone https://github.com/Superside/comfyui-superside-nodes.git
cd comfyui-superside-nodes
pip install -r requirements.txt

Find it under the Superside category. It's a local node: no API key, no network, no model downloads.

Should you actually use it?

Honest answer: if you're building a mixed workflow with other packs, core SaveImage does this identically and there's no reason to switch. Where this node earns its keep is the edge case the pack was designed for - a workflow that must be fully self-contained on this package alone, or a deployment (like a sandboxed or Replicate-style export) where pulling in an extra core dependency isn't wanted. Think of it as insurance for portability rather than an upgrade. The one behavior to remember either way: output is always PNG, so if you need JPEGs for size, you'll want to convert downstream rather than expecting this node to offer a format option.