Nodes/radiance/Video HDR Conditioner
ComfyUI Node

Video HDR Conditioner

It conditions a video model, not your pixels

By FXTD-Studios·Created 8 months ago·Updated about 18 hours ago· 246
Video HDR Conditioner
  • positive
  • clip
  • positive
  • hdr_metadata_json
◄peak_nits1000►
◄target_gamutBT.2020►
◄eotfPQ (ST.2084)►
◄camera_moveNone►
◄moodNone►
◄extra_hdr_prompt►
◄inject_metadata_embeddingtrue►
◄token_strength1.00►

There's a version of "HDR support" that means encoding real PQ pixels, and a version that means telling the model the look you're after. Video HDR Conditioner is unambiguously the second: it concatenates HDR descriptor embeddings onto your positive conditioning so a video model samples toward a luminance-aware look, and it stores the metadata those descriptors came from so the pack's decode node can use it afterwards.

If you want pixels, that's Video HDR Decode. This node is the steering wheel.

What it does

Input positive is the encoded positive prompt. Required settings: peak_nits (100, 203, 400, 600, 1000, 4000, 10000), target_gamut (BT.2020, P3-D65, P3-DCI, BT.709, ACEScg, ACES2065-1) and eotf (PQ (ST.2084), HLG (BT.2100), Linear, sRGB / BT.1886). Each one does two things - adds a descriptor to the conditioning tokens, and writes its value into the hdr_metadata_json output so the downstream decode knows what was requested.

clip is optional in the schema but required in practice, and the pack flags this in its known issues: "Video HDR Conditioner needs clip. Without it the conditioning passes through unchanged and hdr_metadata_json.applied_to_model is false." So if you wire it up without a text encoder, you get a no-op and a metadata key that tells you so. Good design; easy to miss.

The optional flavour controls are more fun and more useful than they look. camera_move adds movement words (Handheld documentary, Locked off cinematic, Slow push-in, Drone aerial, Tracking shot, Static time-lapse, None); mood adds lighting words (Golden hour, Blue hour / dusk, Night, Overcast flat, High contrast, Neon / cyberpunk, Natural daylight, None); extra_hdr_prompt takes free text. These are the descriptors that actually change what the model draws - the nits value mostly changes how punchy it tries to be.

token_strength (default 1) scales the concatenated descriptor embeddings: 1.0 is as encoded, 2.0 leans on them hard. inject_metadata_embedding (default on) stores the HDR metadata inside the conditioning - the tooltip is refreshingly honest that no ComfyUI model reads it; it's there for the pack's own nodes.

Outputs: positive (CONDITIONING) and hdr_metadata_json (STRING). The JSON is what you hand to Video HDR Decode, and it carries peak_nits, gamut and the EOTF value.

How it fits together

The chain that makes sense of the whole HDR-video side of this pack:

Video Cond Merge (or the T2V pipeline's own positive conditioning) → Video HDR Conditioner → sampler → Video Batch Decode → Video HDR Decode, with the conditioner's hdr_metadata_json threaded across to the decode node's own JSON input.

That wiring is worth being deliberate about, because the conditioner's descriptors change what the model aims at while the decode's output_eotf decides what the signal actually is. The conditioner stores an EOTF - but the decode node uses its own output_eotf and the JSON's EOTF is documentation. Ask the model for HLG and encode PQ, and nothing complains.

A reasonable expectation

Descriptor conditioning is prompt engineering with better plumbing. It biases a model that has seen HDR-described footage toward specular-heavy, high-contrast output; it does not add dynamic range that the sampler never produced. The genuinely linear part of the job happens later, in the decode, where the frames are actually turned into a PQ or HLG signal. Community discussion of this area - and there isn't much of it, this is a niche corner - has repeatedly run aground on exactly that confusion, with people assuming an HDR describing node produces "real" HDR. It doesn't, and the pack doesn't claim it does.

Install

  1. ComfyUI Manager → search Radiance → Install → restart → refresh the browser.
  2. Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/fxtd-studios/radiance.git
cd radiance
python -m pip install -r requirements.txt

Windows portable: python_embeded\python.exe for the pip line. Nothing downloads for this node, but note the pack's install is heavy overall - OpenEXR, OpenImageIO, OpenColorIO, transformers, diffusers, scipy - and the registry has lagged behind the README's 3.5.0, so use Manager's Update or git pull if the widgets don't match the docs.

CategoryFXTD STUDIOS/Radiance/Video

Inputs (10)

NameTypeDefaultDescription
positiveCONDITIONINGEncoded positive prompt. The HDR descriptor embeddings are concatenated onto each entry (needs clip).
peak_nitsCOMBO1000Mastering peak in nits: adds a luminance descriptor to the tokens and is stored as peak_nits in hdr_metadata_json for RadianceVideoHDRDecode.
target_gamutCOMBOBT.2020Adds a gamut descriptor to the tokens and is stored as gamut in hdr_metadata_json (RadianceVideoHDRDecode converts to it).
eotfCOMBOPQ (ST.2084)Adds a transfer-function descriptor to the tokens and is stored in hdr_metadata_json. RadianceVideoHDRDecode uses its own output_eotf.
clipoptCLIPText encoder used for positive. Required for the descriptors to reach the model.
camera_moveoptCOMBONoneAdds camera-movement words to the descriptor tokens. None adds nothing.
moodoptCOMBONoneAdds lighting-mood words to the descriptor tokens. None adds nothing.
extra_hdr_promptoptSTRINGAdditional HDR descriptors appended to conditioning tokens
inject_metadata_embeddingoptBOOLEANtrueStore the HDR metadata in the conditioning for Radiance nodes. No ComfyUI model reads it.
token_strengthoptFLOAT1.000–2Scale of the concatenated descriptor embeddings (1.0 = as encoded). Needs clip.

Outputs (2)

NameTypeDescription
positiveCONDITIONING—
hdr_metadata_jsonSTRING—