VAE Encode

Every img2img, inpainting, and "start from a real photo" workflow has to cross the same bridge: your pixels have to become a latent before the sampler can touch them. LF_VAEEncode is the lf-nodes version of that bridge. It's the mirror image of the pack's LF_VAEDecode - same philosophy, opposite direction: take images, encode them into latent space, and tell you exactly what came out. If you're encoding a batch of references and want one clean latent (or a per-image list) with a log you can actually read, it's a nicer wrapper than core's bare VAE Encode.

How it works

It calls the VAE's encode() on each input image, slicing off the alpha channel (only RGB matters for the latent). The notable behavior is the batch handling: a single image encodes in one shot, but a list of images gets encoded individually and then concatenated along the batch axis - so you end up with one coherent latent batch rather than a pile of separate latent dicts. As with the decode side, it then queries the VAE for its spatial and temporal compression and logs the shapes, which is the feature that earns it a place: input image count: 4, output latent shape: 4x16xHxW tells you in one glance whether the encode did what you think it did.

That compression awareness matters more than it sounds. Modern video and image VAEs differ wildly - SDXL sits at 4 latent channels, Flux at 16 - and the encode log surfaces those numbers right on the node, which is exactly the info you need when a latent doesn't behave downstream.

The inputs that matter

• pixels (IMAGE) - the image or image list to encode.
• vae (VAE) - the encoder. Same rule as decode: use the VAE your checkpoint was trained with.

Outputs are latent (the encoded batch) and latent_list (each image's latent separately).

Install

Part of lf-nodes:

• ComfyUI Manager: search "LF Nodes", install, restart.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/lucafoscili/lf-nodes.git, restart.

No models - you supply the VAE.

Common issues

• "The latent came back the wrong channel count." That's a VAE/model mismatch, not the node. A Flux VAE encoding an image intended for an SDXL sampler produces nonsense downstream; the node's log showing 4x... vs 16x... is your diagnostic.
• "It encoded but my img2img looks like a different image." Encoding then decoding at low denoise is expected to drift - every encode-decode round trip costs a little fidelity (see the KB's VAE panel on chained passes). Keep denoise low and you mostly get your image back; crank it and it's a redraw.
• Batch gotcha: the latent output is one concatenated batch - perfect for a sampler that takes batches. The latent_list output is the same material split per image, for workflows that process each latent separately. Don't wire both downstream of a single point unless you mean the duplication.
• Transparency surprise. The node slices to RGB, so a transparent PNG's alpha is discarded at encode time. If you need alpha preserved through the latent round trip, you need a different pipeline - this node assumes opaque RGB.