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?
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.
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.