FastH3 V2 · External Accepted-Picture Color Match (T8 EXP)

What it is

Long video from a model that generates five-second clips means stitching, and stitching means seams. The pack is refreshingly specific about the one it can't fully avoid: dual-pass H3 continuation has a known slight colour shift across the join. This node is the patch for that, and it's honest about being one.

MiniMaxH3FastH3V2ExternalColorMatchEXPT8 applies the pack's RGB colour match to your freshly decoded segment, matching it against the authenticated accepted parent - not against a frame you picked, not against a reference image, but against the actual accepted predecessor video this segment binds to. Audio and latent are untouched. Segment 0 is identity: no parent, nothing to match, frames come back as they went in.

The word "external" is doing real work. This runs after HIGH decode and trim, outside the sampling graph, on RGB frames. It's an image-space correction applied to finished pixels, not a conditioning trick or a latent hack.

How it works

It takes media_receipt, pulls the verified frames and the parent identity out of it, and runs the pack's dual-loop colour correction over the segment. The receipt it emits records which predecessor it matched against - including the parent's candidate ID and video hash - so there's no ambiguity about what "matched" meant. That matters more than it sounds: a colour match against the wrong reference is worse than no match, because it'll shift your whole segment to chase a frame that isn't part of your clip.

Mechanically it's the ordinary post-processing move - measure the statistics of a reference, measure yours, apply a bounded correction - with the difference that both ends are authenticated. It's the same idea as a Reinhard-style mean/std transfer, the cheap deterministic operation the KB's post-processing notes keep telling people to reach for instead of re-generating. A colour match is instant and reproducible; fixing "the colours are off" by re-rolling the segment is neither. If you've done colour matching in image pipelines you also know the trap: over-strong corrections flatten the shot, which is why the pack bounds it and names the modes the way it does.

The three modes

• bounded_motion_color_exp - the default, and the right first try: motion-aware bounded matching, so moving shots don't get a static statistic smeared across them.
• bounded_spatial_temporal_exp - bounded matching that spreads its correction over both space and time.
• bounded_spatial_v2 - the straight spatial version, the simplest of the three.

Plus enabled - leave it on for segment 1, and understand that on segment 0 it does nothing regardless, because there's no parent to match.

Outputs: frames (IMAGE), audio (AUDIO), color_receipt (the typed receipt the coloured candidate writer requires), and report_json. The report is where the useful detail lives: what mode ran, whether it was enabled, and an explicit statement that neither audio nor latent was touched - because on a joint audio-video model, "post-processing" that quietly resampled your audio would be a genuinely nasty bug.

Should you use it?

If you're stitching, try it. If you compared the same render with and without it and preferred without - that's a legitimate outcome, and the pipeline supports it: the raw candidate writer and the coloured one are separate nodes, so you can write both and decide later. The pack's stance is that this is a correction for a specific known artefact, not a general "make it look better" pass. Don't expect it to fix a bad parent, a mismatched reference image, or a genuinely wrong continuation.

Install

ComfyUI Manager → MiniMax H3 Audio T8, or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

Quit ComfyUI completely, restart, refresh the page. Nothing to pip-install - the pack's requirements.txt is deliberately empty so it can't replace ComfyUI's Torch/CUDA stack - and optional EXP features pull their own dependencies only when used. Prerequisites: a recent ComfyUI with native H3 support, H3 weights in models/diffusion_models, Qwen in models/text_encoders, video and audio VAEs in models/vae.

Where it goes wrong

Feeding it a receipt that isn't a completed-HIGH decode will be refused - this node wants typed media provenance, not frames you assembled yourself. If the receipt's media isn't portable, or the colour match can't confirm the parent it matched against, it refuses too, and that's the check you want: the whole value of this node is that it matched the real predecessor.

A practical one: run it, then edit the graph and re-run only part of the chain. The colour receipt is bound to the frames it produced; if you re-render the segment afterwards, re-run this node too, or the coloured candidate writer will reject the stale receipt.