DaVinci Resolve 15 compatible DCTL scripts.
Place the ACES_DCTL folder in Resolve’s LUT folder (as is the case with other LUTs and DCTLs).
Porting CTLs that contain a 3D array (3D LUT) is proving tricky, but there is a workaround. You can also now link a LUT (1D or 3D) inside a DCTL (provided it is of the .cube variety). For example, the header
would be placed at the top of the script, and the LUT can then be applied as follows
const float3 res = APPLY_LUT(r, g, b, LMT_ACESv011);
This actually makes it easier to work with, as navigating a script with an embedded 3D LUT can be inconvenient at best. For existing examples of CTL scripts that contain a 3D LUT (LMT.Academy.ACES_0_2_2.ctl, LMT.Academy.ACES_0_7_1.ctl, etc), it would just be a matter of rearranging the arrays to conform to .cube specifications, adding the appropriate header and extension, and they’re good to go.
Edit: I compiled a simple OFX plugin using the new files.
ACES OFX Plugin macOS
ACES OFX Plugin Win10
ACES OFX Plugin Linux
ACES OFX Source Files
@Paul_Dore This is awesome! Community development at its best!
Thanks so much!
Great job Paul. Glad we now have LUT support in DCTLs.
You’re on fire @Paul_Dore! Fantastic work.
I had heard that Resolve 15 supported include statements but had no references yet on proper syntax and how to use. But it looks like you’ve already converted basically all the CTL to DCTL - can’t wait to test it out. Thanks!
Documentation and examples are available in the Help… Developer Documentation folder from Resolve 15 interface. Let us know if you need any specific help. We are working on adding more features to DCTL.
I was wondering how complicated it would be to convert all the ACES CTL library functions to DCTL, but shied away from doing it because it seemed like a mammoth task!
Great work @Paul_Dore!
Wow, can’t believe I missed that
I will definitely be tinkering around with @Paul_Dore’s fantastic work and seeing what else we can do with the DCTL. Thanks for the exciting updates!
Just did a quick test, and @Paul_Dore’s awesome work means it is now possible to build your own ACES pipeline in Resolve when it isn’t in ACES mode. Naturally, with great power comes great responsibility!
In my testing, my ageing 2010 Mac Pro, with K5000 GPU, was able to sustain real time playback (1080p25) applying an Alexa IDT, the RRT and Rec.709 ODT all in DCTL.
Not sure if you’re up for a little more work but some of us would love to see the ACES 1.1 Beta SSTS/Parametric ODTs in here. Exposing the parameters via an “advanced” menu in the OFX plugin would be helpful to power users.
Post a link to a specific ODT and list the parameters you want to have access to, and I’ll have a go (at some stage).
Thanks Paul … they can be found here
The ACES DCTL collection has been updated to include ACES 1.1 ODTs. The sample DCTL lists the new options (which are all executable).
That is by far the most useful collection of OFX plug ins i have ever come across!
More options added to the OFX Plugin.
More IDT and ODT options, and a custom ODT option that (when selected) reveals an additional 10 parameters. Available with both standard and inverse options.
Export DCTL option now available in the OFX Plugin.
The DCTL replicates the active processes of the plugin at the time of its generation. By default it is saved into the ACES_DCTL folder (where it needs to be in order to link to ACES_LIB files), otherwise Resolve will display a warning message (either the folder is missing or there’s a permissions issue). To access and enable the new DCTL, press the ‘Update Lists’ button in ‘Project Settings/Color Management/Lookup Tables’ followed by ‘Save’, just like you do when you add a new LUT while Resolve is still running. If you export a DCTL and there is already one with the same name at the target destination, then it will automatically overwrite the older one (once you click ok to confirm the export), but every export can have its own specific name.
The only difference between the OFX Plugin and DCTL (in terms of performance) is speed. DCTLs run faster as it’s all done on the device (GPU), whereas with OFX data is passed between the host (CPU) and device (which makes it a little slower). If speed is of particular interest, then the RRTODT (1.1) option runs faster than its equivalent RRT + ODT combination (1.0.3).
As is still the case, the DCTLs will only work in Resolve 15 Studio, but the OFX Plugins (should) work in both free and paid versions of both Resolve 14 and 15.
Hi to all!
@Paul_Dore thanks for this great plugin. Opens a bunch of possibilities for Resolve.
A few newbie questions:
- 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?
- 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.
- Can we use parts of this plugin while ACES is activated in Resolve?
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.
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.
@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,
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!