ACES 2.0 S-2126 Compliance

What it does

You give it two images: the scene-linear ACEScg frame before your output transform, and the display-referred frame after it. It runs a set of checks against Academy S-2126 thresholds and hands back a formatted report plus a count of how many checks passed.

This is a diagnostic, not an effect. It colours nothing, shifts nothing, and outputs no pixels. Its entire job is to answer "did my transform actually do what the spec says", which is otherwise a question you answer by squinting at a waveform on a calibrated monitor - or by not answering it at all.

The five checks

Straight from the implementation:

1. middle_grey_mapping - scene 0.18 should land at about 10% of peak. This one only runs if the input's mean luma is already between 0.10 and 0.30, because there's no sense testing grey placement on an image that isn't around grey. Otherwise it reports SKIP, which is a real result and not a failure.
2. output_clamp - nothing above 1.0 after encoding. Catches a transform that's leaking HDR values into a display-referred output.
3. black_crush - nothing negative. Catches the other end, where an aggressive set of matrices pushes shadows below zero.
4. dynamic_range - the output has to cover more than 2 stops between its darkest and brightest positive values, otherwise "conforms" is meaningless because everything got crushed.
5. gamut_containment - under 0.5% of pixels outside [0,1] counts as marginally out; more than that fails.

Each line gets a PASS, SKIP or FAIL with the measured number and expected value in the report, and the footer totals them.

Inputs and outputs

scene_image is the pre-transform ACEScg image; display_image is the post-transform result. Get these the wrong way round and the checks will fail in confusing ways - the tooltips say "BEFORE" and "AFTER" in capitals for a reason.

output_type (SDR_sRGB, SDR_P3, HDR_PQ_1000/2000/4000, HDR_HLG) and the optional peak_nits are, per the node's own tooltips, labels only right now: they're printed in the report header and the same thresholds run for every choice. Don't read a PASS on HDR_PQ_4000 as "verified for a 4000-nit master" - it isn't, yet.

Outputs are report (STRING) and pass_count (INT). The report is a formatted block with ✓/⚠/✗ per check, which is genuinely pleasant to read. pass_count is the number you'd wire into a conditional later if you wanted a workflow to halt on a bad transform - that's the practical reason it's an INT and not part of the string.

One detail worth knowing: batches are truncated to the first frame. It checks one frame, not a sequence.

When you'd actually use it

The intended audience is someone building or validating a display pipeline, where "did the transform do the right thing" matters and eyeballing isn't good enough. In practice it's also the fastest way to catch your own mistake: if you feed a display-encoded image in as scene_image, the middle-grey check will go SKIP and the others will tell you the output is nonsense. It's a test harness you can leave in the graph while you tune.

For a hobbyist pipeline it's overkill most of the time. But it's also the only node in this pack that will tell you something is wrong instead of just producing a picture that looks slightly off, and that's worth wiring in once when you're setting up an ACES chain, if only to confirm you're not fooling yourself.

Install

ComfyUI Manager → search Radiance → install → restart → refresh the browser. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/fxtd-studios/radiance.git
cd radiance
python -m pip install -r requirements.txt

Use ComfyUI's bundled python_embeded\python.exe for the pip step on Windows portable. Nothing here needs a model or a colour config - it's numpy maths on your tensors. The pack's start-up does configure OpenColorIO (your $OCIO, otherwise the built-in ACES studio config) and turns on OpenCV's EXR codec, but this node doesn't depend on either.

Gotchas

• Swapped inputs. The most common way to get a report full of FAILs on a perfectly good transform.
• Treating SKIP as a pass. Middle grey SKIPs whenever your frame isn't near 18% grey, which includes most photographic frames. pass_count doesn't count a SKIP as a pass, so read the report, not just the number.
• Assuming output_type changes the test. The tooltip states it's a label. Same thresholds for all six.
• Assuming peak_nits matters. Also a label, per the node itself.
• Checking a video. Only frame one is examined.