Save LPNG

Stock Save Image is where the latent goes to die. Your sampler hands you a perfectly good latent, Save Image decodes it to pixels, and that latent is gone - so the next time you want to edit the image, you'll encode it back from the pixels, losing a little fidelity on every trip. Save LPNG is the fix: it writes a normal PNG and tucks the actual latent tensor into the file's metadata, so a later Load LPNG can pick up exactly where the model left off instead of round-tripping through the VAE again.

Why bother

Repeated VAE encode/decode cycles are the quiet source of that "my image keeps getting more saturated / mushier" feeling across img2img chains, inpaint refinements, and hi-res fix passes. Each cycle adds quantization noise and reconstruction bias. LatentPNG's whole pitch is that the latent is the master copy and the visible PNG is just the preview - the RAW vs JPEG argument, applied to generated images. This node is the "save the RAW" half of that.

How it works

Save LPNG takes the latent tensor, converts it to float16, zlib-compresses it, base64-encodes it, and wraps it in a small JSON blob that lands in a standard PNG iTXt metadata chunk keyed LPNG_LATENT. It also runs one VAE decode so you get a normal, viewable PNG out of it - any viewer that doesn't know about the chunk just sees a regular image. Nothing exotic: it's a standard PNG with an extra text chunk, which is exactly why it survives wherever the file's bytes survive.

Three inputs:

• latents - what you'd otherwise feed into VAE Decode. Comes straight off your sampler.
• vae - used to make the visible preview. Attach the model's own VAE; a wrong VAE gives you a wrong-looking preview (the latent itself is saved untouched, but you'll be confused).
• file_prefix - default lpng, becomes the filename prefix.

It saves to your output folder as {file_prefix}_{timestamp}.png (timestamp-based, so nothing collides unless you save twice in the same second). The one output is IMAGE - the decoded preview - so you can chain it onward if your workflow wants pixels too.

Where it earns its keep

Use it anywhere you'd use Save Image in an iterative pipeline: img2img chains, controlnet detail passes, "run this same latent through five models" experiments. The payoff only shows up if you actually reload with the matching Load LPNG node and skip the encode step - saved alone, it's just a PNG with a slightly larger file size. Pair the two nodes and you've cut every decode→encode round trip out of your editing loop.

The honest caveats

The latent is model-native. It carries the channel count and distribution of whatever VAE made it (4 for SD1.5/SDXL, 16 for Flux and the newer DiT-era VAEs), and nothing in the file records which one that was. Feed an LPNG into a different model family and you get noise or flat color. Keep provenance with the file - the README says outright that latent compatibility is the user's job, manually.

Two more things the README implies that the code doesn't do. The documented schema calls for a checksum and VAE hash verification; the shipped implementation writes only format_version and the latent blob, with no checksum and no VAE metadata. So the file is exactly as trustworthy as the person who saved it. And because the latent rides in a text chunk, it dies the instant the file is re-encoded - screenshots, JPEG, and recompressing hosts (Reddit, Discord previews) all strip it. Save the original as your master; the chunk will not survive being shared around.

Install

ComfyUI Manager → Install Custom Nodes → search LatentPNG → install → restart. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/Anze-/LatentPNG

Then restart ComfyUI. There's no requirements.txt and no model download - the node only uses PyTorch, Pillow, and numpy, all of which ComfyUI already ships. If you do multi-pass editing, this is one of those small packs you install once and quietly stop noticing, in the best way.