DaVinci Resolve DCTL and OFX Plugins

odt
resolve
colorcorrection
idt
lmt
look-transforms
workflow
Tags: #<Tag:0x00007f3c5ddd5298> #<Tag:0x00007f3c5ddd5130> #<Tag:0x00007f3c5ddd4ff0> #<Tag:0x00007f3c5ddd4eb0> #<Tag:0x00007f3c5ddd4d48> #<Tag:0x00007f3c5ddd4c08> #<Tag:0x00007f3c5ddd4ac8>

(Alex Forsythe) #41

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.


(Alex Forsythe) #42

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


(Scott Dyer) #43

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.


(Alex Forsythe) #44

@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 @CharlesBoileau 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.


(Paul Dore) #45

I have the same MacBook Pro. In Resolve, go to Preferences/Configuration and select CUDA for GPU processing mode, and Manual for GPU selection mode. You’ll have to save project and restart Resolve for the changes to take effect. If there is still a problem, it may be an issue with your CUDA driver (or something to do with which macOS you’re running).

The ACES DCTL set requires Resolve 15 Studio to work, but the OFX plugin will also work with Resolve 14 (both Studio and free version).


(Alex Forsythe) #46

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!


(Paul Dore) #47

My MacBook has CUDA driver version: 8.0.90 and
GPU Driver Version: 10.30.25 355.11.10.10.30.120 (though it may be a more up to date version, but renamed so that macOS recognises it).

I’m on macOS version 10.13.4

I think I had issues with the GPU Driver when I updated to High Sierra. There’s a possible work around here:

I would first try install the CUDA driver listed above, and then see it that’s enough to get it working properly.

http://www.nvidia.com/object/macosx-cuda-8.0.90-driver.html

There’s no need to use the web drivers on a real Mac. I use them on a hackintosh, but not on my MacBook.

High Sierra is the culprit in all this.


(Alex Forsythe) #48

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.


(Paul Dore) #49

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.


(Pedro Saboya Burgos) #50

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?


(Paul Dore) #51

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.


(Nick Shaw) #52

Is that missing ACES_Conversion.h in the includes?


(Deelan Sital) #53

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.


(Charles Boileau) #54

@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!


(Scott Dyer) #55

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.


(Nick Shaw) #56

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.


(Charles Boileau) #57

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!


(Nick Shaw) #58

Indeed you could. But there is no need for so many nodes. Using @Paul_Dore’s DCTL, you can combine multiple transforms into a single DCTL, as per my example above. Just replace the first aces = ACEScct_to_ACES(aces); line with the relevant IDT (and add ACES_IDT.h to the imports). I don’t know how Resolve optimises multiple sequential DCTL nodes, but you might find you get better performance with a single combined DCTL too. You could do the same for the output set as well.


(Charles Boileau) #59

You’re absolutely right! It was just for me to understand the workflow properly. ;o)


(Paul Dore) #60

I did some tidying up over at my GitHub page. Here are some of the updated links:

ACES 1.1 DCTL

ACES 1.1 OFX Plugin

ACES 1.1 OFX Source Files

I’ve merged the three different operating system specific files into a single plugin, so the same one will work on macOS, Win10, and Linux. Still CUDA only though.