Combine LUTs use pairIdentityReplacement when possible

[remia]

In some cases a pair of inverse / forward LUTs don't get optimized away by OCIO but instead combined in a single half-domain LUT. This seems to happen when there are a number of other operators in between, like a pair of MatrixOp to handle domain scales.

For context, the example I saw this in our config was in the case of an ACEScg to ARRI LogC4 -> CDL (identity) -> ARRI LogC4 to ACEScg conversion, the LogC4 LUT was designed to preserve -1 to 500 range. Here is the Group transform from the Processor for reference. Note that the ExponentOp clamp is ignored when optimizing.

<MatrixTransform direction=forward, fileindepth=unknown, fileoutdepth=unknown, matrix=0.9183876682136227 0.02254918208978807 0.05906314969658851 0 0.04367542261395546 0.8533787609135172 0.1029458164725261 0 -0.005022624839390726 0.004758976255720934 1.00026364858367 0 0 0 0 1, offset=0 0 0 0>
<Lut1DTransform direction=inverse, fileoutdepth=32f, interpolation=best, inputhalf=0, outputrawhalf=0, hueadjust=0, length=8192, minrgb=[-1 -1 -1], maxrgb=[500 500 500]>
<MatrixTransform direction=forward, fileindepth=unknown, fileoutdepth=unknown, matrix=1.430002152919769 0 0 0 0 1.430002152919769 0 0 0 0 1.430002152919769 0 0 0 0 1, offset=-0.4241785407066345 -0.4241785407066345 -0.4241785407066345 -0>
<MatrixTransform direction=forward, fileindepth=unknown, fileoutdepth=unknown, matrix=1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1, offset=0 0 0 0>
<ExponentTransform direction=forward, value=1 1 1 1, style=clamp>
<MatrixTransform direction=forward, fileindepth=unknown, fileoutdepth=unknown, matrix=1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1, offset=0 0 0 0>
<MatrixTransform direction=forward, fileindepth=unknown, fileoutdepth=unknown, matrix=0.6992996464782982 0 0 0 0 0.6992996464782982 0 0 0 0 0.6992996464782982 0 0 0 0 1, offset=0.2966279035598299 0.2966279035598299 0.2966279035598299 0>
<Lut1DTransform direction=forward, fileoutdepth=32f, interpolation=best, inputhalf=0, outputrawhalf=0, hueadjust=0, length=8192, minrgb=[-1 -1 -1], maxrgb=[500 500 500]>
<MatrixTransform direction=forward, fileindepth=unknown, fileoutdepth=unknown, matrix=1.08988212185032 -0.0284558573520009 -0.0614262644983184 0 -0.0564721174094855 1.17395999050224 -0.117487873092753 0 0.00574130479619738 -0.00572826056814317 0.999986955771946 0 0 0 0 1, offset=0 0 0 0>>

[doug-walker]

Remi, thanks for identifying this issue!

However, I'm wondering if it would be better to address this by changing OpOptimizers directly rather than moving optimization techniques into Lut1DOp::combineWith. In principle, this same problem could affect other ops, which would require making other op combineWith functions more complex as well. Plus, it sort of seems like a bug that the optimizer would even try to call combineWith on a set of pair inverses.

I've put together a PR that takes an alternate approach, namely only combining a single pair of ops before trying more preferred optimization techniques (such as removing pair inverses).

Please let me know your thoughts.

[remia]

Declining in favour of #2104.