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 <[email protected]> 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 <[email protected]> > 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 > [email protected] > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
