Updated the readme and added a small fix in the ocio_transform–now it tries pyopencolorio first and if that fails it’ll fall back on ocio. Before it would try pyopencolorio and then give up, so on any box where the package was installed under ocio it was silently passing data through without doing any colour transform despite it having the capability which is arguably a bug.
Hope this helps.
you should always be able to pick up the autodesk flavor of ocio if you point to /opt/Autodesk/python/current/bin/python…
Oh wait
I forgot
there is no /opt/Autodesk/python/current/bin/python…
such an easy fix
such a waste of breath
FI-03212 | Python: Add a “current” path that points to the latest version.
I’d actually argue that the OCIO stuff is more than nice to have. It’s great to have the same color transforms as we have in Flame. It feels far more familiar for me and I have faith that the logic is correct.
Another thing I greatly appreciate is your browsing function/interface. The typical loader and, for that matter, all the other loaders (i.e. CoCo) lack this and it’s très annoying.
Thanks for working with me on this. I really ought to have just followed the instructions more closely. It’s a bit annoying that PyOpenColorIO isn’t available for 3.12 (or at least for M-based Macs).
I’ve updated the workflow now and made a couple quality of life fixes.
Enjoy.