DaVinci Resolve DCTL and OFX Plugins

Hi to all,

I’ve tested extensively the DCTLs scripts and they will quite useful in R15. Especially, considering that (for now) all of the edit created titles, transitions etc… go thru the ACES pipeline unmanaged.

I did not find any bugs or any performance problems associated with the use of the DCTLs. There is some caveats if the user is not well versed in understanding ACES as you could potentially grade outside or before ACES and induce errors.

That being said. It’s seems pretty solid!

Cheers!

Hi, I tried to install the OFX plugin, I place it in the Macintosh HD/Library/OFX/Plugins Folder, but it wont appear in the OpenFX Library in Resolve.
I run Resolve 14.3 on a Mac Pro 2013 (AMD CARDS) with High Sierra installed.
I tried to install also some of the other Plugins you created, and I had the same result. Only the MATTE one is working. Is my version of Resolve?
Thanks in advance Paul

Most of the newer plugins (including ACES OFX) are Cuda only. Most of the legacy plugins are OpenCL compatible. The more advanced features of the new plugins will only work with Cuda, so no plans to attempt further cross compatibility in the near future.

Ok, thanks for the quick replay Paul! Great work by the way!

The ACES DCTL collection has been updated to the official ACES 1.1 release.

New files:

ACES_LIB/ACES_ODT/ODT_P3DCI_D60sim_48nits.h
ACES_LIB/ACES_ODT/InvODT_P3DCI_D60sim_48nits.h

ACES_LIB/ACES_UTILITIES/DolbyPQ_to_HLG_1000nits.h
ACES_LIB/ACES_UTILITIES/HLG_to_DolbyPQ_1000nits.h

ACES_LIB/ACES_LMT/LMT_BlueLightArtifactFix.h (formerly LMT_FixHighlightImageArtifacts.h)

Updated files:

ACES_Sample.dctl
ACES_LIB/ACES_LMT.h
ACES_LIB/ACES_ODT.h
ACES_LIB/ACES_Utilities_Color.h
ACES_LIB/ACES_RRT_Common.h
ACES_LIB/ACES_OutputTransforms.h

The LEGAL_RANGE and SURROUND options are now enabled in the new Output Transform functions.

ACES 1.1 DCTL

2 Likes

Has anyone successfully gotten these running on a Macbook Pro?

I have a Mid-2014 MBP with 16GB RAM and a GeForce 750M. I can get them working if I use the Nvidia web driver and cuda, but I keep running into a major problem. When using DCTL or the OFX Plugin Resolve will suddenly suck all my computer resources and basically lock the machine up. There have been a few instances where I was able to quit resolve and the computer came back, but it’s very annoying.

This happens under both Resolve 14 and 15 so I’m thinking it’s related to the Nvidia Driver. Any thoughts would be greatly appreciated.

FYI … also the OFX plugin doesn’t seem to be working for me in Resolve 14 Studio. Not sure what the issue is there.

I believe this has been asked and answered multiple times in this thread. The plugin requires Resolve 15 since it calls on the DCTL with #include statements.

@sdyer Below is the quote from @Paul_Dore that the OFX plugin should work in Resolve Lite and Studio in both 14 and 15.

The point that was addressed was @chuckyboilo trying to export DCTL out of the plugin in Resolve 14. That obviously doesn’t work because DCTL in Resolve 14 doesn’t support #include statements but I believe the plugin itself should still work on Nvidia systems with Resolve 14 based on @Paul_Dore previous comments.

Thanks @Paul_Dore

GPU Driver Version: 355.11.10.10.35.101
CUDA Driver Version: 396.148
MacOs Version : 10.13.5 (17F77)

Are you running the Nvidia Web Driver or just the stock MacOS GPU driver? Resolve doesn’t seem to recognize my GPU as Cuda capable with the stock MacOS GPU driver.

Thanks again for the confirmation!

Odd … followed the instructions above and it fixed in the “Update Required” issue when using the mac GPU driver, but Resolve still complained about not being able to find a CUDA compatible GPU. It seems to work as long as I use the Nvidia driver.

My set-up is specifically suited for compiling plugins for Resolve, hence the CUDA 8.0.90 driver. Otherwise I would probably use the most up to date versions (provided they work). The throttling issue is something worth approaching either Apple or Blackmagic Design about.

Hey everyone and Paul!

