APZmedia Fast Image Save Node

If you've ever rendered a 1,000-frame image sequence and watched ComfyUI sit there chewing on the save step, this node is aimed straight at you. The pitch is one sentence: saves images faster than the default Save Image node by skipping the workflow embedding and leaning on OpenCV directly. That's the whole game, and it doesn't apologize for it.

Here's the tradeoff, up front, because it's the thing people miss: ComfyUI's built-in Save Image embeds the entire workflow JSON into every PNG it writes. That's how drag-an-image-back-into-ComfyUI reconstructs your graph - it's a real feature, and the community built a whole sharing culture around it. But for a high-volume batch, writing that metadata thousands of times is overhead your disk doesn't need. This node drops it. No workflow in the PNG, ever. If you need reproducible embedded workflows, use the standard node; if you need throughput on a frame sequence, this one wins. There was no real middle ground before this - people doing huge JPEG batches kept complaining that custom save nodes were slower than the default, which is the exact niche this pack targets.

How it actually works

The mechanism is a lot less exotic than the README's marketing. It picks a backend per format - OpenCV for PNG, TurboJPEG for JPEG (claimed 2–3x faster than OpenCV), PIL or native webp for WebP - and auto just picks the fastest one that's actually installed. Parallel saving runs the encode/write calls through a thread pool, which helps I/O-bound disk writes more than you'd think. Filename generation is the quietly clever part: instead of stat-checking each file for collisions (O(n²)), it lists the output directory once and does set lookups. Nothing here calls an API or needs a key; it's pure local code.

One honest gotcha I'll flag since I read the source: the dpi input is accepted (defaults to 300) but the current encode path never actually writes DPI metadata. The README says it does. It doesn't yet. Ignore it - it doesn't touch your pixels either way.

The inputs that matter

The node passes a long list of knobs, but you'll actually touch these:

• images - your batch, straight from VAE decode or whatever's upstream. It passes through untouched on the IMAGE output.
• output_path - defaults to [time(%Y-%m-%d)], which becomes a dated folder under ComfyUI's output directory. Absolute paths work too.
• filename_prefix, filename_delimiter, filename_number_padding - the usual prefix_0001.png naming; padding 1–10, numbering can start at 0 or 1.
• extension - png / jpeg / webp, and quality (1–100, default 100) plus optimize_image for the compression side. lossless_webp does what it says.
• parallel_save + max_workers - on by default with 4 workers. Tune by storage: 4–8 on SSD/NVMe, 2–4 on HDD, 1–2 on network storage. Crank it past that on a spinning disk and you get contention, not speed.
• backend - leave it on auto unless you know better. The dropdown only lists TurboJPEG if the native library is present.

Outputs: IMAGE (your batch, unchanged) and STRING (the full path of the last saved file - wire that into a text/display node if you want to log where things landed).

Installing it

Easiest via ComfyUI Manager - search "APZmedia Fast Image Save" and hit install. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/APZmedia/APZmedia-comfyui-fast-image-save.git

Then restart ComfyUI. The node lands under the APZmedia Fast image save category. It'll try to auto-install PyTurboJPEG and webp on first load, which is where the one real gotcha lives: PyTurboJPEG is only a ctypes wrapper and needs the native libturbojpeg on your system, which pip can't give you.

# Debian/Ubuntu
sudo apt install libturbojpeg0
# macOS
brew install jpeg-turbo

If the native library is missing, the node logs a warning and quietly falls back to OpenCV/PIL for JPEG. Nothing crashes - you just don't get the TurboJPEG speed until you install it.

Common issues

• No turbojpeg option in the backend dropdown - that means libturbojpeg isn't on your system. Install it, restart.
• Images won't reconstruct a workflow when dragged back in - expected, by design. That's the whole point.
• Files keep getting numbered up instead of overwriting - overwrite_mode defaults to false; flip it to true if you want stable names.
• dpi doing nothing visible - see above, it's accepted but not written yet. Not a bug you need to fix.

For a long sequence or animation frame dump where nobody needs the workflow baked in, this is the save node I'd reach for. Just don't pretend the metadata tradeoff doesn't exist.