HDR Monitor

Scene-linear HDR data looks wrong in a normal preview - flat, milky, low contrast - because you're viewing linear values through a display that expects gamma-encoded ones. That's not your pipeline failing, it's a missing display transform. HDR Monitor is that transform, and it's the node you leave dangling off the end of every HDR branch so you can see what you're doing while you work.

Its own description makes an important promise: wire it in parallel, and it doesn't affect your HDR pipeline. It's the pack's viewer-eyeball node, not a processing step. As an output node it always executes, which is exactly right for something whose only job is to show you pixels.

The two things it can do

Preview (SDR) tone-maps scene-linear down to 0–1 for a normal monitor. Four operators: ACES (Narkowicz) (the default, and a good default), Filmic (Hejl-Burgess), Reinhard Extended, and Exposure + Gamma. On top of that there's exposure in EV applied before tone mapping, saturation applied after, gamma (2.2 approximates sRGB, 2.4 matches BT.1886), and gamma_correct_sdr, which applies the 1/gamma display encoding after tonemapping - and applies to every operator, including Exposure + Gamma. reinhard_white sets the white point for the Reinhard Extended path.

Rec.2100 PQ and Rec.2100 HLG encode a signal for an actual HDR display. Those are the modes where peak_nits matters (mastering peak, default 1000). The tooltip flags the important caveat: these modes do no gamut conversion. They encode the signal, they don't move your primaries, so if you need BT.2020 delivery that's a separate step upstream.

One output: preview.

Which mode should you use?

If you have an SDR monitor - which is most of us - you want Preview (SDR) and you should change the operator to suit the content, not leave everything on defaults. ACES Narkowicz has a filmic shoulder that flatters highlights; Reinhard Extended is flatter and more "honest" about how much range you actually have; Exposure + Gamma is the blunt instrument, useful for a quick sanity check on whether your numbers are in a sane range at all.

If you've got a real HDR display and you want to see the target, use PQ or HLG with a peak_nits matching your panel. Just don't confuse "this looks great on my HDR monitor" with "this file is correct" - the monitor node is showing you a preview, not validating delivery.

Install

Manager → search Radiance → Install → restart ComfyUI → refresh your browser. Manually:

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

Windows portable users should use ComfyUI's bundled python_embeded\python.exe for pip. No models needed.

Where people get burned

Don't save the preview. It's tone-mapped and gamma-encoded for viewing; it is not your HDR master. The Radiance README says it plainly in the Viewer section - adjustments and previews affect what you see unless you do the equivalent processing in the workflow - and that goes double here. Save the scene-linear branch.

Tone mapping hides problems. A blown-out highlight that ACES Narkowicz rolls off gracefully is still blown out. If you're debugging range, watch it in a mode that shows clipping (the pack has False Color and Clip Check LUT options in its grading node) rather than judging by whether the preview looks pleasant.

There's a WebGPU caveat worth knowing before you spend an hour on it. Radiance defaults to a WebGL viewer backend; WebGPU is opt-in and its feature parity is explicitly incomplete - masks, qualifiers and OCIO are inert there, and the known-issues list names further gaps in 3D LUT reads and grading. If a preview control seems to do nothing, check which backend you're on before assuming a bug in the node.

And a general one: gamma is a pure power curve, not the sRGB piecewise function. At 2.2 the difference from true sRGB is small but real in the deep shadows - fine for monitoring, not a colour-space conversion.