Reencode Latent

A latent isn't a universal format - it's tied to the VAE that produced it. Reencode Latent decodes a latent back to pixel space with one VAE, then re-encodes it with a different one, in a single node. That's the whole operation: two VAEs in, one round-trip, one latent out on the other side.

You reach for this whenever a latent needs to keep flowing but the VAE around it has changed - say you're routing a latent from one pipe into a second stage that uses a different checkpoint's VAE, or you've swapped in a fine-tuned VAE partway through a workflow and need everything downstream to agree on the same latent space. Feeding a latent encoded by one VAE into a sampler expecting another produces the encoding equivalent of speaking the wrong dialect - the numbers are close enough to look valid but wrong enough to degrade your output. Reencode Latent is the honest fix: actually decode and re-encode, rather than hoping the mismatch doesn't matter.

How it works

input_vae decodes the incoming samples to a full pixel-space image, and output_vae immediately re-encodes that image back to a latent. Straightforward, but it costs a full decode/encode round-trip, which is not free on large images - that's why the node also exposes tiled processing.

tile_mode controls whether that round-trip is tiled at all, and if so, which half: None does a plain full-frame decode and encode, Both tiles both operations, Decode(input) only tiles just the decode step, and Encode(output) only tiles just the encode step. Tiling trades a bit of speed for lower peak VRAM, which matters if you're reencoding a large image and the plain path would otherwise run you out of memory.

The inputs and outputs that matter

• samples (LATENT, required) - the latent to reencode.
• input_vae / output_vae (both VAE, required) - the VAE that produced the incoming latent, and the VAE you want it re-encoded with. If these two happen to be the same VAE, the node still round-trips it - useful mainly for the tiling behavior, not for changing anything.
• tile_mode - see above; leave at None unless you're hitting VRAM limits on a big image.
• tile_size (default 512, range 320–4096) and overlap (optional, default 64) - standard tiled-VAE knobs, only relevant when tile_mode has tiling turned on for at least one side. Larger tiles are faster but use more memory per tile; more overlap reduces visible seams between tiles at a small cost to speed.

Output is a single LATENT - the reencoded result, now consistent with output_vae, ready to feed into whatever sampler or node expects that VAE's latent space.

How to install it

Via ComfyUI Manager: search ComfyUI Impact Pack, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/ltdrdata/ComfyUI-Impact-Pack comfyui-impact-pack
cd comfyui-impact-pack
python -m pip install -r requirements.txt   # ComfyUI's python; python_embeded on portable

then restart. No models bundled with this node itself - you supply both VAEs from wherever you already load them.

Common issues & troubleshooting

Output looks slightly different from the input, even with matching VAEs. That's expected, not a bug - decode-then-encode is a lossy round-trip even when the two VAE inputs are identical, because you're going through pixel space and back. It's usually subtle, but it's not nothing; don't reencode gratuitously if the latent's VAE already matches what's downstream.

Ran out of VRAM on a big image. Turn tile_mode to Both (or whichever side is the bottleneck) and lower tile_size if it's still tight. This is exactly the situation tiling exists for.

Colors or details shifted noticeably after reencoding. Confirm input_vae is genuinely the VAE that produced the latent, not a guess. Feeding the wrong input_vae decodes garbage before you even get to the re-encode step, and the error compounds from there rather than canceling out.

Do you actually need this node? Only when a latent is crossing a real VAE boundary. If your whole workflow uses one checkpoint's VAE throughout, there's nothing to reconcile - skip it.