Superside Save Image With DPI (TIFF/PNG/JPEG)

Why a save node with a DPI dropdown exists

Here's the thing nobody tells you when you export your first print image: your file has pixels and it has no idea how big it is. DPI is the note you leave for whoever opens it - a printer, a layout tool, InDesign, the client's designer - telling them how many of those pixels to pack into an inch.

Without it, the receiving software guesses, and it usually guesses 72. A 3000-pixel-wide render read as 72 DPI "prints" at 41 inches across. Same file read as 300 DPI prints at 10 inches. Nothing about the image changed; only the instruction attached to it did.

This node writes that instruction and then tells you the resulting physical size. It's the natural partner to Superside Tile Upscale in the same pack, which reports its finished size at 300 DPI and hands you the image - and it's a port of the same author's work, comfyui-tile-upscale-AM (Aaron Amortegui). The default filename_prefix of tile_upscale gives away what it was written for.

How it works, per format

The DPI goes somewhere different in each container, and the node handles all three:

• PNG - a pHYs chunk holding pixels per metre with the unit flag set to metres. The node doesn't trust PIL to add it; it saves the PNG to memory, then splices the pHYs chunk in by hand right after IHDR, precisely so it's present regardless of PIL version.
• TIFF - the XResolution/YResolution tags with LZW compression. This is the print-handoff format.
• JPEG - the JFIF DPI fields, written at your chosen jpeg_quality.

DPI does not resize, resample, or add detail. The tooltip says it flatly: "DPI metadata only - does not resize or add detail." If your image is soft, this node will not fix that; run it through an upscaler first, then set the DPI.

Inputs and outputs

Required: image, filename_prefix, dpi (72 / 150 / 300 / 600, default 300), format (png / tiff / jpeg).

72 is screen/web, 150 draft print, 300 quality print, 600 high-res print - that's the author's own mapping. Optional: jpeg_quality (1–100, default 95, JPEG only) and output_subfolder, a subfolder inside ComfyUI's output directory.

Outputs are saved_path (STRING) and print_size_info (STRING) - the latter is the useful one, formatted as pixels, DPI, the size in inches and centimetres, and the path. Wire either into a text display if you want it visible on the canvas. The node is an output node, so it always runs and shows a preview.

Install

Same pack, same steps as everything else:

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

Restart ComfyUI, then look under the Superside category. No API key, no fal call, no cost - this one is pure Pillow, and it works offline.

The gotchas, from reading the code

These aren't hypotheticals; they're in the implementation:

• Only the first image of a batch is saved. The node takes image[0] and writes one file. Send it a batch of four and you get one PNG. Split the batch first if you need all of them.
• Transparency is dropped. Anything RGBA gets converted to RGB, so this is the wrong save node for transparent PNG cutouts.
• The filename convention is not ComfyUI's. You get {prefix}_0001.ext, incrementing until it finds a free name - not the core node's {prefix}_00001_.png. Scripts and folder watchers keyed to the default convention will miss these. TIFF comes out as .tif.
• It replaces the file rather than overwriting, which is good for archiving and bad if you expected the same path every run.
• The workflow is not embedded. Your PNG gets the pHYs chunk and nothing else - the hidden prompt/extra_pnginfo data this node accepts isn't serialised into the file. That's the opposite of the usual ComfyUI convention, where a PNG is the project file and dragging it back onto the canvas rebuilds the graph. If you post this PNG somewhere expecting people to load your workflow from it, they can't. Use the pack's own Superside Save Image for that job.
• Re-encoding kills the DPI. Same rule as every ancillary chunk: a host that recompresses your PNG drops it, and converting to WebP or back strips it too. Send the original bytes to the printer.

If the printer still complains

Two things worth checking before you touch anything else. First, some tools and printers only read JFIF fields on JPEG or only respect TIFF tags - PNG pHYs is technically correct and occasionally ignored, so if the print shop says "this file has no resolution", export a TIFF instead and stop arguing with the pipeline. Second, a viewer showing "72 DPI" in its info panel may just be reporting its own default rather than what's in the file; check the file, not the panel, before you re-run anything.