Spectrum H3 Objective Quality Compare (One-Shot / Full Media)

If you've looked at the sequential capture node and thought "but I already have all three clips decoded in this workflow right now," this node is your answer. Spectrum H3 Objective Quality Compare takes native H3 output (R), legacy Spectrum output (A), and a candidate Spectrum configuration (B) - all as already-decoded IMAGE batches in a single execution - and gives you the same verdict machinery: a summary, a JSON/Markdown report, and an aggregate across seeds.

The tradeoff is spelled out in its own description: it retains full media. Where the sequential capture reduces each clip to a bounded float16 analysis surface, this node compares full-resolution decoded tensors, so it's the memory-hungry path. The pack's own docs steer you to the sequential node for ordinary testing and treat this one as the "one-shot, I have everything anyway" tool. That's a fair split - use this when you want the convenience, use sequential when you're benchmarking seriously on an H3 box where RAM is precious.

What it compares

The three inputs are reference_video, legacy_video, and candidate_video - IMAGE batches with tooltips that spell out the roles exactly: R is decoded native H3 with Spectrum bypassed, A is accelerated legacy Spectrum, B is the accelerated correction candidate. Optional reference_audio, legacy_audio, and candidate_audio sockets extend the same comparison to audio (MR-STFT, normalized correlation, SI-SDR, bounded-lag diagnostics).

Everything must be generated from the same seed, prompt, sampler, steps, and conditioning, or the comparison is meaningless - the node can't verify that for you in this mode, which is exactly why provenance_json exists. It's a big multiline STRING with the default R/A/B setup baked in (A = legacy rational/0.25 correction, B = coordinate_rls/hard_clip/0.40). The default is valid but stamped user-unverified-same-workflow; fill in the exact values before you treat the evidence as trustworthy, and keep it identical across runs you want to aggregate.

The other inputs

• fps - actual output FPS, used for the temporal windows.
• benchmark_id - unique ID for one same-input R/A/B triad; this is what groups runs across seeds for the aggregate.
• seed - the generation seed, recorded into the report's identity.
• frame_chunk_size - how many frames the metric pass processes per chunk (default 4; bump it up on a beefy machine, leave it if you're not sure).

Outputs: summary gives the verdict plus the headline deltas (MS-SSIM, temporal, motion-detail, PSNR diagnostic, and audio numbers if present). The four path outputs - report_json_path, report_markdown_path, aggregate_json_path, aggregate_markdown_path - point at files under ComfyUI's system user cache (runs/<group_id>/ and aggregates/), so you can diff the details later.

Gotchas

• It's OUTPUT_NODE=true, so the summary lands in your UI like a save node's message - read it there or print it to console; it's also printed.
• This is the full-resolution metric profile, numerically distinct from the bounded sequential profile. Pick one flavor of evidence and stick with it; mixing the two is apples-to-oranges.
• You're trusting yourself to have kept R/A/B identical except for Spectrum settings. The node compares what you hand it; it can't detect that you changed the sampler between runs. That's what the sequential node's compatibility_tag and forced-seed wiring are for.

If you're doing a quick three-config sanity check in one sitting, this is the convenient route. If you're publishing a number, go sequential.