[EzulFilm]

The ACES 2.0 gamut compression returns NaN for some very bright colours.

Example:

import numpy as np
import PyOpenColorIO as ocio

gc = ocio.FixedFunctionTransform(ocio.FIXED_FUNCTION_ACES_GAMUT_COMPRESS_20,
                                 [100.0, 0.64, 0.33, 0.3, 0.6, 0.15, 0.06, 0.3127, 0.329])
cpu = ocio.Config.CreateRaw().getProcessor(gc).getDefaultCPUProcessor()
a = np.array([[100.0, 10.0, 46.0]], dtype=np.float32)   # J (lightness), M (colourfulness), h (hue)
cpu.applyRGB(a)
print(a)  # [[nan nan 46.]]  expected [[100. 0. 46.]]

Through the built-in studio config, the range clamp after the output transform turns the NaN into 0, so these pixels render black among white neighbours. For example, ACEScct [1.02502234, 0.90455188, 0.68137096] gives (0, 0, 0) on "sRGB - Display" / "ACES 2.0 - SDR 100 nits (Rec.709)".

In this code, J is the lightness in the JMh space the transform works in, and its upper limit limit_J_max is exactly 100.0 at 100 nits. A colour with J = 100 passes the J > limit_J_max early-out. solve_J_intersect then returns J_intersect_source a float step above the limit (100.0000076), because J = limit_J_max is an exact root of its quadratic. In find_gamut_boundary_intersection, J_max - J_intersect_source is slightly negative, powf of it is NaN, and the gamut_boundary_M <= 0.f guard does not catch the NaN.

Fix: clamp that value at 0, on the CPU and in the generated shader text. The boundary M is then 0, and the existing guard returns {J, 0, h}, the same as for J above the limit (white).

Tests:

• aces_gamut_comp_20_limit_J: forward and inverse, J at the limit and the 3 float steps below it, all hues in 0.5° steps, 4 values of M; all outputs finite.
• aces_output_transform_20_limit_J: an AP0 input that reached the limit inside the output transform now gives display white instead of NaN.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: EzulFilm / name: Kazuaki Matsumura (59a7fe0)

[EzulFilm]

Hi, thank you for OpenColorIO. I hit this while comparing ACES 2.0 renders: a few very bright pixels came out black while their neighbours were white.

What I checked:

• test_cpu_exec: 1205 passed, 0 failed (Release, GCC 13.3, Ubuntu 24.04 on WSL2).
• On 6.5 M sampled inputs, every output that was finite before is bit-identical to the 2.6.0 wheel; only the former NaNs change.
• At J = 100, M = 10, 145 of 720 hues returned NaN before the fix.
• Not run on a GPU. There, pow of a negative base is undefined rather than NaN, which is why the shader text gets the same clamp.

If you'd prefer a different fix, I'm happy to change it: clamping the result of solve_J_intersect to limit_J_max, or a NaN-safe guard !(gamut_boundary_M > 0.f). This may also answer the // TODO: when/why does this happen? next to that guard.

This is separate from #2132 (the divide by zero in Aab_to_RGB for the inverse). The ACES reference has the same expression and guard (aces-core lib/Lib.Academy.OutputTransform.ctl, lines 659 and 752 at 069b0bc). I haven't run the CTL, so I haven't confirmed it produces NaN there too.