Closed sobotka closed 4 years ago
Here's a sample screenshot with the reference space being a smaller-than-sRGB coverage of values of +3 EV to -5 EV. Code value 253/255
results due to the incorrect edge sampling (?) behavior? Likely an EDGE_SIZE - 1
double up somewhere?
The reference space doesn't even cover the generic range that sRGB can cover and the edge error is apparent.
Branch: v1.1.1 tag head
Summary: OpenColorIO appears to exhibit GPU quantisation errors that are pronounced when using simple 1D LUT encodings such as the sRGB inverse EOTF. It appears that domain values near
[0.0, 1.0]
suffer from large 3D shader edge issues.Additional Information and Diagnostics: The example configuration located here has a trivial proof of principle. The reference space is a log2 shader allocation of -10 EV to +15 anchored at
0.18
as a middle grey value. Three display colourimetry sets are provided as follows:[0.0, 1.0]
FileTransform
ExponentTransform
[-0.125, 4.875]
The edge quantisation errors for the value
1.0
in the domain[0.0, 1.0]
case results in code value1.0
transformed into0.941
on round trip output. The stretched range seems to align the errors such that they are less noticeable. The screenshots below can be sampled for the peak 100% SMPTE test pattern. Also note that between the two identical 0.0-1.0 domains for the 1D LUTs, similar scaling errors are present between the entire range.Sample imagery from domain
[0.0, 1.0]
:Sample imagery from domain
[-0.125, 4.875]
Sample imagery from
ExponentTransform
: