ANDRO Remap Range

Once you decode without the [0,1] clamp, you own a problem the stock path never had: an 8-bit or 10-bit writer will happily clip everything above 1.0 on the way to the file. ANDRO Remap Range is what you put in front of that writer when the overshoot is worth keeping - it fits out-of-range values into [0,1] deliberately, and tells you what the fit cost in stops. The obvious reading of this node is "tone mapper," and the more precise one is "a deliberate clamp you get to choose instead of the accidental one ComfyUI does for you."

Why the default isn't what you'd guess

You'd think "scale everything to fit" would be the safe mode. It's not, and the tooltip explains the trade clearly: overshoot is only 0.01–0.34% of samples, so scale to fit pays for those few by moving every sample - flattening parts of the picture that were correctly exposed. That's why the default mode is filmic rolloff. It leaves everything below the knee untouched (verified bit-exact - maximum change below the knee is 0.0) and bends only the top, mapping the input peak to exactly 1.0. On one plate that meant 11.2% of samples moved against 100% for scale-to-fit, with mid-tones untouched in the first case and shifted in the second. It's what a film shoulder does, and what a colourist expects.

Modes and inputs

• mode - one of:
  • clip - what the stock path does anyway: everything above 1.0 becomes 1.0.
  • scale to fit - keep every value, move the whole range into [0,1]. Nothing lost, whole-picture contrast paid for it.
  • reinhard highlights - compress only what's above 1.0.
  • filmic rolloff (default) - leave everything below the knee, bend the top into the remaining headroom.
  • report only - measure, change nothing.
• knee (0.8 default, optional) - where the filmic rolloff starts bending. 0.8 leaves the top fifth of the range to absorb the overshoot.

The image input only means anything on an unclamped decode - a clamped one has nothing left outside the range. Outputs are the remapped image and a report giving the range before and after, so the cost is on the record.

The 10-bit side of the story

ComfyUI's CreateVideo has a bit_depth widget, and it does work - set it to 10 and the file comes out yuv420p10le, High 10 profile, carrying 851 distinct luma values against the 256 an 8-bit file can physically hold. But a container creates nothing: feed that 10-bit encoder the stock bf16 decode and it faithfully records the same ~77 levels. This node (and the float32 decode behind it) fixes what goes in; bit_depth fixes what it goes into. They're complementary, not alternatives. One honest footnote: 10-bit output is still written untagged - color_primaries/transfer/space come back unknown - so a fully colour-managed writer is a separate problem this node doesn't pretend to solve.

Install

ANDRO Remap Range ships in the comfyui-vae-float32 pack alongside ANDRO VAE Decode. ComfyUI-Manager → search comfyui-vae-float32 → install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/AndreiOrehov/comfyui-vae-float32

Find it under the ANDRO category. Quick mental model for when it belongs in a graph: decode with out-of-range values kept → this node → any 8/10-bit writer. If everything downstream is EXR or a float path, you don't need it - that's what the pack's Save EXR node is for.