[Bf-committers] Non-Standard sRGB OETF transform T51216

[Sergey Sharybin]

Answers are inlined

On Mon, Apr 17, 2017 at 8:26 PM, Troy Sobotka <troy.sobotka at gmail.com>
wrote:

> On Mon, Apr 17, 2017, 11:09 AM Sergey Sharybin <sergey.vfx at gmail.com>
> wrote:
>
> I think the inverse lookup is going to be subject to quite a bit of
> numerical degrading. You would need a shaper likely to properly resolve the
> values.
>

It doesn't matter whether you inverse LUT at a runtime or a-prioti if
interpolation is implemented properly. You can confirm that by comparing
values within the definition range of the table. The difference should be
well within floating point epsilon. Requesting values outside of the LUT
definition range is where the error happens.

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.

What i mean here is: this clipping is a subject for being fixed in OCIO.
This is just given fact.

Nearest interpolation does it correct btw.

Does the performance suffer with a 4096 LUT on the inverse Sergs? The 65k
> LUT,


Any inverse lookup will be slower that the straight one.

Using 4K points will be ~2x faster to find a point in LUT, but then you'll
still be doing some interpolation. So overall, using 4K points wouldn't be
as good as 2x faster. But that will still be slower than the use of
pre-computed inverse table.

Reducing number of points in LUT surely will affect on accuracy. And
accuracy with 4K points will be much worse than use of pre-computed inverse
LUT.

So i would suggest just to fix damn interpolation in OCIO.


> in addition to having unnecessary / unused ranges for the older SPI
> pipeline, is on the gargantuan side.
>

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.

>
> With respect,
> TJS
>
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin