Muse-MiniMax-H3-Refine

Muse Minimax Refine

A standalone second-pass "hi-res fix" node for MiniMax H3. Companion to Muse Minimax Director, but has no dependency on it — works with any four IMAGE/AUDIO candidate pairs from any source.

What it does

MiniMax H3 has no dedicated spatial-upscaler model of its own (unlike LTX), so this node works the way an SD hi-res-fix does — entirely in pixel space:

1. Pick one of four candidate clips via the button selector in the node's UI.
2. Resize its frames to a new (typically higher) target resolution.
3. Re-encode those real pixels through the model's own vae/audio_vae to build a genuine, non-empty starting AV latent — this is the img2img step.
4. Run H3's own sampler chain, with denoise below 1.0 so only part of the schedule runs — the model refines the existing content instead of generating from scratch.
5. Decode video only. Audio passes straight through from the selected candidate, untouched.

This is the exact same technique used for a second-pass upscale in Stage 1 → Stage 2 LTX workflows, adapted to H3's joint video+audio latent.

Why pick a candidate first, instead of just generating at high resolution directly?

Because a full high-resolution H3 render is expensive, and you don't find out whether the prompt actually worked until it's done. Generate 3-4 cheap, low-resolution candidates first (e.g. with Muse Minimax Director's own Seed Hunt toggle, or any four manual low-res renders), look at them, pick the one that actually matches what you wanted, and only then spend the real compute refining that one candidate to full resolution.

Inputs

| Input | Type | Notes | |---|---|---| | model | MODEL | The same MiniMax H3 Reference/Omni checkpoint the candidates were generated with | | clip | CLIP | | | vae | VAE | | | audio_vae | VAE | | | prompt | STRING | The exact prompt the candidate was generated from (e.g. wired from compiled_prompt) | | candidate | INT (0-4) | Which candidate to refine. Set by the button UI, not typed directly. Defaults to 0 — the node refuses to run until you actually pick one, rather than silently falling back to candidate 1 | | aspect_ratio / megapixels / multiple | — | Target resolution for the refined output | | resize_method | crop / pad / stretch | How the candidate's frames get fit to the new resolution | | ref_image_size | match / max | Only relevant when ref_images is connected | | denoise | FLOAT (0.05-1.0, default 0.4) | How much of the candidate survives vs. gets redrawn. Low (~0.2) stays close to the candidate and mostly adds resolution; high (~0.6+) lets the model redraw more and can drift from the candidate's content | | seed / steps / sampler_name / scheduler / shift_video / shift_audio | — | Same meaning as on Muse Minimax Director | | candidate_1..4_images / candidate_1..4_audio | IMAGE / AUDIO (optional) | The four candidate clips | | ref_images | IMAGE (optional) | The same character/product reference photos used to generate the candidate — strongly recommended, see below |

Outputs

| Output | Type | |---|---| | images | IMAGE — the refined video frames | | audio | AUDIO — the selected candidate's original audio, unchanged |

Why ref_images matters

Without it, the refine pass only has the text prompt to constrain the redraw. Any visual detail the prompt doesn't spell out explicitly — the exact shape of a product, fine skin detail, likeness — is free to drift toward the model's own generic defaults during the partial-denoise step, even at a fairly low denoise. Wiring in the same reference photos the candidate was generated from (e.g. Muse Minimax Director's own ref_images_used output) locks those details back down, the same way Reference mode anchors them in the original generation.

Candidate=0 and blocked outputs

If candidate is 0, or points at a slot with nothing wired in, the node blocks cleanly instead of erroring — you'll see a warning in the console log, but no red error in the UI and no interruption to the rest of the queue. This is intentional: picking a candidate is a deliberate choice, not something that should silently default to slot 1.

Single-clip only

Candidates are expected to be single H3-call-length clips (≤ ~15s, the same ceiling one real H3 call has) — not a multi-chunk, stitched-together output. A concatenated multi-chunk clip's total frame count generally won't satisfy H3's own frame-count grid as one block, so it isn't a valid input here.