Scale/Unscale Latents (VAE Utils)

This is the little translator node that makes latents from one tool decode correctly in another. Its headline job, called out in the pack's own README as IMPORTANT: if you're pulling latents out of Kijai's ComfyUI-WanVideoWrapper and trying to decode them with a native ComfyUI VAE node, you need to un-normalize them first - and this is the node that does it. Without it you get garbage. With it, they decode clean.

Why you'd reach for it

Here's the mismatch. A raw latent isn't decode-ready as-is; the VAE applies a per-architecture scale (and usually a shift) to move between the model's working representation and the normalized form. SDXL uses a scaling factor of 0.13025, Flux uses 0.3611 with a shift of 0.1159, Wan has its own - every architecture has its own constants baked in. The problem is that different toolchains apply those constants at different points. WanVideoWrapper hands you latents in its normalization; native ComfyUI decode expects them in its. Same numbers, different frame of reference, and the decoder produces nonsense when they disagree.

This is one of those seams that costs people an afternoon. You've got a working Wan generation in the wrapper, you want to route the latent into a native node - maybe the pack's own Latent Upscale, maybe a stock VAE Decode - and it just... doesn't. Scale/Unscale Latents is the adapter that sits at that boundary and reconciles the two.

It shows up in real troubleshooting, too. When the community started swapping the higher-quality Wan 2.1 decoder into Qwen and Krea 2 image workflows in mid-2026 (they can, because Qwen froze Wan's encoder, so the latent space is literally the same), several people hit a wall: the save-image node threw Cannot handle this data type: (1, 1, 12), |u1. The working answer wasn't the stock nodes - it was spacepxl's ComfyUI-VAE-Utils loader and decode nodes, with the latent scaling handled correctly. The lever is real; the drop-in is not clean, and this node is part of why the swap works at all.

How it works

It multiplies or divides the latent by the right scale (and applies the shift) for whichever architecture you tell it. That's genuinely all it is - a deterministic rescale, no network, no model file. The intelligence is in knowing the constants for a lot of architectures and letting you pick the one that matches your model.

The inputs that matter

• latents - the LATENT you're converting.
• direction - either scale or unscale. This is the one you'll fiddle with: one direction normalizes, the other un-normalizes, and which you want depends on which way you're crossing the boundary. If the output decodes to noise, flip this first.
• latent_type - a big dropdown of architectures: SD15, SDXL, SD3, Flux, Flux2, and a couple dozen more (33 in total). Pick the one your latent actually came from. For the WanVideoWrapper case, choose the Wan entry.

The output is a LATENT in the target normalization, ready to hand to whatever node was choking on the original.

Installing it

Dependency-free, like the rest of the pack. ComfyUI Manager: search ComfyUI-VAE-Utils. Or clone:

cd ComfyUI/custom_nodes
git clone https://github.com/spacepxl/ComfyUI-VAE-Utils

Restart ComfyUI. No download needed for this node - it's pure math.

Common issues

The two ways to get it wrong are both quick to diagnose. Wrong direction and you've doubled the problem instead of fixing it - the decode still looks wrong, often worse. Flip direction and try again. Wrong latent_type and you've applied some other architecture's constants, which won't match; make sure the type matches the model that produced the latent, not the model you're about to decode with (unless those differ deliberately, as in the Wan-into-Qwen swap, where knowing both sides is the whole trick).

And the meta-point: reach for this only when you're actually crossing a tool boundary. If you're wholly inside native ComfyUI or wholly inside WanVideoWrapper, the normalization is already consistent and you don't need this node - inserting it there just introduces the very mismatch it's meant to cure. It earns its place at the seam between two toolchains, which, given how much of the interesting Wan work now involves stitching wrappers and native nodes together, is a seam a lot of people are standing on.