H3 Continuum Hi-Res Fix V3.5

You sampled your MiniMax H3 clip at 576×576 and now you want 1152. For images, the answer is "hi-res fix": generate at native res, then do a low-denoise second pass at the higher resolution so you get real detail instead of a blurry pixel-blowup. H3 Continuum Hi-Res Fix V3.5 is that idea, applied to Continuum-aware H3 video in a single node - and it's the Main path the README points normal users to.

The classic hi-res fix tradeoff applies here just like it does for stills: the second pass with low denoising (roughly 0.3–0.5) adds coherent detail without changing the composition, while a full second generation would rebuild the scene. This node bakes that in. The difference from image workflows is that video conditioning - your First/Last frames and Reference Images - has to survive the round trip, and that's the Continuum-aware part.

How it works

For each first-pass physical video LATENT, the node does: Video VAE Decode → bounded pixel-space resize (Lanczos by default) → re-encode with the same VAE → one low-denoise Second Pass using the SIGMAS you supply. No hidden denoise value lives inside the node; the strength is entirely controlled by the workflow-side scheduler, which is the one thing that trips people up.

The standard wiring:

H3 Continuum Sampler V3.5
  -> H3 Continuum Hi-Res Fix V3.5
  -> Core Video / Audio VAE Decode
  -> H3 Continuum Assemble + Seam V3.5

Inputs that matter

• video_latents, audio_latents, assembly_plan - from the sampler.
• refine_context (optional) - connect the sampler's refine_context output so First/Last/Reference conditioning is preserved at the target geometry. Connect it; that's the whole point.
• video_vae (optional but effectively required while enabled) - the same H3 Video VAE used for the first pass; needed for the safe pixel/VAE round trip.
• model, clip - the same final H3 MODEL and CLIP from the first pass.
• sampler, sigmas - a separate second-pass set. Accepted GPU baseline: res_multistep, simple, 10 steps, denoise 0.35.
• enabled (default on) - turning it off is a lazy passthrough; nothing is resized, decoded, or sampled, and the VAE dependency isn't even evaluated. Handy for A/B testing the same graph.
• scale_by (default 2.0) - 2.0 is the validated 2x. 0 uses ComfyUI Core's H3 native canvas automatically. Anything ≥1.0 works but follows the Second Pass contract.
• upscale_method (default Lanczos) and refine_seed (base seed, derived once per physical group).

Outputs

video_latents and audio_latents (lists, one entry per physical group), updated_assembly_plan, and a status string. They feed straight into Core Video/Audio VAE Decode.

Installing it

Same pack, same one-time install:

cd ComfyUI/custom_nodes
git clone https://github.com/ukr8b3g-cmyk/ComfyUI-H3-Continuum.git

Or search "H3 Continuum" in ComfyUI Manager, then restart ComfyUI. No extra pip deps.

The warnings, because it says "Experimental" for a reason

• Long 2x runs can exceed GPU memory. The README documents a real failure: a 3×5s run at 576→1152 OOM'd on a 16 GB RTX 5060 Ti at the terminal 77T physical group. The 1×5s path at the same resolution passed. Test short first.
• Read the README's headline correction twice: the accepted baseline is 10 steps and denoise 0.35 - not denoise 10. If your refine looks like a full regen, your scheduler is lying to you.
• Don't chain Hi-Res Fix with another Second Pass. It already performs one internally.
• Don't reach for H3 Continuum Latent Resize as the Main 2x path - direct high-ratio interpolation of the 24-channel H3 latent produced persistent artifacts in the pack's own testing. Pixel/VAE round trip or an external latent processor, not raw latent 2x.