Potential Op Optimiser bug with ExponentTransforms since OCIO v2.4.1

[KevinJW]

test_case.ocio.txt

We recently upgraded one of our 3rd party applications to a new version and this "broke" some of the display outputs. Replicated a fault by using ocioconvert and the attached test case.

Tested against OCIO versions:

2.1.3, 2.2.1, 2.3.0, 2.3.1, 2.3.2, 2.4.0 - All work identically and as was intended
2.4.1, 2.4.2 - appears to not include the 2nd ExponentTransform in the rendering and result in a 'linear' looking image
2.5.0 - Renders a 3rd result also different to the original

As a workaround inserting a RangeTransform before the ExponentTransforms restores the old behaviour within the limit of the 'clamp'

ocioconvert --view SonyF35.StillLife.exr "ACES2065-1" test1_utm_SonyF35.StillLife.exr "Test Case (2.4 P3 D65) - Display" "Un-tone-mapped"
ocioconvert --view SonyF35.StillLife.exr "ACES2065-1" test2_utm_SonyF35.StillLife.exr "Test Case 2" "Un-tone-mapped"

I have not yet delved into any of the optimiser updates, but I suspect that could be the source of the behaviour change.

Be good if somebody else can confirm if they think this is a bug before I go any further.

[doug-walker]

Hi Kevin, I only checked the 2.5.0 release, but it seems to be working as expected. For the first DisplayViewTransform, the unoptimized transform is this:

>>> dvt1 = ocio.DisplayViewTransform("ACES2065-1", "Test Case (2.4 P3 D65) - Display", "Un-tone-mapped")
>>> p1 = cfg.getProcessor(dvt1)
>>> p1.createGroupTransform()
<GroupTransform direction=forward, transforms=
        <MatrixTransform direction=forward, fileindepth=unknown, fileoutdepth=unknown, matrix=[0.9382798492772554, -0.004451445812361399, 0.01662752358677617, 0, 0.3373688907878367, 0.7295215666902654, -0.06689045747810234, 0, 0.001173950849685879, -0.003710706402052562, 1.091594506312247, 0, 0, 0, 0, 1], offset=[0, 0, 0, 0]>
        <MatrixTransform direction=forward, fileindepth=unknown, fileoutdepth=unknown, matrix=[2.493496911941426, -0.9313836179191244, -0.4027107844507172, 0, -0.8294889695615747, 1.762664060318346, 0.02362468584194359, 0, 0.03584583024378447, -0.07617238926804183, 0.9568845240076879, 0, 0, 0, 0, 1], offset=[0, 0, 0, 0]>
        <ExponentTransform direction=inverse, value=[2.6, 2.6, 2.6, 1], style=clamp>
        <ExponentTransform direction=inverse, value=[2.6, 2.6, 2.6, 1], style=pass_thru>
        <ExponentTransform direction=forward, value=[2.4, 2.4, 2.4, 1], style=pass_thru>>

And with the default optimization level, it becomes this:

>>> p1.getOptimizedProcessor(ocio.OPTIMIZATION_DEFAULT).createGroupTransform()
<GroupTransform direction=forward, transforms=
        <MatrixTransform direction=forward, fileindepth=unknown, fileoutdepth=unknown, matrix=[2.024905285966782, -0.6890697610347679, -0.3358355249320183, 0, -0.1835970322561775, 1.289506207759019, -0.105909175502841, 0, 0.009058561122347672, -0.05927968405755229, 1.050221122935207, 0, 0, 0, 0, 1], offset=[0, 0, 0, 0]>
        <ExponentTransform direction=inverse, value=[2.816666666666667, 2.816666666666667, 2.816666666666667, 1], style=clamp>>

Composition of ExponentTransforms with the clamp and pass_thru styles is allowed, the result just becomes a clamp style. And the exponent value of 2.8167 with direction=inverse seems correct.

The optimized version of your second DisplayViewTransform is this:

>>> p2.getOptimizedProcessor(ocio.OPTIMIZATION_DEFAULT).createGroupTransform()
<GroupTransform direction=forward, transforms=
        <MatrixTransform direction=forward, fileindepth=unknown, fileoutdepth=unknown, matrix=[2.024905285966782, -0.6890697610347679, -0.3358355249320183, 0, -0.1835970322561775, 1.289506207759019, -0.105909175502841, 0, 0.009058561122347672, -0.05927968405755229, 1.050221122935207, 0, 0, 0, 0, 1], offset=[0, 0, 0, 0]>
        <ExponentTransform direction=inverse, value=[2.6, 2.6, 2.6, 1], style=clamp>
        <RangeTransform direction=forward, fileindepth=unknown, fileoutdepth=unknown, minInValue=0, maxInValue=1, minOutValue=0, maxOutValue=1>
        <ExponentTransform direction=inverse, value=[1.083333333333333, 1.083333333333333, 1.083333333333333, 1], style=pass_thru>>

Which should be identical except for the clamp at 1.0, which would never be expected in the first transform.

There have been a couple of bug fixes over the past year that relate to this, so it is not unexpected that there could have been a change from 2.4.0 to 2.4.1 and then another from 2.4.2 to 2.5.0. Please see:
#2104
#2154

[KevinJW]

Thanks for looking at this. I've captured the GPU shaders from ociodisplay v2.4.0 and v2.4.1 for reference

v2.4.0_test1.txt
v2.4.0_test2.txt
v2.4.1_test1.txt
v2.4.1_test2.txt

I'm now going to bisect to see if I can find the cause of the change.

[KevinJW]

So far bisecting confirms that the change occurs with 1890b7d

[KevinJW]

And now for v2.5.0

v2.5.0_test1.txt
v2.5.0_test2.txt

This confirms we have a 3rd different gamma value in v2.5.0, but that the 2.5.0 shader is otherwise identical to the v2.4.0 output.

Now the question is what is actually correct, i.e. is 2.5 now correct and 2.4 was in fact buggy

[KevinJW]

For completeness further bisecting confirms the 2nd change was ac94d7b

[KevinJW]

In between meetings today I had a play around with improving the debuggability of the optimiser here:

https://github.com/KevinJW/OpenColorIO/tree/feature/optimiser_debugging

It would suggest that 2.5.0 is in fact correct and that maybe 2.4.0 (and earlier?) had a bug, but I haven't had the chance to back port that to see what was going on.