DaVinci Resolve DCTL and OFX Plugins

Tags: #<Tag:0x00007febcdcbf640> #<Tag:0x00007febcdcbf500> #<Tag:0x00007febcdcbf3c0> #<Tag:0x00007febcdcbec90> #<Tag:0x00007febcdcbeb50> #<Tag:0x00007febcdcbea10> #<Tag:0x00007febcdcbe8a8>

(Scott Dyer) #21

Correct. The custom ODT code will not match the tone scale of ACES 1.0.3. It uses an adaptable single tone scale that is close to but not identical to the v1.x 48-nit tonescale. The custom ODT stuff is “experimental” but indicates the direction we are hoping to go in ACES Next. None of the tonescale or parameters are “final” yet. It’s merely a “proof of concept”.

But you are correct that it is “not the same” as the Rec 709 D60sim ODT currently built into Resolve.

(Paul Dore) #22

Can we add more IDTs and ODTs? For example: I use the P3-DCI and REC709 (d60sim) ODTs allot. But I don’t see them in the list. Am I missing something?

They’re not there, but they can be added in a future update. (They are already included in the DCTL collection though).

I tried building a custom ODT but the Results are “not the same”. For example tried to do a 709 D60sim ODT but the result was not the same as the one within Resolve.

This is probably due to an error on my part when translating the CTLs. It requires further testing, and input from those who contributed to the original code, to fix it.

Can we use parts of this plugin while ACES is activated in Resolve?

Yes, it can be used while ACES is activated. When ACES is activated , the process (usually) in Resolve is IDT to AP0 Linear, then AP0 Linear to ACEScc or ACEScct (depending on which one is selected in settings), then at the end of the pipeline is ACEScc or ACEScct to AP0 Linear, then AP0 Linear to RRT+ODT. You can select no Input and/or Output Transform in the settings, but this removes only the IDT or RRT+ODT transform. There will always be a AP0 Linear to ACEScc or ACEScct transform at the beginning and an ACEScc or ACEScct to AP0 Linear at the end when ACES is activated. There are options in the plugin that convert to and from ACEScc or ACEScct so that you can work in AP0 Linear (and avail of the LMT options).

If you want to to use a custom ODT instead of the built in Resolve options, then select No Output Transform in settings, and either with another iteration of the plugin or a DCTL apply an ACES to ACEScc or ACEScct transform to the last node, which will counter the mandatory ACEScc or ACEScct to AP0 Linear transform.

(Charles Boileau) #23

Thanks Guys!

@Paul_Dore: it would be great to see more “standard” odts (and IDTs) included in the plugin. At least the ones that are already in Resolve.

I thought for a second that your plugin might be the solution we needed to enable “onlining” in ACES. But it’s really Resolve that has a workflow problem. All titling and transitions etc… are done before ACES (yet being subject to the workflow without any parameters to adjust it). Your Plugin confirmed this.
I was hoping that all of these elements would react correctly If I built my ACES workflow while in YRGB. But unfortunately we see the same heavy aliasing on tilting even though we’re still in YRGB. It seems like it’s the ACES to ACEScct (back to ACES) that creates this unpleasant rendering.

I really wish BMD would look into this. It wasn’t a problem when we tested Baselight and it’s very frustrating,


(Charles Boileau) #24

I worked out a workflow that works. It combines Pre and post grade groups. What Resolve is doing wrong is that it runs everything from EDIT into the ACES workflow with our without applying an IDT. Thus transitions, titles and others online elements are just NOT MANAGED…

By applying the IDT in the Pre-Group section, ACES to ACEScct and ACEScct to ACES nodes I can work in LOG and linear (this is great for blurs and diffusions). Finally the RRT-ODT combo can be applied in the Post-Group. Enabling the switching of ODTs for different outputs.

By doing this the titles and all online elements are untouched by the ACES workflow…

A few caveats:

  • Any changes in groups (adding clips to a new groups) must contain the workflow. It will be apparent. But any outputs to a different ODT must be manually changed.
  • Maybe I could add and invert ODT to new ODT in the timeline nodes. But that would affect titles which have not IDTs applied. Is this a bad thing? I tried and it seems to do the right thing. For example: going from 709 to
    2020 desaturated the red drop shadow I added under the text.
  • Will it playback in realtime with some many added nodes?
  • We’d need to have all standard IDTS and ODTs installed in the presets. (SRGB, 709 D60, All P3s etc…)
  • The timeline NODES affects the titles, transition.

But all in all, this is probably the greatest ACES too I’ve had so far. It enables us to work ACES like compositors in Nuke.

I’ll be glad to contribute for future development! Do you need funds?

Also, the connected nodes in R15 will work wonders with this plugin!

Thanks for the great work!

(Paul Dore) #25

