Try this example to see if it will work (place it in Resolve’s main LUT folder Blackmagic Design/DaVinci Resolve/LUT)
DEFINE_LUT(Rec709_Kodak_2383_D65, Film Looks/Rec709 Kodak 2383 D65.cube)
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 rgb = APPLY_LUT(p_R, p_G, p_B, Rec709_Kodak_2383_D65);
return rgb;
}
If the DCTL is in a folder within Resolve’s main LUT folder e.g. Blackmagic Design/DaVinci Resolve/LUT/DCTL/DCTL_LUT , then the top definition would be
It might get a bit tricky if you’re moving the DCTL to different locations while running tests, especially with the DCTL OFX Plugin, so you might have to restart Resolve instead of just clicking Update Lists in Project settings.
Hi guys, and Paul. First of all thanks Paul for all the effort you are putting into your plugins, I have been using them in some of my works with nice results…
As a long time ACES user I want to take a step forward and try to make custom pipelines and avoid resolve one. I have been toying with your dctl/ofx without luck. I have two questions( I tried check around the forum but I didnt find any concrete answer or maybe It was lost in a wall of text).
-First is about IDT for R3D files, I just found the IPP2 one in the .h library, is it because is still not implemented, I tried check on OCIO libraries but they in python so I understand the libraries are custom made by Paul, I’m wrong?
-Second is much more easy, trying the plugin(I know the dctl is better but I just wanted to check everything was alright before) I didnt get the desired results:
NODE 1:
Process= Standard
IDT:Alexa Raw
ACES to:ACEScct
NODE:2 :Grading etc…
NODE 3:
ACES from ACEScct
RRT Enabled
ODT: rec709 100nits Dim
I’m getting really funky results( Note I tried the workflow with the ACES Resolve ofx and It worked as intended)
-Lastly I would like to ask If It will be a good practice to create the pipeline with the ofx plugin and then export the dctl so we get the best of both worlds.
Thanks in advance and sorry if It has been answered elsewhere).
With R3D files, you would use the Colour Space Transform OFX Plugin in the first node to convert to ACEScct AP1.
See post 83
You can do this, but it’s not a substitute for understanding how to build a pipeline directly with the ACES DCTL set. If you’re looking for short-cuts in this regard then you’re only inviting trouble on yourself.
it took me a while to figure it out, but the underscores bevor and after “DEVICE” where missing. I think they might be trunkated when pasting code into this forum.
Ok, I have been testing the DCTL(for DR 16) all day, I found some stuff on the sample:
The RRT function is on capital letters but in the library is on lowercase.
The IDT for Alexa Raw it has two 00 more at the end. I’m also not sure about this IDT since I’m using it with arriraw footage and it goes almost fully white, the other Alexa IDT works fine, I tried find info about this IDT but didnt find so maybe is special?
-I have a question about where does the dctl work. I mean, I should cut the pipeline in the middle to work in the node between( As I would do with the standard ACES plugin, or does the dctl work some stuff(IDT) before the node operation and the others at the end? Like it would happen if you use the color management tab.
I will keep checking and thanks for all the hard work Paul!!!
This should be changed back to uppercase. I was running tests with the new Combo Box option and there was a conflict, but uppercase maintains compatibility with the ACES 1.1 plugin.
I forgot to add the 00 to the end of the function name. The function itself is a direct translation from the original CTL header, which was probably not intended for use within Resolve in its current form. It’s in the library purely for the sake of inclusion. The exp_factor is what is returning super high values (it’s 36 in the original CTL).
The ACES DCTL set should be used in Resolve YRGB, but the LMTs can be used in Resolve ACES (provided they included a conversion to and from ACEScct). In Resolve YRGB and Resolve ACES you can apply a DCTL as an input transform (pre node graph), within the node graph (clip level, and timeline), and as an output transform (post node graph). Fully modular. In Resolve ACES at the input level, the DCTL is applied before the conversion from ACES to ACEScct (or ACEScc), so an IDT DCTL can be applied here if not natively supported in Resolve.
Thanks to Nick Eason (over at LGG) I was able to precompile the full ACES transform library into a single header file, which can be included in a DCTL in both Metal and CUDA. The ACES_Sample option than was previously only available in CUDA is now available in Metal too. I tried OpenCL, but only the IDTs and some LMTs would work.
In a separate folder called ACES_DCTL_NEW I’ve added 3 files
ACES_LIB.h
ACE.dctl
ACES_COMBO.dctl
ACES_LIB.h contains the full ACES transform library, ACES.dctl has a similar layout to ACES_Sample.dctl from the original ACES_DCTL set, and ACES_COMBO.dctl works in DR16 with the DCTL OFX Plugin.
Yes. The ARRIRAW IDTs should not be used in Resolve, as Resolve never presents the image data in its raw form, even if the source is ARRIRAW. It is already decoded. The value 36 is the multiplier from sensor linear to relative scene exposure at EI800. When that is incorrectly applied to image data which is already had EI gain applied, it will indeed produce ridiculously high values.
I converted the ACES transform library into a Matchbox Shader. It works in Flame, but I haven’t tested it in Baselight or Scratch (or any other app that can run these shaders).
It has a similar UI to the combo box DCTL in Resolve. There are a few options included in the drop down menus, but the entire library is included in the .glsl file so the remaining options can be added as required.
Thanks so much for the efforts you’ve put into this. It took me a while, the first time I came here I did not understand the scope of everything you had done. Now I get it and it’s amazing you’re dedicating the time to the community.
Having an exposure controller for resolve and this alternatives to keying are just amazing.
On aproblem note:I tried installing the Edge Detect on the ofx folder but it won’t show up! And I believe that, specially for HDR grading this is very, very interesting.
What could be causing the issue?
I have a MBP 2018 on macOS 10.14.6.
Using Resolve 16.0.0
It’s a specifically strange behaviour from the ADX10 IDT in the old ACES DCTL set. It works fine in the ACES OFX Plugin and the new ACES DCTL set. I recommend switching to the new set (with the single library file).
Most of the OFX Plugins are CUDA only, which rules out your MacBook (no Nvidia). There may be, in the future, updates to the plugins that add OpenCL or Metal compatibility.
On aproblem note:I tried installing the Edge Detect on the ofx folder but it won’t show up!
No Edge Detect plugin. Perhaps you mean the Convolution plugin (which has an Edge Detect option). The Convolution plugin is perhaps more a showcase tool than a practical one. You’re better off using Resolve’s native OFX Plugin instead.
This thread (and website) is specifically for ACES related inquires, whereas yours seem to be of a more general nature. Perhaps you should try a more appropriate channel instead:
thanks for the answer. That makes total sense.
You are right, I’m referring to the Frequency Separation OFX that was described in the ACES TOOLS video.
But with the context around CUDA you provided, I’ll try and get a different configuration to check it out!
