OCIO VAE Encode

Here's the quiet problem with the stock VAEEncode: it applies image * 2 - 1 with no clamp, so if you feed it pixels outside the 0..1 range it was trained on, those out-of-range values ride straight into the latent without a word. You never find out. OCIO VAE Encode is the honest version: same encode, but it reports out-of-range input instead of folding it in silently, reports the silent crop to the VAE's compression ratio, and can run the whole encode in float32.

The pack's own framing is worth quoting, because it stops you from overbuying: this node exists "for consistency with the rest of the pack rather than because the stock encode is broken." The stock encode works fine for SDR images in their training domain. You want this one when you're feeding it a real HDR plate - values above 1.0, below 0, or log-coded - and you want to know what the model was given rather than infer it later from weird results.

The inputs that matter

• pixels - the image or sequence to encode. Values are expected in 0..1; anything outside is outside the VAE's training domain and is handled per out_of_range.
• vae - the VAE that belongs to your model. A VAE is trained together with its transformer; you can't swap in another one.
• precision - float32 (default, ~1.8x the model's own dtype) or float16 (only where the VAE lists it; the LTX VAE doesn't, so it falls back and says so on the report).
• out_of_range - report only (default, matches stock behavior but tells you), clamp to 0..1 (keeps the VAE in domain), or raise an error (stops the job). If you're deliberately feeding the model what it was trained on, clamp - the LTX-2.5 docs note their own reference code clamps its input both directions.

Outputs are the latent (ready for a sampler) and an input report STRING: what the encoder was handed, the share outside the 0..1 domain and what it did about it, any silent crop, and the precision actually used.

Two things it deliberately does not do. It does not convert color - if your plate is log or ACEScct and you're encoding into a model that expects linear (or vice versa), put OCIO LogConvert in front, where the curve is visible in the graph. And it doesn't un-clamp anything on the way in; that's the decode side's job. In the LTX-2.5 HDR world, the round trip is: OCIO LogConvert (Linear to Log, ACEScct) → this node → sampler → OCIO VAE Decode (clamp off) → OCIO LogConvert (Log to Linear, ACEScct) → OCIO Write. This node sits in the middle as the point where out-of-range input becomes visible instead of silent.

Install via ComfyUI Manager - search "ComfyUI-OCIO", pick Nightly (the numbered registry entries are stale and flagged) - or clone https://github.com/SlavaSexton/ComfyUI-OCIO into custom_nodes and pip install -r requirements.txt, then restart. It's under OCIO. No extra downloads; it uses the VAE you already loaded. If a report flags out-of-range pixels you didn't expect, that's the node doing its job - check what's upstream before the encode, not after.