Reencode Latent (pipe)

Same job as Reencode Latent: decode a latent with one VAE, re-encode it with another, in a single node - the fix for when a latent needs to keep flowing downstream but the VAE around it has changed. ReencodeLatentPipe is the pipe-flavored version: instead of two separate VAE inputs, it takes two basic_pipes (model/clip/vae/positive/negative bundled) and pulls the VAE out of each. Handy if your workflow is already routing basic_pipes between stages and you'd rather not unpack one just to grab a VAE.

You reach for this any time a latent is crossing a real VAE boundary - feeding a latent from one pipe's stage into a second stage built on a different checkpoint's VAE, for instance. Skip the reencode and you get results that are wrong in a way that's easy to miss: the latent numbers are close enough to look valid to whatever samples them next, but wrong enough to quietly degrade the output.

How it works

The input_basic_pipe's VAE decodes samples to pixel space; the output_basic_pipe's VAE immediately re-encodes those pixels back to a latent. That's the whole operation - the model, clip, positive and negative carried in each pipe are along for the ride and unused here; only the VAE matters.

tile_mode controls whether that decode/encode round-trip is tiled, and if so which half: None is a plain full-frame pass, Both tiles decode and encode, Decode(input) only tiles just the decode, Encode(output) only tiles just the encode. Tiling trades a little speed for lower peak VRAM - worth turning on if you're reencoding a large image and hitting memory limits on the plain path.

The inputs and outputs that matter

• samples (LATENT, required) - the latent to reencode.
• input_basic_pipe (required) - the pipe whose VAE produced the incoming latent.
• output_basic_pipe (required) - the pipe whose VAE you want the latent re-encoded with.
• tile_mode - see above; leave at None unless you're VRAM-constrained on a large image.

Unlike the non-pipe Reencode Latent, this node doesn't expose separate tile_size/overlap controls - tile_mode is your only tiling lever here.

Output is a single LATENT - now consistent with output_basic_pipe's VAE, ready for whatever samples or decodes it next.

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 extra models - both VAEs come from whatever's already loaded into your two basic_pipes.

Common issues & troubleshooting

Output looks slightly different even though both pipes use the same VAE. Expected. Decode-then-encode is a lossy round-trip through pixel space regardless of whether the two VAEs match - usually subtle, but real. Don't reencode a latent that doesn't actually need it.

Ran out of VRAM on a big image. Set tile_mode to Both (or whichever side is the actual bottleneck).

Colors or detail shifted more than expected. Double-check input_basic_pipe genuinely carries the VAE that produced samples, not a different checkpoint's. A wrong input_basic_pipe decodes garbage before the re-encode even happens, and there's no recovering from that downstream.

Do you need this over plain Reencode Latent? Only if you're already carrying basic_pipes through the workflow. If you just have two loose VAE nodes lying around, the non-pipe version is simpler and skips building pipes you don't otherwise need.