(deforum) VAEEncode [safe]

The name makes this look like a boring re-skin of ComfyUI's built-in VAEEncode, and honestly, for most of your Deforum work it kind of is. The "safe" in the title is the tell: this node exists for the moments when your workflow doesn't know, ahead of time, whether it's going to be handed pixels or a ready-made latent. It handles both without blowing up.

This comes from XmYx's Deforum Nodes pack, the official port of the classic Deforum animation engine (the A1111 extension that defined the "zoom and morph through a single image" look back in late 2022, per the KB's ui-history writeup) into ComfyUI node graphs. In that world, latents don't always come straight from an image encode - they can come out of the Deforum latent cache, or from frame warping, or from a previous iteration.

How it works

Look at the inputs and the logic is one small branch:

• vae (required) - your VAE, wired from the checkpoint/VaeLoader like normal.
• pixels (optional, IMAGE) - if something is connected here, the node runs vae.encode on it and returns a fresh latent. It slices off the alpha channel (pixels[:, :, :, :3]) so RGBA images don't trip up the encoder.
• latent (optional, LATENT) - if pixels is not connected, the node simply returns this latent untouched. Passthrough, nothing more.

The single LATENT output is what flows on downstream, either freshly encoded or handed through.

That branch is the entire reason the node exists. In Deforum's cadence workflows - and this node appears in the pack's shipped deforum_cadence.json example - the first frame needs to be encoded from a reference image while every later frame reuses cached latents. Rather than making you fork your graph and pick which encode path you're on, this node accepts both and makes the choice at execution time. If you feed it a latent, it doesn't crash and doesn't re-encode; it just lets the latent through, which is exactly the "safe" behavior.

Why you'd use it

If you're building a Deforum graph by hand, reach for this when a latent path is conditional - a cached latent that may or may not exist yet, a first-frame encode that might get bypassed, an IPAdapter or frame-warp branch feeding pixels in some runs but not others. If your pixels path is static, the stock VAEEncode does the identical job and you don't need this wrapper.

Installing it

Part of the Deforum Nodes pack:

cd ComfyUI/custom_nodes
git clone https://github.com/XmYx/deforum-comfy-nodes.git

Restart after cloning, or use ComfyUI Manager → "Deforum Nodes" by XmYx. Remember this is a heavyweight install: it pip-installs the deforum-studio backend plus librosa, moviepy, av, pydub, opencv-contrib and a numpy<2.0.0 pin, and the README requires Python 3.10. The first run of the install script also tries to drop in a stable-fast wheel, which fails silently on some setups - it warns and moves on, so don't panic if you see that in the log.

Common issues

The main way people get burned is the opposite of what you'd expect: they treat "safe" as "smart." This node does not know which input you meant if both are connected - it prioritizes pixels every time. If you have a latent wired in and pixels connected, it will re-encode the image and silently ignore your cached latent, which can nuke a cadence workflow's continuity. Connect only the path you actually want. Also worth knowing: any orphaned A1111-era deforum pip package in your Python can collide with this pack on install - uninstall it (pip uninstall deforum), then retry in the Manager.