OCIO output-sRGB doesn’t match ACES sRGB ODT reference image.

Hello,

I am familiarizing myself with ACES pipeline and workflow, I wanted to build out the OCIO node network in Fusion as a means to just really understand all the working parts.

However I have run into a bit of a problem, the sRGB reference ODT image supplied from here: ( Dropbox - syntheticChart.01_ODT.Academy.sRGB_100nits_dim.tiff - Simplify your life ) does not match my output in Fusion.

My node network loads in the ACEScg reference image from here: ( Dropbox - syntheticChart.01_ACEScg.exr - Simplify your life ), and applies these color space transforms,

Loader : ACEScg (Space+Gamma) >
OCIO Colorspace ACEScg input, ACEScct output >
OCIO Colorspace ACESct input, Output – sRGB output.

If I skip the ACEScct portion and do ACEScg > Output – sRGB, the colors match better in different ways but have issues in other ways.

I am not using any LMT or Blue light artifact fixes in this network, its vanilla. The resultant image has a strange effect on the saturated blue/red color bar on the RGBCMY portion of the image. I feel like I am missing something here. (Images included)

NOTE: If I use the embedded color controls for ACES in Fusion or Resolve its fine, the result matches the output reference image without any issue. In the ACES Transform tool (ATr) if I use the below network in Fusion it seems to match the sRGB output perfectly. I am not using any gamut compression in this ATr tool.

Loader : ACEScg (Space+Gamma) >
ACESTransform (ATr) ACEScg input, sRGB output

What am I missing here?

Thank you in advance for any help you can provide in helping me understanding what I am doing wrong.

I am using ACES 1.2 ocio.config from here (GitHub - colour-science/OpenColorIO-Configs: Color Configurations for OpenColorIO) in fusion 18.

-T


Hi Troy,

I believe these are limitations of the LUT based implementation that ACES 1.2 uses with OCIO v1 configs. The newer ACES 1.3 OCIO v2.x based configs do not use LUTs anymore but the same analytical transforms as with native implementations like that of the ACES Transform node in Fusion.

The values where you see discrepencies are extremely high and likely not emerging in a real project. But if you want to be very accurate you’d have to use an OCIOv2 config. The problem however, is that BMD even after “supporting” OCIOv2 configs for quite some time now, still didn’t bother doing a proper implementation. Therefore you are not able to have a proper viewing LUT.

I’ve expressed this concern not too long ago on BMD Forum.

They miss a lot of OCIO tools but even without OCIO the viewerLUT is not practical enough. It would be as simple as making ACESTransform available as viewerLUT option. That would already solve most of the workflow problems.

1 Like

Thanks for the info on that, I had a hunch it might be related to the LUTs, glad I was at least on the right track and wasn’t doing something completely out of the ordinary. I noticed this same sort of issue in Unreal 5.3 as well which is what got me started down this whole rabbit hole. Thank you, thank you.