"nan" (not a number) in InvRRT-ODT spi3d files

[michaeldsmith]

The value "nan" (not a number) appears in several inverse-RRT-ODT LUT files included in the ACES 1.03 OCIO Config:
'nan' appears 56534 times in InvRRT.P3-D60_ST2084__1000_nits_.Dolby_PQ_1000_nits_Shaper.spi3d
'nan' appears 45137 times in InvRRT.P3-D60_ST2084__2000_nits_.Dolby_PQ_2000_nits_Shaper.spi3d
'nan' appears 36663 times in InvRRT.P3-D60_ST2084__4000_nits_.Dolby_PQ_4000_nits_Shaper.spi3d
'nan' appears 49458 times in InvRRT.Rec.2020_ST2084__1000_nits_.Dolby_PQ_1000_nits_Shaper.spi3d

The first entry in the above four LUT files (on line 4 of each spi3d file) corresponding to input value 0 0 0 has output value nan nan nan, line 4 of those files looks like the following line:
0 0 0 nan nan nan
There are thousands of other lines in these files that also have nan output values.

If the display-referred input image to be processed by the inverse RRT-ODT LUT contains pure-black pixel value [0 0 0], which is of course very common, then the result of the output of the LUT is nan. This results in undefined/application-specific output. When using NUKE 11v1's built-in OCIO ACES v1.0.3 config, the value of these [0 0 0] input value is black and is shown as nan in the viewer's pixel sniffer and but it is rendered as max-white in the viewer and resulting output files.

Replacing "nan" with 0 in the above spi3d files leads to the expected result of black input values rendering back out to black output values. There may be better values to use instead of replacing nan with 0, but replacing with 0 fixed the nasty artifact to let me proceed with the project I'm working on.

The snip below shows an image processed with released ACES v1.03 LUTs containing "nan" (on the left side) and the same image processed by the same set of ACES v1.03 OCIO-Config LUTs but with the "nan" values replaced with 0.

[KelSolaar]

Hi @michaeldsmith,

Thanks, I looked quickly where they could be originating from and could not find anything obvious at first glance beside the fact it happens when ctlrender is called with some CTL transforms. We could certainly cull them with some post-processing of the files.

Cheers,

Thomas

[KelSolaar]

This was addressed in 1.1 on the colour-science fork.