"nan" (not a number) in InvRRT-ODT spi3d files #16
Description
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.
