🅛🅣🅧 LTXVSDR To HDR Working Space

The HDR IC-LoRA is the interesting part of the LTX-2.3 era: it's the first time an open AI video model has produced genuinely high-dynamic-range frames, and it drops 16-bit half-float EXR straight into Resolve and compositors. But the LoRA doesn't speak MP4. It expects to be conditioned on frames in the ACEScct working space - the same space Lightricks' Python pipelines use internally - and your LoadVideo node hands you display-referred sRGB. This node is the translator. One input, one output, no parameters worth agonising over.

It's also the node that quietly decides whether your conversion looks right.

Why a colour-space node exists in a video model

IC-LoRA conditioning feeds a guide video into cross-attention so the model copies structure and appearance from it, which means whatever numbers you feed it become part of the input distribution. Hand it sRGB display codes when its pathway was trained on ACEScct and every frame is slightly wrong: the model reads the guide as if highlights were already clipped and shadows lifted.

So the node does the boring, correct thing. It takes float RGB in and returns ACEScct in [0, 1]: apply the sRGB EOTF to get display-linear Rec.709, convert primaries to ACEScg with a Bradford-adapted matrix from colour-science (the same source OpenColorIO's ACES configs use), then apply the ACEScct log curve with the AMPAS constants. If your input is already ACEScct, it clamps and passes through rather than punishing you for having clean plates.

Where it sits in the graph matters as much as what it does. The author's own instruction: place it before resize. Resize is a bilinear filter, and the EOTF is nonlinear, so EOTF-ing codes that have already been blended at a different scale gives you subtly wrong values in every soft edge. Ingest first, then scale.

The two inputs

• image - the frames. Whatever LoadVideo or an image loader gives you. It must be floating point; the node raises rather than guessing if it gets integer pixels.
• color_space - the SDR ingest IDT, and the only thing you actually choose:
  • srgb_gamma (default) - display sRGB. This is the correct choice for ~everything you load from an MP4 or a PNG, because those files carry display-encoded values, not linear light.
  • srgb - scene-linear Rec.709. Use it only when something upstream already linearised the footage.
  • acescg / acescct - scene-linear ACEScg plates, or already log-encoded frames (clamp passthrough).

The output is a single acescct image. That goes into your resize, then into the IC-LoRA guide path.

The workflow it belongs to

From the pack's own 2.5 example README, the SDR→HDR graph goes: LoadVideo → this node (srgb_gamma) → Resize Image/Mask (scale to a multiple of 32) → fixed scene embeddings via LTXVLoadConditioning (not a free-text prompt - the conditioning is your video, not a description of it) → HDR IC-LoRA guide → float32 VAE decode → LTXVHDRDecodePostprocess with transfer=acescct → LTXVSaveHLG. Sampler is euler, and the original audio is frozen and muxed back through.

Two more author-specified settings that bite: turn the prompt enhancer off, and for native HDR EXR input set img_compression = 0 downstream, because CRF compression on ACEScct codes darkens highlights. If you're matching the example workflows, those aren't optional.

Install

Manager route, as with the whole pack: Ctrl+M → Install Custom Nodes → search LTXVideo → Install → restart. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/Lightricks/ComfyUI-LTXVideo

The dependency that matters here is colour-science>=0.4.4. There's no baked-matrix fallback - the primaries conversions genuinely call into it, and if it's missing the HDR nodes won't load. Reinstall requirements after any ComfyUI update that wipes packages:

pip install -r ComfyUI/custom_nodes/ComfyUI-LTXVideo/requirements.txt

For the model side you need the LTX-2.3 22B checkpoint, the distilled LoRA, ltx-2.3-22b-ic-lora-hdr-0.9.safetensors in models/loras, and Gemma 3 12B in models/text_encoders/gemma-3-12b-it-qat-q4_0-unquantized. The README's standing numbers are 32GB+ VRAM and 100GB+ free disk; the pack's low-VRAM loaders exist because half the people running this don't have that.

Where people get burned

Picking srgb when you meant srgb_gamma. On an MP4 that skips the EOTF, so your working-space frames come out too dark and the LoRA will faithfully reproduce that. This is the single most common HDR-ingest error, and it looks like "the model is broken" rather than "I picked the wrong enum".

Expecting the SDR→HDR conversion to be free. It isn't, and it's not meant to be. A VFX user testing the HDR IC-LoRA on Lightricks' own sample clip reported the output came back with noticeably different colour, brightness and gamma - inevitable when you're moving between display-referred SDR and scene-linear HDR. The goal isn't a perfect match; it's enough range to grade.

Not testing consistency across shots. Same user made the point that matters most for real jobs: if you convert ten similar SDR shots, you want them to drift the same way, so a colourist applies one look to all of them. Batch-test early rather than discovering drift at the end of a timeline. And remember the HDR IC-LoRA is still labelled beta - it invents dynamic range convincingly, not forensically.