[Bf-committers] Non-Standard sRGB OETF transform T51216
troy.sobotka at gmail.com
Tue Apr 18 00:40:40 CEST 2017
On Mon, Apr 17, 2017, 1:29 PM Sergey Sharybin <sergey.vfx at gmail.com> wrote:
> It doesn't matter whether you inverse LUT at a runtime or a-prioti if
> interpolation is implemented properly.
The interpolation can't work terribly well, even with large tables. The
DolbyPQ is a good example. Too much compression in a range of nonlinear.
The same applies for 3D LUTs where you need a shaper to achieve a uniform
> This is not related on the inverse or direct sRGB transform, this issue
> will be visible with any 1D LUT (3D LUT i did not verify the clipping yet)
> on an extreme values.
Sean committed a patch that may address this. In theory, values beyond the
LUT should have been clamped to begin with. This could be another issue
rearing its head.
Any inverse lookup will be slower that the straight one.
See above. Doesn't work on many nonlinear LUTs.
> Using 4K points will be ~2x faster to find a point in LUT, but then you'll
> still be doing some interpolation.
> So i would suggest just to fix damn interpolation in OCIO.
It is a lookup search on the inverse, which delivers more accurate values
in heavily nonlinear curves. This is why most of the DolbyPQ transforms are
provided as nonlinear to linear, and the inverse is a lookup +
interpolation, as opposed to a lookup and interpolation on extremely dense
Speaking of unnecessary: this is fully unnecessary to bake transform which
> has simple definition with formula into a LUT. Such a baking just gives you
> hedaache with dynamic ranges without giving any speedup.
Except as you can see, the definition of "sRGB" varies pipeline to pipeline
as in this particular instance. And let's not even begin to dive into the
myriad of variations on 2017 era transforms.
There is an ExpressionTransform in the pipeline that will hopefully get
More information about the Bf-committers