OCIO Display

Load an ACEScg EXR into ComfyUI and it looks washed out. Not because it's broken - because it's scene-referred, and ComfyUI previews assume sRGB. OCIO Display is the step you're missing: Nuke's OCIODisplay rebuilt, applying a display + view transform so scene-linear data becomes a picture a monitor can show. It's the scene-referred → display-referred conversion, and once you're working in any real colorspace, you need it before you can see what you're doing.

It's the sibling of OCIO ColorSpace and easy to confuse with it. ColorSpace moves between working spaces (ACEScg → ACES2065-1, say) with no change in reference; Display is specifically the "what does this look like on a screen" transform - ACEScg into the ACES 2.0 SDR view on an sRGB monitor, or into a Rec.2100 PQ view for HDR.

The inputs that matter

• in_colorspace - what the incoming image is in (e.g. ACEScg or ACES2065-1).
• display - the display device from the config: sRGB, Display P3, Rec.1886 Rec.709, Rec.2100 PQ/HLG, and so on.
• view - the tone-mapping/rendering intent for that display. The stock config ships the ACES 2.0 views: SDR 100 nits (Rec.709 or P3 D65), the HDR 1000/2000/4000 nits variants, plus Un-tone-mapped, Video (colorimetric) and Raw. Views must be valid for the display you picked - pick an HDR view on an SDR display and the combo won't hold together.
• invert_direction - run it backwards: display-referred back to the input colorspace. Useful for round-trips.
• mix - blend with the original, 0.0 bypasses.
• image / video - mutually exclusive; VIDEO in, VIDEO out, so it drops into a native video graph like the rest of the color nodes.

Outputs are image/sequence/video and ComfyUI Video with the transform applied.

Where people get burned

The big trap is baking a display transform into something you're about to master. A display transform is a tone map; the result is display-referred, so if you pipe OCIO Display into OCIO Write and write an EXR "master," you've just thrown away the scene-linear range you were protecting - the file now has white for a ceiling. The correct mental model: Display is for what you look at (or a review deliverable), ColorSpace is for what you keep. For the same reason, don't put one in the middle of an LTX HDR path - the ACEScct codes you want to preserve live on the scene side of this node.

Second, note that the ACES 2.0 output reads slightly different from an ACES 1.x setup you may know from Nuke - the pack is deliberately on the 2.0 config. If a view looks a touch different from your old Nuke comp, that's the config generation, not a bug.

Install: ComfyUI Manager → ComfyUI-OCIO → pick Nightly in the version dialog (the numbered registry entries are old and flagged), or clone https://github.com/SlavaSexton/ComfyUI-OCIO into custom_nodes and pip install -r requirements.txt. Needs opencolorio, which that installs. If your config dropdown only shows the built-in ACES config, that's expected until you drop a .ocio into the input folder.