DOGMA OptionalSaveImage v2

What it is

A save node with an off switch. enabled on: it writes PNGs exactly like core Save Image, metadata and all. enabled off: it does nothing at all - no file, no folder, no error, and crucially no execution of whatever produces the images it would have saved.

It has no outputs. It's a terminal node, the end of a branch, which is how ComfyUI decides what to run at all.

Why a switch beats bypassing

On a multi-phase pipeline you end up with intermediate outputs you want to inspect while tuning and don't want cluttering your output folder - or paying GPU time for - on the final run. The usual answers are both worse:

Bypass the node. Now ComfyUI has to decide what to do about the branch; in practice bypassing a save node often leaves the upstream half of the graph unreachable and pruned, so you're not just skipping the save, you're skipping the phase. If that's what you want, fine - but it's a bigger change than you asked for.
Delete the node. Now you have to remember where it went, and any downstream wiring it carried goes with it.

A boolean is a much smaller decision. And it's the same pattern the pack uses in three other places - lazy phase switches, a lazy search node, a lazy presence gate - so once you've used one of these, the others read the same way.

How "off" avoids running anything

The images input is declared lazy, and the node's check_lazy_status returns:

['images'] if enabled is true, otherwise [].

That's the mechanism, and it's the interesting bit. A normal required input forces its producer to execute. A lazy input lets the node say "not yet" - or, here, "never" - so with enabled off, ComfyUI never evaluates whatever upstream would have produced the images. Save yourself a VAE decode or a diffusion pass, not just a file write.

When disabled the function returns {'ui': {}} - an empty UI result, no side effects, and no complaint about images being None. That last part matters: it means you can leave the node sitting in the graph with its input unconnected and disabled, and nothing errors.

Inputs

enabled (BOOLEAN, default true) - the switch.
images (IMAGE, lazy) - what to save. It's a required input, so with enabled on it has to be wired; nothing connected and enabled is a validation error, which is the correct behaviour.
filename_prefix (STRING, default DOGMA_V2/01_QWEN) - the same prefix format core Save Image uses, so the slash makes a subfolder under output/. The leading number is the author's convention: number your saves in phase order (01_QWEN, 02_MASKS, 03_RENDER) so the folder sorts the way the pipeline runs.

Outputs: none. It's an output node, which in ComfyUI terms means it always executes - that's what makes it the anchor the engine works backwards from. Its result shows in the node's own preview area, same as Save Image.

Things that catch people

"Off" means off. No preview either. If you switch a save off for a final run and then want to see the intermediate, you have to re-enable it and re-run the phase - there's no cached image to look at, because nothing was produced. (Anything saved on a previous run is still on disk, of course.)

Two of these in one graph is fine, but they're not a folder manager. Each one writes wherever its prefix says; there's no dedupe, no manifest, no "only the latest". For phase-order folders that's what you want.

It inherits core Save Image behaviour, including PNG metadata. The workflow JSON goes into the PNG, same as always - which is how you can drag a saved intermediate back into ComfyUI and recover the graph. If you're doing that on purpose, remember the seed trap the plumbing docs cover: whether the seed in that recovered graph is the one that produced the image depends on your control_after_generate settings, not on this node.

Install

Manager → search DOGMA Nodes (publisher axior), or:

cd ComfyUI/custom_nodes
git clone https://github.com/axior/ComfyUI-DOGMA-Nodes
# restart ComfyUI

requirements.txt declares scipy>=1.10 and that's the whole dependency story; no model downloads, no ComfyUI internals touched. This node imports the core SaveImage class and delegates straight to it, so the output format, metadata and naming are the ones you already know.

The usual caveat for the pack - one author, CPU-validated, no community footprint - barely applies to a save wrapper. The logic is visible at a glance, and the only behaviour worth knowing is the lazy input, which is the same idiom half the ecosystem uses for "don't run this branch".