[Draft] ACES2 Output Transforms

[remia]

Opening this PR early even though it's very much a work in progress / prototype so far, the code is more or less imported directly from the CTL.

Next steps includes:

• Adding all the official output transforms from the ampas repository
• Adding support for creative white point and surround gamma factor
• Review lookup table constexpr initialization (assuming OCIO 2.4 moves to C++14, C++14 has limitations in constexpr support making it less clean, increase library size (probably), custom compiler flags needed to lift constexpr instruction count limit), implement caching for custom output transform's tables
• Review current CPU code duplication (reimplement NPM derivation, matrix inversion, etc) that are available in other place in OCIO, though typically using the Ops abstraction, not native code / types
• Optimize CPU path (currently 8x slower than ACES 1)
• Implement GPU path
• Cleanup the FixedFunctions used for testing
• Add tonescale (Daniele's curve) only FixedFunction

[linux-foundation-easycla[bot]]

• :x: The email address for the commit (bc3be886248f290f19ed80e75d4a2f7b6500d988) is not linked to the GitHub account, preventing the EasyCLA check. Consult this Help Article and GitHub Help to resolve. (To view the commit's email address, add .patch at the end of this PR page's URL.) For further assistance with EasyCLA, please submit a support request ticket.

[doug-walker]

Thank you so much for doing this Remi! Everything aside from ACES2CPUHelpers.h looks perfect. And please assume that OCIO will move to C++14 minimum if that allows a cleaner implementation.

I understand, as you wrote above, that the ACES2CPUHelpers.h module is a direct port of the CTL. But wow, this still really feels like research code. I'm surprised it's only 8x slower than ACES 1, there are so many unnecessary conversions being done. I know you wrote above that optimization is still a TODO, but it really seems like that is going to be a huge task in order to get something reasonably performant. I don't think it's simply a matter of pre-multiplying a few matrices and swapping in the fast power function. For example, I see things like:

    const float linear = Hellwig_J_to_Y(inputJMh[0], inputJMhParams) / reference_luminance;
    const float luminanceTS = tonescale_fwd(linear, params);
    const float tonemappedJ = Y_to_Hellwig_J(luminanceTS, inputJMhParams);

And that seems like it should be replaced by a spline or something. But building these approximations would take time and may not be exact. I'm very worried about the amount of work here, given that OCIO 2.4 is supposed to release in only a few months. It seems like we need more people working on this.

I feel like we should ask the ACES WG to provide CTL that is closer to being ready to implement?