709 "IDT" and ADX10

Hi to all,

I was wondering what was the appropriate chain of transforms for 2 purposes. I’m now testing @Paul_Dore’s DCTL (for Resolve) workflow and looking at different situations that might arise.

How is Rec709 footage “imported” into ACES? Is it by applying a invODT at the input?

Same for ADX 10… I’ce tried applying the ADX10_to_ACES.dctl on input but it doesn’t work. Do I have to linearize first?

Thank you very much.


I found the answer to the 709 workflow. But the ADX is not working… I’ll check with the person concerned.

You seem to have found this already, but just to confirm, where you want the Rec.709 footage to appear identical to the original on a Rec.709 output, you use the inverse ODT (and inverse RRT) so that the entire pipeline cancels out. If you are using Rec.709 as a scene referred format from a camera (albeit a very limited one in terms of dynamic range) you need an IDT which simply inverts the Rec.709 encoding curve, and transforms the primaries to AP0, just like any other camera IDT. I believe Resolve includes this IDT under the name “Rec.709 (camera)”.

Film is not my field of expertise, but I can tell you that ADX is a logarithmic encoding, so you should not need to linearise first. Your material will need to have been scanned on a system set up for ADX in order to work as intended. The ADX10 IDT will give an approximately correct result on a generic Cineon scan, but the format is supposed to be more specific than that.

There was an issue with the ADX10_to_ACES transform. The interpolate1D function was not getting the correct value with regards to the size of the array, and the definition of REF_PT was also returning an incorrect value.

Even though the function for deriving the size of an array conforms to published definitions, it’s not working here, so I’ve updated the interpolate1D function with an extra argument to solve the issue.

For some reason unbeknownst to me, the REF_PT definition was not returning the correct value, and this was solved by placing it in brackets and multiplying by 1.0f

Anyway, it appears to work now, and I’ve updated the ACES_DCTL set (as well as the ACES_OFX source files and macOS branch of the plugin).

Thanks @Paul_Dore! Sorry for the radio silence I was grading. I’ll try it ASAP