Nodes/ComfyUI-ACES-IO/ACES IO — Display Transform (OCIODisplay)
ComfyUI Node

ACES IO — Display Transform (OCIODisplay)

Bake a display transform into pixels — the Viewer's more committed sibling

By BISAM20·Created 6 months ago·Updated 6 months ago· 9
ACES IO — Display Transform (OCIODisplay)
  • image
  • ocio_config
  • input_colorspace
  • display
  • view
  • image
invertfalse

ACES IO - Display Transform is the answer to a question you'll hit the first time you try to save an ACES-corrected image: how do I get my scene-linear ACEScg pixels into an sRGB file without them looking washed out? The Viewer node can show you the correct result, but it's a monitor - it doesn't commit. This node runs the same display view transform (OCIO's DisplayViewTransform, the Nuke OCIODisplay equivalent) but writes the result into the image data. What comes out the other end is display-referred sRGB, ready for a normal saver or a PNG.

Inputs

  • input_colorspace (default ACEScg) - the space your image is actually in.
  • display (default sRGB - Display) and view (default ACES 2.0 - SDR 100 nits (Rec.709)) - together they pick the exact display transform, same options as the Viewer.
  • invert - the new-in-v1.3 trick. Flip it and the whole pipeline runs in reverse (TRANSFORM_DIR_INVERSE): display-referred sRGB goes back to your scene-linear input colorspace. That's a genuine roundtrip tool - bake an image for review in an sRGB tool, then recover the scene-linear ACEScg from it. Handy when someone "helpfully" exported a flattened PNG and you need the linear values back.

Output is a single image.

Where it slots in

The honest use is at the end of a chain before output, and it's the safer default than the Viewer for anything you're going to save:

EXR Loader → ColorSpace (→ ACEScg) → [your nodes] → Display Transform (ACEScg → sRGB) → Save

The main trap is doing this before your diffusion pass instead of after. If you bake the display transform and then run img2img, the sampler operates on sRGB-encoded values - you've thrown away the linear light data you went to the trouble of loading. The order matters: transform at the edges, keep the middle linear.

Install & gotchas

Part of BISAM20/ComfyUI-ACES-IO - Manager → Install Custom Nodes → ComfyUI-ACES-IO, restart, or git clone https://github.com/BISAM20/ComfyUI-ACES-IO into custom_nodes plus pip install -r requirements.txt. Shared with the rest of the pack: the one dependency that actually breaks installs is PyOpenColorIO, which pip installs as opencolorio (not "PyOpenColorIO" - that name isn't on PyPI).

Things that bite:

  • Output is clipped to display range. A display transform maps HDR values into SDR by design - that's the whole point - so don't send this into an EXR saver expecting linear data. If you want to store linear, don't apply a display transform.
  • Switching configs silently resets things. Like the Viewer, if your saved display/view don't exist in the newly loaded config, the node falls back to that config's defaults instead of erroring. Check your dropdowns after changing the Config Loader.
  • invert is not a "make it look normal again" button - it's a precise mathematical inverse of the transform you picked. If the image wasn't produced by that exact display transform, inverting gives you garbage, not a correction.
CategoryACES IO/Transform

Inputs (6)

NameTypeDefaultDescription
imageIMAGE
ocio_configOCIO_CONFIG
input_colorspaceACES_COLORSPACEACEScg
displayACES_DISPLAYsRGB - Display
viewACES_VIEWACES 2.0 - SDR 100 nits (Rec.709)
invertBOOLEANfalseInvert the transform: display-referred → input colorspace

Outputs (1)

NameTypeDescription
imageIMAGE