I’ve been trying to work with ACES inside Resolve’s YRGB mode using DCTLs instead of your ACES OFX plugin, as you recommend.

At first, I tried exporting DCTLs with the proper transforms from the Plugin, but couldn’t due to a permissions issue (even to the default folder). So I’m using your ACES_Sample as a reference, so I could create DCTLs for the transform.

For the IDT/ACES_to_ACEScct, it worked well, just like the OFX.
For the ACEScct_to_ACES/RRT/ODT (rec 709), it didn’t. I can’t figure out what I’m doing wrong.

IDT:
#include “ACES_LIB/ACES_IDT.h”
#include “ACES_LIB/ACES_LMT.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 = ACES_to_ACEScct(aces);
return aces;
}

ODT
#include “ACES_LIB/ACES_IDT.h”
#include “ACES_LIB/ACES_LMT.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 = ACEScct_to_ACES(aces)
aces = RRT(aces)
aces = ODT_Rec709_100nits_dim(aces);
return aces;
}

Can anyone help me figure out what I’m doing wrong?

What does it say in the davinci log files? The source of the error can be traced there. Also, list your operating system, version of Resolve, and the exact location of the dctls.

Is that missing ACES_Conversion.h in the includes?

Dear Paul,

Thankyou for this OFX plugin. Its a great timesaver.
Just wondering if support for Sony Raw is available? Currently if i put it as bypass it still works on OFX but for sake having already some Sony transforms there already would be benificial.

The other thing is the plugin currently works on my 2009 Mac Pro. which has Nvidea cards.
Unfortunatly Trashcan mac Pros only have AMD cards which make the plugin unworkable.

Pedro (on the thread above) has suggested to build the DCTL using the sample file.
Coming from a total noob it looks alittle menacing if i change the values.

But am I right in removing the // tags to activate certain aspects of the OFX options?

I know youre only doing support for Cuda based setup but for those who are later Macs which are AMD based, what would you suggest to do?

Thankyou nonetheless.
Why doesnt BMD implement this brilliant workaround i dont understand. Giving big props and share of money you’ve given to the community.

1 Like

@Paul_Dore. Just updated to R15.1.1 and now considering using the DCTLs actively…

I have a question for you and @sdyer: The highlight fix LMT used to be applied directly on the clip in Resolve. Could we fit it somewhere else in this DCTL workflow? I tried adding it as the first and last nodes, after and before the RRT and after the IDT. This is not producing the same result as adding it directly to the clip (which I think might be problematic since the clip is technically not in ACES at that particular position).

So I guess my question would be: where do we put this RRT in the workflow?

Thanks!

I haven’t done any testing recently but would be happy to look into this.

To be clear what we’re talking about here,

1)What version of the highlight fix LMT are you using?
Are you using a DCTL version (like this one https://www.dropbox.com/s/itmg7pvrwr67nz9/LMT.Academy.FixHighlights.dctl?dl=0)
or are you using Resolve’s CLF implementation?

It sounds like you’re using DCTL. Have you tried using Resolve’s provided sample CLF?

2)What is your “Process Node LUTs in” dropdown set to? (in Settings->Color Management->Color Space and Transforms)

The DCTL is supposed to be applied in to ACES values (AP0/linear), so if this option is set to ACEScc AP1 Timeline Space, that could be causing the differences you’re seeing.

It absolutely shouldn’t go after the RRT. The artefacts happen in the RRT (or at least begin in the RRT and are hit home by the ODT). It really needs to be applied up front, to fix the image data before you do anything else to it.

If you are using @Paul_Dore’s DCTL, you could put it as the first node in the node tree, as long as it is sandwiched between transforms from the working space to ACES2065-1 and back. Something like the following (untested) code:

#include "ACES_LIB/ACES_LMT.h"
#include "ACES_LIB/ACES_CSC/ACES_Conversion.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 = ACEScct_to_ACES(aces);
aces = LMT_FixHighlightImageArtifacts(aces);
aces = ACES_to_ACEScct(aces);

return aces;

}

Or you could bundle the IDT and LMT fix into a single DCTL which goes camera log −> ACES2065-1 −> LMT fix −> ACEScct.

Thanks @nick! Always very helpful!

Could I consider doing the following:

Node 1: IDT
Node 2: MT_FixHighlightImageArtifacts
Node 3: ACES_to_ACESccct
Subsequent nodes: color work

Then: ACEScct_to_ACES, RRT, ODT

What do you think!

Thanks!