Qwen VAE Decode (Lock Size & Crop Back) — by wallen0322

Every encoder in wallen0322's QI pack pads your image up to a grid multiple or a 32-aligned working size - that's the whole trick that stops Qwen-Edit from drifting and offsetting your geometry. But it means your latent isn't shaped like your image anymore, and a stock VAEDecode happily hands back a padded frame with gray bars on the edges. QI_VAEDecodeLockSize is the closing move of the workflow: it decodes the latent and crops the padding back off, returning exactly the size you started with.

How it works

When the QI encoders build their latent, they stash a qi_pad dict inside it recording how much padding went on each side (top/bottom/left/right) and the original dimensions. This node reads that metadata after decoding: it crops the padded edges off, and if the letterbox alignment left a few stray pixels of mismatch it re-centers and replicate-pads the hair-thin remainder so the final image lands on the exact original size. If there's no qi_pad - say you're feeding it a latent from a normal workflow - it just decodes like a plain VAEDecode, so it's a safe drop-in either way.

Under the hood it's careful with tensor shape (it unwraps whatever container your VAE returns, including 5D temporal forms) and with precision: force_fp32 (default on) casts the latent to fp32 before decode, which is the standard fix for Qwen VAE decoder noise.

The inputs that matter

Only two required, both obvious: vae and latent. The two optional toggles are worth a glance:

force_fp32 (default true) - leave it on. The Qwen VAE decoder gets noisy and banded in lower precision; this is where the "stability" of the pack's name is earned.
move_to_cpu (default true) - hands the result back to CPU, which keeps the GPU free for the next job and is what you want for a final output tensor anyway.

Output is a single image, ready for a preview, a save node, or further post-processing.

Wiring

This is the end of the chain the pack is built around:

CLIP / IMAGE / VAE → QI encoder → (conditioning, image, latent) → KSampler → QI_VAEDecodeLockSize → image

Use it with either QI_TextEncodeQwenImageEdit_Safe or QI_RefEditEncode_Safe; both write the qi_pad metadata this node reads.

Installing

Same one-time install as the rest of the pack. ComfyUI Manager, search ComfyUI-QI-QwenEditSafe, or:

cd ComfyUI/custom_nodes
git clone https://github.com/wallen0322/ComfyUI-QI-QwenEditSafe

Restart. There are no Python dependencies - the pack's install script literally prints "nothing to install." You still need the Qwen-Image-Edit model itself (a GGUF quant or the Nunchaku INT4 loader from the sample workflows, since 20B won't fit consumer VRAM at full precision).

Gotchas

The README names it QI_VAEDecodeHQ in places, but the class that actually ships is QI_VAEDecodeLockSize. If you don't see the node in your list after installing, make sure you're on the current version of the repo - the old name is a doc artifact, not a second node.
If you used a stock TextEncodeQwenImageEdit instead of a QI encoder, there's no qi_pad and this node behaves like a plain decode - correct, but you're not getting the crop-back benefit.
Cropping happens from the recorded metadata, not by guessing, so mixing encoders mid-workflow (encode with QI, decode a different latent) is fine as long as each latent carries its own qi_pad.