Nodes/Latent-Tiled PiD/Latent-Tiled PiD QA (vs VAE twin)
ComfyUI Node

Latent-Tiled PiD QA (vs VAE twin)

Is your PiD decode collapsing in slow motion? This node tells you

By BennyDaBall930·Created about a month ago·Updated 17 days ago· 15
Latent-Tiled PiD QA (vs VAE twin)
  • image
  • reference
  • STRING

The failure this whole pack exists to prevent - PiD's color collapse when you decode past its trained envelope - is not always visible at a glance. Whites going pink and chroma noise creeping in can read as "moody" instead of "broken" on first look. Latent-Tiled PiD QA is the objective check: it compares your PiD decode against the plain VAE decode of the same latent and gives you numbers instead of vibes.

It's a small node, but it's the one the author actually used to build the pack - every one of those 56 presets in the Size Picker was gated through this measurement before it shipped. If you're pushing new resolutions or a new model combo, this is the safety net.

How it works

Two images in, one verdict out. image is your PiD decode (any resolution), reference is the normal VAEDecode of the same latent. It measures two things:

  • midtone chroma delta - the collapse detector. Healthy decodes calibrate ~8–12 on PiD v1.5 (10–15 on the deprecated v1 checkpoint), collapsed ~30, flag > 20.
  • shadow green-bias delta - a secondary tone-shift check, flag at ±3.

The output is a STRING (the node is an output node, so the report shows up in the UI) that prints both numbers with a PASS / CHECK verdict. If the two images have different resolutions, it area-interpolates the PiD image down to the reference size before measuring, so the comparison is apples-to-apples at the reference resolution - that also means your reference has to be the VAE decode of the same latent, or the numbers are meaningless.

What it's for

The README's doctrine is simple: run it whenever you push a new resolution or model combo, and trust its verdicts over hope. It's why the pack's preset ladders have per-rung verdicts in the sweep reports instead of "looks fine to me." If you're trying an untested path - say a flux1 or sd3 latent through the Decode node, which exists but isn't render-tested - this is the node that tells you whether it actually works.

Reading the results

  • Chroma > 20: past-envelope decode territory. Check max_tile (should be 1024), check latent_format matches your model, or check that you're using PiD v1.5.
  • Healthy chroma but green-bias flag: the secondary gate. Worth a seed-shifted retest - that's exactly what the author did with culled rungs, and some of them passed on the second roll. One fail isn't necessarily a death sentence.
  • Baseline drift: expect ~8–12 chroma on v1.5 vs ~10–15 on v1. And the flux2 lane runs a few points warmer than qwen at the biggest rungs - still inside the gate, but know your lane's baseline before you panic.

Install

Same pack, so this is the last time you'll read this: ComfyUI Manager search "ComfyUI-Latent-Tiled-PiD", or:

cd ComfyUI/custom_nodes
git clone https://github.com/BennyDaBall930/ComfyUI-Latent-Tiled-PiD

Restart; nodes are under latent/pid. ComfyUI ≥ 0.28, no python dependencies. You don't even need the PiD checkpoints loaded to run this node - it's pure measurement math on whatever two images you wire in, which makes it handy as a general "did my decode hold up" check.

Categorylatent/pid

Inputs (2)

NameTypeDefaultDescription
imageIMAGEThe PiD decode (any resolution).
referenceIMAGEThe stage-1 VAE decode of the same latent.

Outputs (1)

NameTypeDescription
STRINGSTRING