Fizgig H3 Still Decode

You did the sensible thing. You got a single-frame H3 latent, sampled it, and piped it into the plain old VAE Decode like you would for any image model. What came back is streaky, dark and banded - like the picture is being viewed through blinds. You reroll the seed, add steps, rewrite the prompt. None of it matters, because the problem is downstream of the sampler.

H3's decoder was not trained on one frame at a time.

What's actually going wrong

H3's VAE is a ViT decoder trained on groups of five latent frames, and its token coordinates are normalised across the temporal length of whatever latent it's handed. A lone latent frame - which is what a still is, and what VAE Decode dutifully feeds it - sits outside that regime entirely. The decoder has no idea what to do with it, so it comes back at roughly 17 dB round-trip instead of 30 dB. That gap is your banding.

Fizgig H3 Still Decode puts the frame back into the regime the decoder expects. It takes the single latent frame and replicates it into a full five-frame group, decodes that group (tiled, as the model always is), then keeps pixel frame three of the twenty it produced - just past the decoder's causal lead-in, where the output has settled. Four of those five latent frames and nineteen of those twenty pixel frames get thrown away.

Yes, that's more compute than decoding one frame would be. But one frame doesn't decode. That's the entire point of the node.

Inputs and outputs

Two inputs, identical to the node you're replacing:

• samples - the LATENT out of your sampler.
• vae - the H3 video VAE, same as you'd load for VAE Decode.

One output: IMAGE, wired wherever the stock decode was going - Save Image, Preview Image, or an upscaler. That's why this is the easiest flavour of custom node to adopt: delete one, add one, reconnect two wires. You can even A/B it, which is what the pack's example workflow does - it decodes twice on the same seed, so you see the difference in one run instead of trusting a screenshot.

Installing it

cd ComfyUI/custom_nodes
git clone https://github.com/shootthesound/ComfyUI-Fizgig-H3-Still

Restart ComfyUI and both nodes in the pack - this decode and the still latent - show up under the Fizgig category. No Python dependencies at all: the dependency list is empty and there's no requirements file, so there's no chance of it dragging in a conflicting package and wrecking the rest of your install. That's rarer than it should be.

What you need is the H3 model stack from Comfy-Org/MiniMax-H3: pruned int8 diffusion model, Qwen3-VL text encoder, H3 video VAE. This node needs no weights of its own.

It costs you nothing on video work

That's the nicest design decision here. The node checks what it's been handed first. If the latent isn't a single frame - a clip, in other words - or the VAE isn't the H3 one, it hands the job straight to the stock decode and gets out of the way. Leave it in permanently, then: if you occasionally render a clip from the same graph, this node won't be what breaks it.

Where people get burned

Expecting it to rescue a video. Anything with more than one latent frame goes through the stock path by design. Not a bug, but it isn't a clip cleaner either.

The node missing from the menu after install. This pack imports ComfyUI internals that only exist in builds with MiniMax H3 support. On an older ComfyUI the import fails and the pack silently doesn't register. Update first.

VRAM and speed expectations. The decode is tiled, so large stills don't need a large card - it works through a few tiles at a time, or one at a time when VRAM is tight, and the one-at-a-time path is slow. Batches decode serially, one item per loop, which is kind to memory and unfriendly to wall-clock.

Reaching for the dedicated single-frame VAE instead. There's a separate H3 image VAE (minimax_h3_t1_image_vae…safetensors) that people try. The author's testing found it slower and softer with less skin detail than this route - their images, not a lab benchmark - but the mechanism backs it up: this node uses the VAE you already downloaded the way it was trained to be used.

Odd resolutions upstream. Anything other than a multiple of 32 produces a latent the decoder can't make sense of, and the error will point at the wrong node. Set width and height once, on both the latent node and the conditioning node, and leave them alone.

The licence. Unrelated to the pack, but it gates the model: H3's weights exclude the US, EU, UK and South Korea from their licensed territory.

For provenance - Fizgig is Peter Neill's LoRA training workbench for Flux Klein and Krea 2, and these two nodes are the H3-still path pulled out of it, the same decode that renders its previews. Small, self-contained, and shipped because the stock decode genuinely doesn't work here.