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

[Sergey Sharybin]

This is because OCIO is rather a joke and takes much much much more time to
perform inverse transform. And it doesn't even cache anything, so it
performs expensive inversion for every pixel, every frame slowing
everyone's workflow like hell.

The new inverted transform is calculated from the original forward transfom
by simply transposing it. I am not sure what is wrong there and your
feedback is rather vague. Please attach .blend configured in a way which
shows that something became broken after that change.

On Sat, Apr 15, 2017 at 12:55 AM, Troy Sobotka <troy.sobotka at gmail.com>
wrote:

> Whoops... wasn't T51216, but rather
> https://git.blender.org/gitweb/gitweb.cgi/blender.git/commit/
> 6fb874369c31649de7232235b0114344bfdb8e92
>
> Anyways, the values and ranges are off and it breaks HDRIs.
>
> With respect,
> TJS
>
> On Fri, Apr 14, 2017 at 3:53 PM Troy Sobotka <troy.sobotka at gmail.com>
> wrote:
>
> > Any reason that the nonstandard sRGB OETF transform was expanded to
> > include an "inverted" LUT as well?
> >
> > Why wasn't OCIO's native inversion sufficient? Why is the inverse
> building
> > upon the nonstandard SPI based sRGB transform versus a proper 0.0 to 1.0
> > sRGB OETF?
> >
> > 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