On Mon, Apr 17, 2017, 1:29 PM Sergey Sharybin <[email protected]> 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 perceptual range. > 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 values. 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 committed soon... With respect, TJS _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
