MiniMax H3 Pixel Continuity • Finish
Put the protected head back, fade the tone, touch nothing else
- video
- continuity
- video
- video_path
- status
Finish is the second half of a two-node bracket around a pixel upscale, and it only does two things: it restores the repeated context head you protected, and it eases the new footage's color bias toward the tail it continues from.
The setup it belongs to: in a chained H3 run, the second scene's clip starts with the previous scene's tail frames repeated as visual context. When you pixel-upscale both scenes at full quality, you don't want those repeated frames re-invented - you want them to stay the previous scene's actual high-quality frames, or the join will pop. So MiniMax H3 Pixel Continuity • Protect Tail swaps the repeated head with the previous saved HQ tail and hands USDU its temporal mask and anchor context. Finish cleans up after: the head goes back exactly as it was, and the rest gets a small, decaying color correction.
Unmarked does nothing. If continuity is empty - because you didn't tick Continue previous shot (pixel upscale) for that boundary in Checkpoint Manager, or because the pair didn't match - video comes straight back out and status says the shot was independent.
Inputs and outputs
Required: video (the USDU output for this scene), continuity (the object Protect Tail produced for this exact take pair), and two settings:
tone_strength- default1, range 0–1. Set it to 0 to skip the color work entirely and get a pure head restoration.fade_frames- default 39, range 1–240. How many frames the correction decays over before the picture is left alone.
Outputs are video, video_path (STRING, the file it wrote) and status. Save and Loop End both take the same final video, so the frames that get saved and the frames the next scene sees stay consistent.
The tone correction, precisely
This is the interesting part, and it's more careful than "color match the neighbors."
Instead of comparing the new scene's opening to the previous scene's ending - which conflates lighting changes and motion with actual tone drift - the node compares the same frames through two different paths: the refined output against its own reference, over a handful of frames that include the protected region. The average per-channel offset is subtracted from a stored bias, clamped to ±0.03, and scaled by tone_strength. Then it's applied with a smoothstep weight that decays over fade_frames, and the result is clamped. RGB bias only, no curves, no per-pixel matching, no blending, no retiming, no audio change.
Because the correction is a fraction of a percent of channel range, it cannot fix a scene whose lighting genuinely changed - and the pack's docs say as much: lighting changes can make it undesirable, which is why the dial exists.
Install
ComfyUI Manager, search MiniMax H3 Contex Loop, or:
cd ComfyUI/custom_nodes
git clone https://github.com/seitanism/ComfyUI-H3-Motion-Context-MultiRef.git
git clone --branch main https://github.com/ethanfel/ComfyUI-MiniMaxH3-Context-Loop.git
Restart ComfyUI fully after cloning or updating - the pack installs H3 guide and mask patches and relies on rebuilding that ownership cleanly at startup. There's no requirements.txt, so no pip step, but do budget for: your own H3 model files, ffmpeg on PATH, and the ComfyUI-ContextAnchoredTile-videopath pack, which supplies the file-backed VIDEO transport both this node and its Protect Tail partner use (it is not optional - the node resolves it by node registration and errors out without it). The refinement example also assumes ComfyUI-DLSS5-Enhancer and ComfyUI_UltimateSDUpscaleGuider_H3.
Where it goes wrong
Continuity VIDEO must keep the exact scene frame count, size and 24 fps clock is the one you'll actually meet. Finish reads frames through a checked path that enforces the saved scene's delivered frame count, its pixel dimensions and a 24 fps timestamp grid, so anything that re-encoded, retimed or resized the clip on the way in - a converted preview, a resampled export, a resize node in the middle - bounces. Keep the upscale chain's video untouched between Protect Tail and here.
The other silent-ish failure is a stale mark. Marks are bound to the exact take and the exact previous take; if either selected take changes, the mark is discarded, and picture-only alternate takes don't inherit it. That's intentional. It also means "why did my continuity stop working" is usually "the take changed underneath it," not "the node broke."
For calibration, the pack's own two-scene test found the join's mean absolute RGB difference dropping from 0.0424 to 0.0356 with protection plus tone fade - about 16% - with the restored prefix matching the prior HQ tail exactly in decoded RGB16. That's the scale of improvement you're buying, and it's worth knowing before you blame the node for not fixing a hard cut.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| video | VIDEO | — | |
| continuity | H3_PIXEL_CONTINUITY | — | |
| tone_strength | FLOAT | 1.000–1 | — |
| fade_frames | INT | 391–240 | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| video | VIDEO | — |
| video_path | STRING | — |
| status | STRING | — |