ACES 2.0 Output Transform performance optimisation

[cozdas]

This is a slightly polished version of @KevinJW's optimization work. Attaching below Kevin's original PR comment

---

Overall the main algorithm changes come from:

1. Precomputing a number of the scaling factors, etc during the init stage
2. Some micro optimisations, reformulating things to use fewer divisions
3. Redistribution of the sampled hues to be more linear whilst still including explicit sampling of the corners of the gamut. This allows us to have a much narrower search range for the hue table lookup.
4. Some calculations have been migrated up the "call stack" to allow the results to be reused
5. Adjustment of the upper hull slope calculation parameters to allow for the elimination of a call to pow replaced with a multiply
6. Splitting some functions to allow exposure of the Achromatic and using that in the tonescale calculation
7. The gamut compression was calculating various slopes which nominally should all have been the same value

Things not really done, but could be in the future mostly CPU side and primarily by vectorising:

1. A number of the functions could be looked at and reformulated to take/return only the attributes they change, e.g. J or M rather than full JMh, might help with a vectorised implementation
2. The 3x3 matrix uses could be much faster may want to try 3x4 and a simple vectorised code, alternatively...
3. Generally the whole transform is run per pixel, may be worth looking at running smaller parts of the code on lines of pixels and using intermediate buffers for partial results.
4. May be worth reforming the pow() calls into appropriate logarithm/exponent form
5. The Hue lookup binary search whilst heavily improved could probably be unrolled for many of the common gamuts as the search range is often within 3 positions

General observations

The algorithm makes heavy use pow(), so it is heavily influenced by the system C library implementations.

We need finer grained testing for C++ functions rather than at an "Op/Transform" level

GPU shader generation notes:

We may want to add wrappers for compatibility to the shader generator

• log10()
• atan2()

We have a sign() wrapper but none of the code uses it.

[remia]

While I didn't review in details the line by line changes, I tested that this was indeed improving speed and had a similar or better roundtrip than 2.4.1. The initialisation time (LUTs creations) also seems similar compared to 2.4.1. I also ran the GPU tests on a few different platforms (macOS GLSL and MSL, Linux GLSL and Windows GLSL) successfully.

In previous work in progress commits I saw issues with C++11 support but this is now fixed.

Also checked for NaN in the D65 roundtrips in the CMS and Cube faces images.

Great work @KevinJW and thanks @cozdas for the fixes !

[zachlewis]

The improvements seem well reasoned... although I can't claim to understand everything that's happening, nor can I really speak to the relative efficiency of the code... the code looks good and smart and not malicious and well-tested to me, and doesn't cause anything to break when I try to build it!

[doug-walker]

Thank you @KevinJW , @cozdas , @remia , and @zachlewis for your work on this! I will merge this for inclusion in OCIO 2.4.2.

[remia]

@doug-walker it looks like the builtin transform round trip tests are triggering a warning that makes the platform latest workflow fail. Will need to initialise all three variables to 0 to make it go away.