I recommend constructing a workflow using DCTLs first, as there are more options, and when it’s working as intended the plugin can be upgraded to accommodate needs. The plugin is effectively a user-friendly interface (albeit limited) for the DCTL collection, and will have new features added as time goes on, but power users will get better performance, modularity, and more choices when using DCTLs instead.

(Scott Dyer) #26

@CharlesBoileau I’d tend to agree with Paul about explicitly piecing together the proper chain using DCTL nodes for now. As he mentions, there are more options and you are able to be sure of each piece in the chain. (The Rec709 D60sim ODT should be available that way, too).

In general, I would exercise caution using any of this in any important productions just yet. That’s not to take away from the absolutely incredible amount of work that @Paul_Dore has already done on this, but I would just recommend some more testing and development before full trust. When I finish with my current workload, I certainly plan on doing my own testing so that I’ll be able to be conversant on the intricacies and caveats of using these new tools.

This entire thread is fantastic progress in usability of ACES in Resolve and holds a lot of promise for a very user friendly approach to help users have more flexibility moving forward. Let’s keep up the positive forward momentum!!

(Charles Boileau) #27

Thanks @Paul_Dore and @sdyer

Pardon my lack of technical knowledge… but how would I go about using the DCTLs? The folder has allot of files but they all end with a « .h » extension. Not sure on how I’m supposed to use them.


(Nick Shaw) #28

You don’t do anything with the .h files except copy them with the whole folder structure into your Resolve LUT folder. They are library files which define functions which the main DCTL files use. This makes the .dctl files smaller and more readable, as the functions which are used many times in different .dctls don’t need to be repeated in all of them.

UPDATE: Sorry, I realise now that there are no “main DCTL files” as such. There is the one ACES_Sample.dctl which shows you how a DCTL should be constructed using the library functions. Duplicate that, and edit each copy to perform a particular operation or sequence of operations. So a simple DCTL to build the entire ACES base processing (in DaVinci YRGB mode, so you are doing everything yourself) for ALEXA EI800 LogC would use only these lines:

#include "ACES_LIB/ACES_IDT.h"
#include "ACES_LIB/ACES_RRT.h"
#include "ACES_LIB/ACES_ODT.h"

__DEVICE__ float3 transform(int p_Width, int p_Height, int p_X, int p_Y, float p_R, float p_G, float p_B)

float3 aces = make_float3(p_R, p_G, p_B);

aces = IDT_Alexa_v3_logC_EI800(aces);

aces = RRT(aces);

aces = ODT_Rec709_D60sim_100nits_dim(aces);

return aces;


(Paul Dore) #29

More IDTs and ODTs have been added to the DCTL collection. Check the ACES_Sample.dctl for available (and executable) functions.

(Charles Boileau) #30

Thanks for the follow up.

It seems that I’m way out of my league here. I tried editing the DCTL but it seems that I lack the technical knowledge to understand how to correctly do this. I understand the premise but cannot implement.

@nick: could you post an example DCTL (the ALEXA IE 800 LOGc)? Maybe this will help me understand how to go about editing the DCTL.

So far, for people like me, the plugin would be the best option. But I would really like to be able to work the DCTLs.

Anywhere I could get some documentation or a crash course?

EDIT: I also tried to export a DCTL directly from the plugin and that gave me an error message when trying to apply it back on a node.


(Paul Dore) #31

He already did exactly that in his last post.

I also tried to export a DCTL directly from the plugin and that gave me an error message when trying to apply it back on a node.

Have you read carefully the instructions in the 1st post and the one that introduced the DCTL export option? For the DCTLs to work properly you need Resolve 15 Studio. The ACES_DCTL folder (containing ACES_Sample.dctl and ACES_LIB folder) goes into the same LUT directory as regular 3D LUTs. Copy Nick’s example code and paste it into a blank text file, change the extension to .dctl, and place it inside the ACES_DCTL folder.

Again, please read carefully the preceding posts, as you’re likely to find the answers to your questions have already been supplied.

(Jorge Ferraro Martin) #32

Thanks @Paul_Dore!


(Charles Boileau) #33

I read the first post when you started the thread. I was unable to get to testing before Monday. That detail must of slipped my mind after started to test the plugin in 14. Sorry for not running thru the instructions properly. I’ve been working on a workflow for months (that was at a dead end) and I was very excited about your plugin.

Did test in Beta 15 and it works. This really opens up a new world for us… The DCTL took a few seconds to load… Is this expected as it is looking up the all the different files?

Thanks again for the great work. I’d be willing to contribute in any way to help you with development.


(Paul Dore) #34

The OFX Plugin has been updated to include more IDTs and ODTs. Hue degrees have been reverted back to the original values and order (green at 120, blue at 240, etc.), so once again compliant with the source CTL code.