OpenClip Colour Space Transform

Cameras don't hand you pictures, they hand you encodings - LogC3 in Wide Gamut 3, S-Log3 in S-Gamut3.Cine - and everything downstream of a comp assumes one shared working space. This node reconciles one into the other, scene to scene, with no display transform sneaking in.

Which of the two colour nodes you want

The pack ships two, and confusing them is the main way to waste an afternoon.

OpenClip Colour Transform applies an OCIO display/view transform. It's the one you insert after the reader when a log plate needs to look like something a diffusion model understands - models trained on BT.1886/Rec.709 footage want Rec.709-ish input, not ACEScg.

OpenClip Colour Space Transform - this node - does plain scene-to-scene conversion: no display, no view, no tone mapping. You're not making the plate pretty, you're telling the pipeline that this image is in that gamut and needs to be in this one.

That division exists because of how the reader behaves. OpenClip Reader decodes camera log curves on read, so by the time an image reaches here the log curve is already gone - only the native-gamut identity is left to reconcile. So the source dropdown is full of already-linear entries: pick "ARRI LogC4 (Wide Gamut 4)" and the node actually feeds Linear ARRI Wide Gamut 4 to OCIO. The familiar camera names are the labels; the linear names are what runs.

The inputs you'll actually touch

• IMAGE - the plate, straight off a reader.
• ocio_config - a path to a .ocio file. The default is smarter than it looks: $OCIO if it's set, otherwise the newest Flame install under /opt/Autodesk/colour_mgmt/configs/flame_configs/*/aces2.0_config/config.ocio, otherwise blank.
• source - 13 options: ACEScg (already the working space), ARRI LogC3/LogC4, RED Log3G10, two Sony S-Log3 variants, Canon Log2/Log3, Panasonic V-Log, Blackmagic Film Gen5, DaVinci Wide Gamut, sRGB, Rec.1886/BT.1886, and Custom....
• target_colour_space - 14 options: the same list, plus Same as input (via pipe) and Custom.... ACEScg is the usual destination; it's the working space the rest of this pipeline assumes.
• custom_source / custom_target_colour_space - only read when you pick Custom.... Real OCIO colour-space names, spelled exactly.
• same_as_input_colour_space - only read when the target is Same as input (via pipe). Wire an OpenClip Reader's colour_space output into it.

Outputs are IMAGE and MASK. The mask is a passthrough: connect one and you get it back, don't and you get a fully opaque mask, because that's the VFX convention for "no matte" rather than "nothing here".

Two honest caveats, straight from the author's source comments. The Canon entry is unverified: the config it was checked against has no already-linear Canon Wide Gamut entry, so it's the best available option rather than a tested one. And the reader's colour_space output is the verbatim tag in the file, not cross-checked against your config - a tag your config doesn't know fails inside OCIO at execute time, not at wiring time.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/allklier/ComfyUI_OpenClip.git
pip install -r requirements.txt

Or search "OpenClip" in ComfyUI Manager, which installs lxml, openimageio and opencolorio from requirements.txt. No model weights, no downloads, nothing to put in models/.

Where people get burned

Blank ocio_config on a non-Flame machine. That Flame-config default is a courtesy for people sitting at a Flame workstation, and the $OCIO fallback only helps if you set it. Elsewhere the widget is often empty and every queue ends with ocio_config path is required. Grab an ACES config (the ACES 2.0 Studio config from the OpenColorIO releases works) and point the widget at the config.ocio inside it.

OpenColorIO errors at execute, not at startup. The import lives inside the transform call, so a ComfyUI that boots cleanly tells you nothing about whether opencolorio is installed - the other OpenClip nodes load and run without it. If you get "PyOpenColorIO is required for colour transforms", that's a pip install, not a graph problem.

Same as input (via pipe) with nothing plugged in raises rather than guessing. Correct behaviour, and it'll feel like a bug the first time - the option sits in the dropdown looking perfectly usable.

Using this node where you needed the display transform. A LogC3 plate pushed scene-to-scene into ACEScg is still a linear plate with values well outside 0–1; feed that to a model trained on Rec.709 stills and it looks washed out and flat. Passes and comps want this node. Generative models want its sibling. That's the whole leaf-versus-glue distinction in the colour-management corner: you don't out-engineer OCIO, you hand it the right question.

And if you're a solo generator making finished images, ignore all of this - the sRGB path is correct. It starts mattering the moment your output has to survive as an element next to real footage, where one unmanaged decode poisons the comp.