Is there a way to use OpenColorIO in Resolve?
That would probably solve a lot of transform problems. I thought maybe there is an OpenFX plugin somewhere like I use OpenColorIO as a plugin in AfterEffects.
The official OpenColorIO website lists no OpenFX version. But maybe there is one somewhere?
Natron seems to be things along those lines here: https://github.com/MrKepzie/openfx-io
I never look into it so I’m not sure how it would work in Resolve.
What are you looking to achieve with OCIO that you can’t do with the built in Color Transform effect or DCTL?
TuttleOFX has a basic OCIO plugin but you need to manually set environmental variables to access the config and it tends to crash Resolve if you can get it working at all. Its more stable on Windows than OSX but certainly not enough for anything important.
As Nick says, the builtin Color Transform plugin and DCTL are sufficient for most things (except maybe certain ACES RRT and ODT CTL functions). Users who don’t have the Studio version of Resolve (with DCTL support) can always roundtrip and use OCIO in Nuke or Fusion if necessary and some of us can supply bespoke lut or plugin solutions if needed.
I still find it bit odd that BMD decided to reinvent the wheel with RCM and DCTL when CTL and OCIO are so widely supported in other apps but then again Filmlight do it too with Truelight Colour Spaces (much better I might add) so it’s not that unusual I guess. Better OCIO support will definitely come to Resolve and I’m sure BMD will continue expanding RCM but for now there are workarounds for nearly anything you want to do.
Thanks for your help! I was just wondering if it’s possible.
OpenColorIO works so well in Aftereffects that I thought it would be a good solution for Resolve also.
I can understand the basics of what is written in a CTL or DCTL code, but I cannot write a DCTL on my own.
Of course, I can ask you for help, like when Nick did the SLog3/SGamut3.cine IDT that I needed.
But again: I was just thinking if OCIO would work with Resolve, all transforms would be available instantly.
CTL was never designed to be a real-time system. It was only ever intended to be a reference.
In a grading system, real-time is very important, so BMD and FilmLight have built their own optimised implementations.
I know but surely they could have retained direct CTL compatibility for IDTs etc without us needing to rewrite them. I did think of writing a script to translate CTL into DCTL but that seems like a lot of work for no good reason.
I don’t mean to knock BMD (you really can’t beat Resolve for the money) but implementing OCIO instead of RCM would have been a much more flexible solution for colour management and can be built with more than enough precision for any grading app. The same can be said for Adobe apps but they are too heavily built around ICC.
[quote=“cinelogdcp, post:7, topic:695”]
I know but surely they could have retained direct CTL compatibility for IDTs etc without us needing to rewrite them. I did think of writing a script to translate CTL into DCTL but that seems like a lot of work for no good reason.[/quote]
While it’s true that translating most CTL IDTs to DCTL is straightforward, and could be automated, that really only applies to the common ones for log formats, which are just a transfer function and 3x3 matrix. IDTs don’t have to be that simple. Remember the old Canon IDT, with its 17x3 matrix? And IDTs for colour baked formats could potentially be far more complex.
If they offered direct CTL support, but didn’t support everything, that could be problematic. DCTL is designed to be directly compiled as a shader. CTL is not.
OCIO is substantially built around LUTs, and can run up against the limitations inherent in that. I can completely understand why they went for a modern shader based approach. That is the direction everybody is heading, and rightly so, in my opinion.