🅛🅣🅧 LTXV Save HLG

EXR sequences are great until you need to send someone a file. Clip, email, upload to a review tool, drop in a Discord - none of that wants 400 half-float frames in a folder. LTXVSaveHLG is the delivery end of the HDR chain: it takes the scene-linear HDR image and writes a BT.2020 / HLG 10-bit HEVC MP4 master. That's a real broadcast-ish deliverable, the kind of thing you can hand a colourist or play on a modern TV, and roughly the last node in the graph.

The catch, and it's the reason this node exists at all, is that you can't just save a normal MP4 from HDR frames. The usual route goes linear → Rec.709 → Rec.2020, and that Rec.709 hop clips out-of-gamut colour before you ever get to the wider space. This node maps your source primaries straight to Rec.2020 - ACEScg to Rec.2020, or Rec.709 to Rec.2020 - then applies HLG. No intermediate stop where information dies.

Wiring it

The input is one image batch, hdr_linear, and it is specifically the hdr_linear output of LTXVHDRDecodePostprocess - not the tonemapped preview. This is the single most common mistake with this node. The tonemapped output has already been Reinhard-compressed and gamma-encoded for human eyes; feeding that into an HLG encoder gives you a washed, double-processed master that looks vaguely fine on your monitor and falls apart under a grade.

linear_primaries tells the node what space hdr_linear is in. acescg is the default and the right answer for the modern ACEScct path - both the SDR→HDR IC-LoRA and native EXR HDR decode to ACEScg linear. rec709 is there for the legacy LogC3 LoRA era, and light's worth noticing: the pack's own top-level README still describes the HDR IC-LoRA as producing "LogC3-compressed space", while the node defaults and the 2.5 workflow docs say ACEScct. Trust the node and the source here; logc3 is labelled legacy for a reason.

frame_rate and filename_prefix (default hdr/ltxv_hlg) are straightforward. audio is optional and, if you give it an AUDIO track, it gets muxed in as AAC - the HDR IC-LoRA workflow freezes the source audio through the sampler and then hands it here, which is how you end up with an HDR video that still has its soundtrack.

There are no outputs on this node. It's a terminal save node; the file lands under ComfyUI's output/ directory.

What it's actually doing under the hood

The encode runs through PyAV to libx265, at CRF 12 with preset medium, 10-bit yuv420p10le, plus the colour tags that make players treat it as HLG: colorprim=bt2020, transfer=arib-std-b67, colormatrix=bt2020nc, limited range, hvc1 codec tag so Apple hardware plays it. CRF 12 is a high quality setting - your HLG files will be big and the encode will not be fast. Work in EXR or check the tonemapped preview first and only run this when you're happy.

Two consequences fall out of that config. 4:2:0 chroma needs even dimensions, and the node silently crops a row and column if your width or height is odd - a 1081-tall output becomes 1080 without asking. And the AAC stream has to be registered before the video packets or PyAV refuses the mux; that's handled internally, but it explains the ordering.

Install

ComfyUI Manager → Install Custom Nodes → search LTXVideo, or:

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

Then be honest about what this node pulls in. requirements.txt brings colour-science>=0.4.4 for the primaries matrices and openimageio for the EXR side; the HLG encode itself needs PyAV with an x265 build, which normally arrives with ComfyUI core rather than this pack. If libx265 is missing from your PyAV wheel you'll get an encoder error at save time, not at install time - that's the failure to expect in a stripped-down environment.

Models-wise this node is free - no checkpoints needed. It's the upstream HDR work that wants the 22B checkpoint, the HDR IC-LoRA in models/loras, and the README's 32GB+ VRAM budget.

Where people get burned

• Wiring the tonemapped preview instead of hdr_linear. Already covered, still the number one issue.
• Wrong linear_primaries. If graded HDR looks oversaturated and slightly wrong in Resolve, you probably left it on acescg for a legacy LogC3 chain, or vice versa.
• Somebody opens the file and says it looks washed out. HLG is designed for HLG-aware displays and pipelines. VLC on an SDR monitor is not that, and Resolve needs a colour-managed timeline with an HLG output transform to show you the truth. VFX folks testing the HDR IC-LoRA did this in Flame and Resolve for exactly this reason. Don't judge the master from a browser tab.
• Expecting grading levers in ComfyUI. The one exposure control in the chain lives on LTXVHDRDecodePostprocess and affects the preview only. The plan is: export, then grade. People working in VFX asked for exactly that in the HDR release thread - plus OCIO/ACES-aware viewing inside ComfyUI, which still isn't there.