Aces Inverse IDT transform using OCIO Library

Hey I am trying to implement ACES 1.3/2.0 using OCIO library.
I am currently unable to apply an INVERSE IDT ACES trasnformation on the image.

Currently the ODT and Colour transforms are working correctly. However, I am undable to perform and inverse ACES IDT transform. There seems to be a step im missing. From browsing the forums it mentions the aces transformation requires a chromatic adaptation from the source colour space to AP0 or AP1 whitepoints.

My understanding of colourscience is poor at best. Any help in usage of OCIO or on the aces workflow would be greatly appreicated.
Knd regards,
Tristan

What version of OCIO and config are you using?

Using studio-config-all-views-v4.0.0_aces-v2.0_ocio-v2.5 and studio-config-v2.2.0_aces-v1.3_ocio-v2.4
Made slight changes where I’ve duplicated all the shared views and added the look ACES 1.3 Reference to the new shared views.
looks: ACES 1.3 Reference Gamut Compression.

OCIO Im using is v2.5.0, built myself.

@tristan.sear , regarding your statement “I am currently unable to apply an INVERSE IDT ACES trasnformation”, could you please provide the exact source and destination color space name strings that you are using with the OCIO ColorSpaceTransform?

So Code looks like this
m_colourProcessor = m_ocioConfig->getProcessor(source space),
m_displayName, m_viewName,//display and view transforms
m_ocioForwardDirection ? OCIO::TRANSFORM_DIR_FORWARD : OCIO::TRANSFORM_DIR_INVERSE);
where as doing an inverse we use TRANSFORM_DIR_INVERSE -
Source as ACES2065-1
Display as Rec.1886 Rec.709 - Display
View as ACES 2.0 - SDR 100 nits (Rec.709).

What I notice when performing the process using a cpuProcessor (test with OPTIMIZATION_NONE - OPTIMIZATION_LOSSLESSand OPTIMIZATION_ALL) at bitdepth BIT_DEPTH_F16 and BIT_DEPTH_F32

The Process always crashes with in the reach_m_from_table function in transform.cpp it appear i_lo and i_hi are out of range of the array. (361 and 362 with the hue array of 1-360)
Catching the crash when running the code this time - the current rgb values from the image are 0.00677728886,0.000228424367,0.00195409427.

After doing more testing I found this issue only occurs when running in debug mode - applying the inverse IDT seems correct running in release mode an almost matches resolves Inverse IDT to a sub 10 difference.

Tristan, the subject heading for this issue is confusing. In ACES, “IDT” stands for “input device transform” and that is not what you are working with. You are working with an inverse Output Transform.

I think you are probably running into this OCIO edge case issue, which is fixed in the current release:

Please update to OCIO 2.5.1 and try again.

Sorry Doug, relatively new to colour science and espically ACES.
In regards to upgrading to 2.5.1 that fixed the issue Thank you so much.

This is out of scope of this thread - but as an aside is there a forum or thread for pest practices in regards to getting the most performance off OCIO CPU (the GPU code is exceptional). Currently splitting the images into groups of scans lines (32 lines per group in this case which how we optimise the rest of the workflow/rendering) and its taking 100 ms roughly to process the frame this is with optimisation all for hd 1920x1080 content. I am reusing the main processor but not the CPU processor.

Glad that solved the issue Tristan!

Regarding CPU performance, multi-threading will be important in order to use all the cores. OCIO does not do the threading itself, so it is up to the application to do that.

The best place to ask OCIO questions is in the #opencolorio channel on the ASWF Slack, so I suggest moving the optimization questions over there to put it in front of more sw devs.