◎ Radiance Log Curve Encode

Decoding log footage is the half everyone talks about. Encoding back into log is the half nobody mentions, until you're the person who has to hand an AI-generated element to a colorist or a VFX pipeline and it has to match the log-encoded plates. That's what Radiance Log Curve Encode is for: take linear data and apply a camera's log curve so it sits in the same encoding as the rest of the shot.

It's the exact inverse of the pack's Log Curve Decode node - same curve list, same EI handling, mirrored direction. Together they're the "decode → work in linear → re-encode" loop that keeps your AI output consistent with real footage, which is the whole reason the KB's color-management section exists: a single un-managed decode poisons the comp, and so does a missing re-encode on delivery.

How it works

The node takes linear values and applies the log function for the curve you pick - ARRI LogC3/LogC4, Sony S-Log3, Panasonic V-Log, Canon Log 3, RED Log3G10, ACEScct, or DaVinci Intermediate - the same families the decode node offers. source_gamut tells it what color space your linear data is already in (ACEScg, sRGB, P3-D65, Rec.2020, or Native), because encoding the curve without accounting for the gamut gets you values that won't reconstruct correctly on the way back out.

There's also a gamma/exposure escape hatch for when you're not doing a strict camera log encode. apply_gamma (on by default) applies a gamma curve - the gamma default of 2.2 is the classic display-encode value - and exposure shifts things in stops before the curve. So it doubles as a general "encode to a gamma space" node, not just a camera-log encoder.

The inputs that matter

• image - linear input.
• curve - the log curve to encode into. Match the delivery format of your pipeline.
• source_gamut - what your input is currently in. Get this right or the round-trip decode/encode will drift color.
• exposure_index - only affects LogC3, same as the decode side.
• apply_gamma, gamma, exposure - the escape hatch for gamma-space work. Defaults: on, 2.2, 0.
• clamp_output - on by default here (unlike most of the pack). Encode is a delivery step, so it clamps to 0–1 unless you explicitly need the log values to exceed it.

Output: the encoded image.

When you actually need this

Honest answer: only when you're delivering into a log-managed pipeline. If you make finished images and save them as sRGB PNGs, you don't need this node and shouldn't force it. The moment your output has to be a log-encoded element - for a Nuke comp, a colorist, or an ACEScct workflow - this is the difference between an element that composites cleanly and one the colorist has to explain to you on Slack. Combined with the decode node it also makes a good round-trip test: encode to LogC3, decode back, and if you don't get your original values back, your source_gamut/target_gamut choices were off somewhere.

Installing

cd ComfyUI/custom_nodes
git clone https://github.com/fxtdstudios/radiance.git
cd radiance
pip install -r requirements.txt   # or requirements_windows.txt / requirements_linux.txt / requirements_mac_silicon.txt

Or search Radiance in ComfyUI Manager. Linux needs libopenexr-dev first; restart after installing.

Gotchas

The round-trip trap is the one to watch. Encode with apply_gamma on when your pipeline expects pure log, and the decode side will see a double curve - your "log" file won't decode back to the linear you started from. Keep apply_gamma off for camera-log work and reserve it for actual gamma-space delivery. And remember the pack's data rule: encoding can't rescue a clipped source. If you started with 8-bit sRGB, re-encoding it as LogC4 doesn't make it HDR - it just puts your 8-bit data in a log envelope.