Frankly I would suggest that you need to look at each time they are used (which isn’t that many times) and make a judgement call os to what the intent of the use is. DCTL includes isinf() and isnan() functions, which will help. Often the reference CTL uses things like clamp_f3( aces, 0., HALF_POS_INF which is essentially just ensuring the value is positive.
I know that diverges from your intent of making the DCTL resemble the CTL as closely as possible, but sometimes you need to diverge. Maybe you could add a comment showing the original CTL.
But currently your code would clamp the image data to 0.0 - 31744.0, which, while it is unlikely to be problematic in the case of most real images, is absolutely not the intent of the CTL. Perhaps @Alexander_Forsythe or @sdyer could comment on the intent.
There has been a persistent problem with the RRT function in the macOS version of the plugin. The same code works fine with DCTL and in the windows version. This update now works (macOS DR16 only)
Been testing the PFE DCTL and found something interesting.
Like most “kodak type” emulations greens are pushed heavily towards the yellows. I noticed some artiefacts/fringing in the yellow to green colors. See attached images.
I modified the LMT (with a node before the DCTL) for contrast and exposure.
I tried smoothing it out with the controls in the DCTL but was unable to get to something “natural”.
Reduce the value of Scale Color1 parameter (it’s 1.4 by default in the LMT PFE OFX DCTL). That should remove the artiefacts/fringing in the yellow to green colors.
Why not use the contrast and exposure controls within the OFX DCTL?
LMT_COLOR_BALANCE_OFX, LMT_HSL_OFX, and LMT_HUE_VS_LUMA_OFX emulate some of the controls familiar to users of Photoshop and Camera Raw. They can be used separately, or in conjunction with other LMTs (including LMT PFE)
this is probably just a minor thing, but I can’t seem to figure it out. I am trying to call an external LUT from a basic DCTL but it’s doesn’t work. If I apply the DCTL via the OFX Plugin nothing happens, and when I load the DCTL into a Node without the plugin I get the “Error Processing Davinci CTL” - error. This also happens when I use the example DCTL “LUTApply.dctl” from the “…/Developer/DaVinciCTL/” Folder. I have tried to reference various Lut’s in .cube format, with absolut or relative path. I have also tried Resolve 15.3 and Resolve 16b1 on OSX.
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!!!