LTX-2.5 SDR-To-HDR IC-LoRA: how should it be structured?

[christopher5106]

What
Lightricks/LTX-2.5-22b-IC-LoRA-SDR-To-HDR can't run in diffusers today. LTX2HDRPipeline targets the LTX-2.3 LogC3 LoRA. The LTX-2.5 one (Lightricks' ltx_pipelines.hdr_ic_lora.HDRICLoraPipeline) needs:

1. ACEScct input/output transforms;
2. a video-only, single-stage distilled path conditioned on the LoRA's precomputed scene embedding (no text encoder, no CFG);
3. seam keyframes: 1-frame SDR guides plus generated slots at each 24/32-frame seam, decoded by a keyframe-aware diffusion decoder (decoder.type_emb, joint attention with the nearest keyframe planes).

I opened #14966, #14974 and #14975 for this before discussing it here, sorry about that. I'm closing them and would like to agree on the shape first.

What I measured (H200, real weights, hiker.mp4 from documentation-images, against the reference at LTX-2 9ec55f9f)

• (1)+(2): final latent 50.0 dB, output 38.4 dB; inputs, RoPE positions, masks and token order identical.
• (3): final latent 52.4 dB, token-level checks at 70 dB or better.

Checkpoint blocker
The diffusion_decoder in Lightricks/LTX-2.5-Diffusers doesn't match the current original VAE (ltx-2.5-video-vae): it has no decoder.type_emb, and none of its decoder tensors match. Decoder-only parity against the reference is 44.4 dB (plain) / 35.2 dB (keyframes) with the published weights, and 62.2 / 68.6 dB once re-converted from the original file. Reported in https://huggingface.co/Lightricks/LTX-2.5-Diffusers/discussions/19. Keyframe decoding can't ship against the current Hub weights.

Questions

1. A mode of LTX2HDRPipeline (hdr_transform="acescct", which changes the inputs, components, schedule and decoder), a separate LTX2SDRToHDRPipeline, or modular blocks?
2. Does diffusers want the HLG BT.2020 10-bit MP4 / EXR writers (optional OpenEXR dependency), or should export stay on the user side?
3. Keyframe decoding touches the same decoder code as [LTX-2.5] Refactor LTX-2.5 Diffusion Decoder Forward Methods #14694. Should it wait for [LTX-2.5] Refactor LTX-2.5 Diffusion Decoder Forward Methods #14694 and be built on its scheduler-owned loop, as a model-only PR after the Hub decoder is re-converted?

My suggested order, if that works for you: (a) ACEScct transforms + SDR-To-HDR without seams, in whatever shape you prefer; (b) the keyframe-aware decoder, after #14694 and the checkpoint fix; (c) seam keyframes in the pipeline; export separately or not at all.

[yiyixuxu]

thanks for opening the issue!

it looks like something requires a new pipeline -> can you create & host a modular pipeline on hub for now? You can reuse some of the existing LTX2.5 blocks and only add what's specific to this Lora

some resources:

• Quickstart on modular diffusers (https://huggingface.co/docs/diffusers/modular_diffusers/quickstart)
• doc on building & share custom blocks (https://huggingface.co/docs/diffusers/modular_diffusers/custom_blocks)
• diffusers-cli related (https://huggingface.co/docs/diffusers/using-diffusers/cli#customblocks)

some examples:
https://huggingface.co/collections/diffusers/modular-pipelines
https://huggingface.co/collections/diffusers/modular-diffusers-custom-blocks

please share with us so we can help test and add into our collections