ComfyUI Node

๐Ÿ“ฅ LDM VAE Encode

Pushing a real image into this model's latent space

By WinlenskyยทCreated 22 days agoยทUpdated 16 days agoยท 1
๐Ÿ“ฅ LDM VAE Encode
  • pixels
  • vae
  • LATENT
โ—„vae_scale0.1822โ–บ

The decoder gets all the attention because it produces the image you can see. But if you want to do img2img with the CompVis LDM F8 Large - take a real photo and have this 2021 model redraw it - you need the front half of that round trip first. This node encodes pixels into the model's latent space so the sampler has something to partially denoise instead of starting from scratch.

It sits between Load Image and the ๐ŸŽฒ LDM Sampler in an img2img graph, and it's the mirror image of the decode node in the same pack. It uses the same AutoencoderKL from ComfyUI core (the f8 VAE this checkpoint trained against), it respects the same vae_scale, and it has the same rule about 256ร—256.

How it works

The mechanics are worth knowing because they tell you what img2img here can and can't do. Your input image - expected in the standard [0, 1] float range, straight off Load Image - gets converted internally to [-1, 1], pushed through the VAE encoder, and the mean of the posterior distribution is taken. That last bit means encoding is deterministic: no random sampling of the latent, same image in, same latent out, every time. The result is then multiplied by vae_scale (0.18215, the same magic number as on the decode node) so the latent matches the space the UNet actually operates in.

Inputs and the consistency rule

Three inputs: pixels (an IMAGE, e.g. from Load Image), vae (the VAE output from Load LDM Checkpoint), and vae_scale. Output is a single LATENT, feeding the sampler's latent_image socket.

Here's the rule that matters: encode and decode must use the same vae_scale. The tooltip on the field says it straight - it must match the value you use in VAE Decode. If you nudge the scale to fix washed-out brightness on decode and forget to mirror it on encode, your img2img latents will be sitting in the wrong range and the output will look subtly wrong in a way that's annoying to debug. Change both, or change neither.

The img2img recipe for this model

The full loop is: Load Image โ†’ ๐Ÿ“ฅ LDM VAE Encode โ†’ ๐ŸŽฒ LDM Sampler with denoise below 1.0 โ†’ ๐Ÿ–ผ๏ธ LDM VAE Decode โ†’ Save Image. The denoise value is your strength knob - 0.3 keeps it close to the source, 0.7 starts drifting into the model's own interpretation. Remember there's no CFG here, so the prompt does light steering, not strong control.

Two practical notes. First, feed it a 256ร—256 image - this model was trained at 256 and gets structurally weird beyond that, exactly like the empty-latent side does. Second, the image you load should be a multiple of 8 in each dimension (256, 512, 640...). The f8 VAE downsamples 8ร—, and a mismatched shape can produce encode errors or nasty edge artifacts. If your source isn't already a clean size, resize it first with a stock image node.

Install is shared with the whole pack: ComfyUI Manager (search comfyui_compvis_ldm) or git clone https://github.com/Winlensky/comfyui_compvis_ldm into custom_nodes, restart, and load a checkpoint from ComfyUI/models/ldm. This node adds no extra downloads of its own - the VAE comes out of the checkpoint.

CategoryLDM

Inputs (3)

NameTypeDefaultDescription
pixelsIMAGEInput image in [0, 1] range (e.g. from Load Image). Conversion to [-1, 1] is handled internally.
vaeLDM_VAEVAE output from Load LDM Checkpoint.
vae_scaleFLOAT0.18220.01โ€“1Latent scaling factor. Must match the value used in VAE Decode (default 0.18215 for f8 VAE).

Outputs (1)

NameTypeDescription
LATENTLDM_LATENTโ€”