Nodes/comfyui-minimax-h3-audio-T8/FastH3 V2 · Save Externally Colored Candidate (T8 EXP)
ComfyUI Node

FastH3 V2 · Save Externally Colored Candidate (T8 EXP)

Writing the colour-matched version without destroying the original

By T8mars·Created 2 months ago·Updated about 7 hours ago· 1,158
FastH3 V2 · Save Externally Colored Candidate (T8 EXP)
  • color_receipt
  • candidate_json_path
  • candidate_video_path
  • source_provenance_path
  • report_json
◄candidate_id►

What it is

The sibling of the plain candidate writer, with one difference: it writes the colour-matched segment instead of the raw one. Same durable candidate format, same source sidecar, same "saved means not accepted" contract - just fed by a colour receipt rather than a media receipt.

That it exists as a separate node rather than a toggle is the design statement. On a continuation you often want both: the untouched decode so you can see what the model actually produced, and the matched version to compare at the seam. Two writers, two files, one render. If you'd rather not have the correction, you simply don't wire this node.

How it works

It takes exactly one required input - color_receipt, the typed receipt from the external colour-match node - plus the optional candidate_id label. That's the entire surface. It won't accept media_receipt, and it won't accept frames, which is the point: the coloured candidate must be provably the output of a colour match that matched against an authenticated accepted parent. If the receipt is stale (you re-rendered the segment after matching), it refuses.

The underlying writer is unchanged from the raw path - same format, same sidecar shape - so a coloured candidate and a raw candidate are reviewed by the same gate and accepted through the same transaction. Which is how it should be: the review step shouldn't need to know or care which one you chose.

Outputs: candidate_json_path, candidate_video_path, source_provenance_path, report_json. The JSON path is what you paste into the review node.

Where it fits

Decode/trim → colour match → here → review and explicit accept → chain verification → compose. The raw writer can sit on the same graph fed from the decode node, so one run produces both candidates and nothing is lost either way.

One thing to keep straight while you're learning the pack: this is a terminal node. It executes and writes files. It doesn't return a video object for preview, and it doesn't compose anything. If you queue and see it in the executed list with paths in report_json, it worked.

And the same caveat that applies to the raw writer applies here - the sidecar is local integrity tracking, not a signature. It tells you the file on disk matches what the graph wrote. It doesn't tell you the segment is good, and it doesn't vouch for the colour match's taste.

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

Fully quit ComfyUI and restart it, then refresh the browser - new custom nodes register at import, so a soft reload won't reveal them. No pip install is needed or wanted: the pack ships an empty requirements.txt on purpose so nothing can replace ComfyUI's Torch/CUDA stack, and the optional EXP features check their own dependencies only when invoked. You'll need a recent ComfyUI with native H3 support, H3 weights in models/diffusion_models, Qwen in models/text_encoders, both VAEs in models/vae, and the FastH3 V2 ConvRot INT8 checkpoint for the V2 stages.

If ComfyUI Manager shows an older version than the GitHub repo, that's expected - Registry and GitHub publication progress independently, and the pack's own advice is to install from GitHub when they disagree.

Where people get burned

Two failures account for most of it. First, wiring media_receipt into this node and getting a type complaint: right idea, wrong receipt. Colour matching has to happen in between. Second, writing the coloured candidate and then re-running the render, leaving the on-disk colour receipt pointing at frames that aren't the ones you just produced. The review gate checks media hashes against reality, so you'll get a mismatch naming frames or hashes rather than a friendly "please re-run the colour match" - but that's what it means.

If you're mid-project and wondering which of the two candidate files to accept: it doesn't matter to the pipeline, and the accepted chain only cares that the segment you accepted is the one the verification step later re-checks. Pick the one you actually want in the finished clip.

CategoryT8/MiniMax H3/Modular Sampling/Continuation Experimental

Inputs (2)

NameTypeDefaultDescription
color_receiptT8_FAST_H3_V2_COLORED_MEDIA_RECEIPT—
candidate_idSTRING—

Outputs (4)

NameTypeDescription
candidate_json_pathSTRING—
candidate_video_pathSTRING—
source_provenance_pathSTRING—
report_jsonSTRING—