Simple VAE Encode

Every time you VAE-encode a decoded image back into latent space, you lose a little. The encode isn't the exact inverse of the decode - you get a slightly different latent than the one you started with, and if you're doing repeated img2img passes, that loss compounds each round trip. SimpleSyrup.SimpleVAEEncode looks at the graph, sees that the image it's being asked to encode already came straight out of a VAE Decode, and simply hands you the original latent instead of re-encoding. Same output, zero loss, one less encode to pay for.

The mechanism is graph provenance, and it's the cleverest thing in the pack. Instead of guessing whether some latent happens to match an image tensor, the node traces the graph: it checks whether the input image can be proven to be the direct, unmodified output of a VAEDecode node, traveling through transparent pass-through nodes along the way. If yes, it recovers the source latent - but only when the VAE you connected matches the VAE that did the original decoding. The vae input isn't decorative; a mismatch means latent reuse is unsafe, and the node falls back to a normal encode. The source's own framing is precise: "These nodes follow the graph instead of trying to identify a latent from the finished tensor."

What breaks the proof, per the tooltip: editing, cropping, detailing, or resizing the image. The instant you insert a ResizeImageToTarget or a crop or any pixel-touching node between the decode and this node, the graph can no longer prove the image is unmodified, and you get a regular VAE encode. That's not a bug - it's the safety condition. It would rather do the slightly-lossy thing than hand you a latent that doesn't actually correspond to the pixels in front of it.

Two inputs, image and vae; one output, latent. Where it shines:

• Progressive refinement loops. Decode → adjust → re-encode used to pay a full encode each cycle. If the adjustment is elsewhere in the graph and the image is still the unmodified decode, this node hands back the true latent and the loop stops degrading.
• Multi-pass workflows that touch pixels once. Any place you're tempted to decode early and re-encode later, put SimpleVAEEncode right after the decode point and let it short-circuit the return trip.

The honest caveat is that its usefulness is exactly proportional to how disciplined your graph is. The moment you're resizing or cropping between passes - which most real workflows do - you fall back to normal encoding, and you're no better off than with the stock VAEEncode. It's a node for workflows that respect provenance, not a magic quality button you can slap on a sloppy graph.

Install: the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/Artificial-Sweetener/SimpleSyrup
cd SimpleSyrup && pip install -r requirements.txt

or ComfyUI Manager → search SimpleSyrup → Install → restart, with a current ComfyUI (v3 extension API). No models involved - this is pure graph logic plus a VAE you already have. If you're getting normal encodes when you expect latent reuse, the image isn't provably an unmodified decode; add this node immediately after the VAE Decode and keep the path transparent.