LTXV API Video to Video HDR

This is the odd one out in the pack, and it's the one VFX people will care about. LTXV API Video to Video HDR takes an SDR video, sends it to Lightricks' async HDR endpoint, and gets back scene-linear EXR frames - float32, not clipped to [0,1], values that genuinely exceed 1.0. That's a real HDR deliverable, not a tone-mapped fake. It's also priced like it: $0.20/s at 1080p, $0.40/s at 1440p, $0.80/s at 4K, with per-tier frame caps (181 / 101 / 41 frames respectively). Check the LTX console before you queue something long.

Why you'd reach for this

Every other node in this pack returns a nice MP4 you can immediately post. This one returns a pile of EXRs that most people have no idea what to do with - which is exactly why it exists. If you work in a pipeline that grades, composites, or delivers in linear space, an HDR regrade of footage gives you latitude no tone-mapped video has: relight in HDR, pull highlights back, push them over. If you're making social clips, this node is not for you. The README's own framing is blunt about it - wire image into an EXR-aware writer like AM Write Image (ext=exr) for HDR-safe export, or into stock CreateVideo for an SDR preview.

How it works

Mechanically it's the async sibling: POST /v2/video-to-video-hdr returns a job ID and a 202, then the node polls with exponential backoff (starting at 5s, capping at 30s, 10-minute default ceiling) until the job is terminal, downloads a ZIP of per-frame EXRs, and decodes them via OpenCV into a float32 IMAGE batch. There's no audio (by definition) and the EXR ZIP has no native time base - so the frame_rate output is just whatever you put in the output_fps widget, and downstream consumers use it for cadence.

The one real gotcha is color space, and the author flags it honestly. Lightricks calls the output "scene-linear 16-bit" and declines to say what the primaries are. Source inspection of their local code shows an inverse LogC3 transfer with no color matrix - so the working assumption is linear ARRI Wide Gamut 3 (AWG3), LogC3's canonical companion. Treat it that way, apply an AWG3 → ACEScg or AWG3 → Rec.709 IDT downstream, and verify against a reference. Do not assume linear Rec.709 just because EXR readers default to it - the file doesn't carry that interpretation. This is beta-era behavior and may get colour-management notes later.

The inputs that matter

• output_fps - the cadence reported on frame_rate. It doesn't change the render; it's metadata for downstream tools.
• poll_timeout_seconds - max wait for the async job (default 600). 4K inputs at the frame cap can outrun it; raise it.
• keep_temp_exrs - off by default (temp files deleted after decode). Flip it on if you want the EXRs left on disk for DJV, Nuke, or a real pipeline.
• video / video_url - SDR source. File-backed video uploads original bytes; use video_url for anything that would balloon a base64 body.

Outputs: image (the float32 batch), info (which includes the LTX job ID), and the standard width / height / frame_rate / frame_count metadata.

Installing it

Same repo, same steps, but the HDR node is where opencv-python earns its place in the dependency list - EXR decoding is OpenCV's job:

cd ComfyUI/custom_nodes
git clone https://github.com/am-pipeline-prod/comfyui-ltxv-api.git
cd comfyui-ltxv-api
pip install -r requirements.txt

The package sets OPENCV_IO_ENABLE_OPENEXR=1 in-process at import, so the EXR codec works out of the box in a normal ComfyUI launch. But if you start ComfyUI from a wrapper - systemd, Docker entrypoint - set it there too, before anything else reads EXR:

export OPENCV_IO_ENABLE_OPENEXR=1

API key goes in LTXV_API_KEY (env var) or ~/.config/comfyui-ltxv-api/config.toml. Same self-serve caveat as the rest of the pack: MIT, works, not actively maintained.

Where people get burned

• HDR job times out - long 4K inputs outrun the 600s default. Raise poll_timeout_seconds.
• OpenCV failed to read EXR - your opencv-python build lacks the codec. If you installed from a system package or a stripped wheel, pip install --upgrade opencv-python (the pip wheels ship EXR support).
• Wrong-looking colors - you assumed sRGB/Rec.709. Retag as linear AWG3 and apply an IDT; a 30-second A/B settles it.
• Frame cap errors - you exceeded 181 (1080p) / 101 (1440p) / 41 (4K) frames. Shorten the input.
• Massive base64 body rejected - use video_url for long sources.

This is the node you reach for when "good enough for socials" isn't the goal. It's fiddly, it's pricey, and it's the only thing in this pack that outputs a genuinely HDR intermediate. If you don't need scene-linear EXR, the regular Retake node costs less and gives you an MP4 you can actually post.