🅛🅣🅧 LTXV Load EXR Sequence

Every video model before LTX-2.3 topped out at 8-bit SDR, which is fine until you try to grade the thing. Highlights clip, shadows crush, and it composites badly against CGI. Lightricks shipped an HDR IC-LoRA to fix the model side of that problem, and this node is the front door on the ComfyUI side: point it at an EXR still or a folder of EXR frames and it hands your graph usable frames.

It's worth being precise about the two HDR paths in this pack, because people mix them up constantly.

• Native HDR (this node): you already have EXR plates, in real linear or log values, and you want LTX to work on them directly.
• SDR→HDR (the LTXVSDRToHDRWorkingSpace node): you have an ordinary MP4 and the HDR IC-LoRA is going to invent dynamic range that was never there.

If your source is a phone clip, you want the second one. If you shot or rendered plates, this one.

What it does

It reads each EXR as float32 RGB, stacks them into an IMAGE batch, and converts the set into ACEScct, scaled to [0, 1]. That's the working space the HDR IC-LoRA and the float32 VAE were trained around - the same space Lightricks' own Python pipelines use when you run them with --hdr. The color_space field tells the node what your files already contain: srgb_linear and acescg get compressed into ACEScct, acescct passes through with a clamp.

Two details in the implementation are the kind that save you an afternoon. Frame filenames are sorted naturally, so frame_9.exr lands before frame_10.exr. And with trim_to_8k1 on (the default), a 100-frame sequence gets quietly trimmed to the longest legal prefix - the LTX video VAE compresses time in blocks of 8, so it wants 1 + 8k frames, and 97 is the legal version of 100. You get a log warning, not a crash. It does throw if your frames don't all share the same H×W×C, so don't hand it a folder where someone left a half-resolution render in.

EXR sequences carry no container metadata, so nothing in the file says "24 fps". That's why frame_rate is a plain float you type in, and why it's required even for a single still - it sets the length of a silent AUDIO track the node emits alongside the images. That's not a joke feature. V2V graphs freeze the original audio latent, and a zero-length waveform crashes torchaudio's resample and VAEEncodeAudio before you ever see a preview.

The inputs that matter

• path - a .exr still (fine for I2V) or a directory of *.exr (use a folder with 8k+1 frames for V2V). Relative paths resolve under ComfyUI's input/ folder, so the painless move is ComfyUI/input/plates/shot01/.
• color_space - srgb_linear, acescg, or acescct. Get this wrong and your HDR either goes flat or blows out; if a colourist hands you plates, ask them which one it is.
• frame_rate - required for folders, no way around it.
• frame_start, frame_cap, trim_to_8k1 - the trim/limit knobs. frame_cap of 0 means "all", which is what you want until you're prototyping on a huge sequence.

Outputs are images, frame_rate, width, height, frame_count, and audio: images into the guide/VAE path, audio into whatever the V2V graph wants as a frozen soundtrack, the metadata for duration math.

One instruction from the author worth repeating verbatim in spirit: downstream, set img_compression = 0 on LTXVPreprocess. ComfyUI likes to JPEG/CRF-compress conditioning frames, and ComfyUI-LTXVideo's own Python HDR path skips that - running ACEScct codes through a lossy compression step darkens your highlights. Native HDR means no compression in the chain.

Install

Same as everything else in the pack - ComfyUI Manager, Install Custom Nodes, search LTXVideo, install, restart. Or:

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

Then make sure the two dependencies this file actually needs are there. openimageio is non-negotiable - the code raises Reading EXR requires OpenImageIO. Install with: pip install openimageio and there is deliberately no OpenCV fallback. colour-science handles the primaries matrices. Both are in the pack's requirements.txt.

Models: the HDR work runs on the LTX-2.3-era 22B checkpoints, the distilled LoRA, the HDR IC-LoRA (ltx-2.3-22b-ic-lora-hdr-0.9.safetensors, into models/loras), and the Gemma 3 12B text encoder. Budget 32GB+ VRAM and 100GB+ of disk as the README says, though the low-VRAM loaders in the pack are the escape hatch.

Where people get burned

• EXR folder, wrong frames. Ten mismatched resolutions in a folder is a hard ValueError, not a warning.
• Opening plates somewhere the node can't see. Absolute paths work; relative ones are resolved against ComfyUI/input, and neither resolution step will guess for you.
• Forgetting the float32 VAE. ACEScct values live outside [0,1] once decoded, and float16 decode rounds the range away. Chain VAELoader → LTXVVAEForceFloat32 → encode/decode, then LTXVHDRDecodePostprocess with transfer=acescct, and send its hdr_linear output to LTXVSaveHLG for a master you can hand over. The pack's example_workflows/2.5/ folder has the working native-HDR graphs (LTX-2.5_I2V_Native_HDR_Two_Stage_Distilled.json is the readable one) - start from those rather than wiring it blind, because the order of these five nodes is the whole trick.