1D LUT "linear" interpolation method is breaking with large values.

[KelSolaar]

Hi,

I noticed some noise in HDR light sources and after further investigation it seems like the 1D LUT linear interpolation method is breaking when subjected to large values, roughly around 65535 / 2: https://sendvid.com/wwqwmxdk

Reproducible using the following Nuke copy / paste:

set cut_paste_input [stack 0]
version 9.0 v4
Read {
 inputs 0
 file /Users/kelsolaar/Documents/Development/colour-science/colour-ramblings/resources/images/LuxoDoubleChecker.exr
 format "3115 1752 0 0 3115 1752 1 "
 origset true
 version 1
 name Read1
 selected true
 xpos -160
 ypos -85
}
EXPTool {
 mode Stops
 red 7
 green 7
 blue 7
 name Exposure1
 selected true
 xpos -160
 ypos -5
}
OCIOFileTransform {
 file /Applications/Nuke10.0v4/Nuke10.0v4.app/Contents/MacOS/plugins/OCIOConfigs/configs/nuke-default/luts/srgb.spi1d
 working_space linear
 name OCIOFileTransform3
 selected true
 xpos -160
 ypos 19
}
Viewer {
 frame 1
 frame_range 1-100
 name Viewer1
 selected true
 xpos -160
 ypos 43
}

The Luxo Double Checker image is available from Mark’s website: http://rit-mcsl.org/fairchild/HDRPS/Scenes/LuxoDoubleChecker.html

[KevinJW]

Looks like the output is unstable in terms of floating point precision

set cut_paste_input [stack 0]
version 10.0 v4
Constant {
inputs 0
channels rgb
name Constant1
selected true
xpos 586
ypos -329
}
Ramp {
p0 {0 0}
p1 {{width-1} 0}
color 10000000
name Ramp1
selected true
xpos 586
ypos -257
}

Simpler test case:

Version 1
From 0.0 1.0
Length 3
Components 1
{
0.1
0.6
1.1
}

If you feed ^that^ through the OCIOFileTransform and then into a Sampler node you will see the problem.

[KevinJW]

Potential fix...

https://gist.github.com/KevinJW/e14d19c5d6ad5af222982e22629df84d

This may or may not have better accuracy as it does subtract numbers that are likely close to each other, loosing precision. For more details... http://math.stackexchange.com/questions/907327/accurate-floating-point-linear-interpolation

which suggests testing the index against 0.5 and using separate computation for the two halves - at a loss of performance.

Kevin