Adding IDTs to Resolve

As of Resolve 12.5, it is now possible (Studio version only) to create DCTL (DaVinci Colour Transform Language) files which are mathematically expressed transforms, similar to GPU fragment shaders. These can be used like LUTs, but with higher precision and without the range limitations inherent in LUTs. One use for these is to implement a custom ACES IDT, for example when a new camera is released, or a manufacturer adds a new recording colour space to an existing camera, but Resolve has not yet been updated to include it as an IDT.

DCTL is relatively similar to the CTL used by the IDTs in the ACES repository. This means that it is not too difficult to convert a CTL file to a DCTL one, to add a new IDT to Resolve. You do however need to bear a few things in mind.

Published IDTs convert from the camera colour space to linear ACES. Neither of the ACES options in Resolve are linear. ACEScc follows the Academy’s spec, and DaVinci ACES has AP1 primaries (like ACEScc) and a gamma of 2.6. This means that when you select an IDT of “None” in Resolve, a transform is still applied to convert to ACEScc or DaVinci ACES from the supposed linear ACES of the source image. When writing a custom IDT you need to add code at the start to remove the curve of the particular Resolve working colour space, and to apply an AP1 to AP0 matrix. You then need to add code at the end to return the image to the working colour space. This also means two versions of the DCTL file are needed, one for DaVinci ACES and one for ACEScc.

This may all sound very complex, but for anybody familiar with basic scripting it does not take too long to get your head around! I have an example custom IDT which I will send out at no charge if people email me on nick[at]antlerpost[dot]com.

The example is taken from the idt-alexav3-logC-EI800.ctl file in the ACES repository. The built in IDT in Resolve (last time I checked) used the EI1000 version. While the difference is extremely subtle, I created it in order to exactly match results in Resolve with those in other ACES implementations. Even if Blackmagic design change the behaviour of Resolve to use the EI800 version by default, I hope my example will still prove useful for people wanting to create their own IDTs.

While it might also be possible to create custom ODTs using DCTL, because the RRT and ODT use numerous CTL library functions, it would be necessary to convert all those to DCTL as well. I plan to experiment with doing this, but have not yet done so. Currently custom ODTs I have created for Resolve use a combination of mathematical transforms and 3D LUTs. If you are careful when creating the LUTs, and implement only the part which is absolutely necessary as a cube, good results can be obtained. Indeed, I believe OCIO uses this same approach to good effect.

6 Likes

A couple of quick updates to my previous comment.

  1. It appears that the latest release of Resolve has been updated to use the correct IDT version, as opposed to being fixed at the EI1000 version. So my custom IDT is no longer required. However it is still a useful example of converting CTL to DCTL.

  2. I have discovered that in Resolve input LUTs are applied before the conversion to the working colour space. This means that my description above of converting to and from DaVinci ACES or ACEScc in the DCTL file is not necessary if applied as an input LUT. This makes converting CTL to DCTL even simpler. It is just minor syntax changes. If people request the DCTL file, I will send two versions, one which includes conversions to and from DaVinci ACES, to be used within the node tree, and one for use as an input LUT.

1 Like

Some recent testing I have been doing has indicated that the Sony SLog3 IDT in Resolve is specifically S-Log3/S-Gamut3, not the more commonly used S-Gamut3.Cine. I have reported this to the Resolve team, but some people may need a stop-gap.

For those who can write their own DCTL, you can create an S-Log3/S-Gamut3.Cine IDT relatively easily. But for those who can’t, I have created one which I am selling for only $30. Contact me by email – nick [at] antlerpost [dot] com.

I have not tested with a wide variety of footage, but have found that it also works on F65 RAW footage shot with the camera set to S-Log3/S-Gamut3.Cine, where Resolve’s built in Sony RAW IDT does not match the result from other implementations.

Hi Nick,
thanks for your explanations. That helped a lot already.
If I understand right, then Resolve (when the DCTL is used as a input LUT) is expecting linear AP0 data. From there Resolve is doing the Davinci ACES and ACEScc under the hood, right?
We are currently trying to add an linear/sRGB IDT to Resolve. We wrote a color matrix which should convert from sRGB to ACES primaries (AP0) and for the most part it works well. But with extreme saturation values there is something weird going on. It does not really clip the values, but it is kind of reversing it. At least the vectorscope looks folded somehow.
Do you know what is going on there?

Thanks,
Sönke

Yes, you are correct that when you set ACES Input Transform: None in Resolve it expects the image data be linear with AP0 primaries. So a DCTL applied as an input LUT acts on the unmodified pixel values, and should output linear AP0. Resolve then transforms to the working space – ACEScc, ACEScct or DaVinci ACES.

If colours are so saturated that one or more channels has negative values, that can sometimes cause unexpected behaviour with a 3x3 matrix. However, I wouldn’t expect that with an sRGB to AP0 matrix, as all the coefficients of the matrix are positive, since the sRGB gamut is entirely contained within the AP0 gamut.

Are the issues you are seeing with extremely saturated values in your original sRGB file, or when increasing saturation dramatically in Resolve?

Thanks for your answer Nick.
What I did to test the created DCTL: I took the ACES reference image “SonyF35.StillLife” in ACES2065, converted it in Nuke to Linear - sRGB and exported it as an EXR. As a double check I re-imported the EXR back in to Nuke and set the read node to Linear - sRGB. Compared to the original still in ACES2065 it is a 99.99% match.
Vectorscope of the resulting image:


When I import the Linear - sRGB frame in Resolve and apply the DCTL - I get the following vectorscope:

Any ideas?
Thanks,
Sönke

That is the ACES values which produce negative values in sRGB. Resolve appears to be clamping negative values in the sRGB EXR. You can replicate this in Nuke. Bring in the original ACES EXR, and your converted sRGB EXR. If you apply an sRGB to AP0 matrix to the sRGB image, the two will match (you are, after all, just inverting what you did to create it.) Now add a clamp in Nuke before the matrix (set the maximum to 200 or something, to ensure only negatives are clamped, not >1) and you will see the same thing you see in Resolve

Thanks! Just tried the procedure you described in Nuke and you are absolutely right.
So it is Resolve again…
That might be the reason Resolve is not providing any “Utility” conversions for ACES.
The only way around this would be to do the ACES conversion prior importing in Resolve.

@nick… Just following up on this SLOG3 issue. I was wondering if Resolve had fixed this. I’m still using your DCTL for the S.Gamut.cine idt. Thanks!

You’ll have to tell me! Compare my DCTL with the built in IDT in Resolve 14 and see if they now match.

Once I update a machine here with a recent OS, so I can run Resolve 14, I will test.

I’ll check! But shouldn’t we have the option of 2 IDTs in Resolve? Or could the IDT detect the correct gamut? (might be a stupid question)

I don’t think they changed that. I use Nick’s DCTL as SLog3/SGamut3.cine IDT.

Like you said: There should be 2 IDTs to choose. No automatic detection unfortunately. Although it would be possible. All information is in the XAVC-Files. Even the ISO which Resolve also ignores. When opening Sony XAVC with SLog3 material in Sony RAW Viewer everything can be read from the Metadata… So we can only hope Resolve will implement that.

Peter

There should be manual selection in any case. Externally recorded ProRes, or DPX from VFX, for example, may not have metadata.

You’re absolutely right.

But VFX should come in as ACES2065-1 anyways :slight_smile:

Peter

So I confirm! There are 2 IDTs in Resolve 14. And, I compared with @nick 's IDT there are pretty much identical. BMDs IDT seems a bit “brighter” at first sight.

Also, can confirm the BMD included a PFE 2383 LMT in the software (That I had aflasy assumed to have come from the @ACES_Leadership . But it doesn’t work properly even when converted to LInear (2065-1 and CG).

I’ll get in touch with BMD about that.

Cheers

Where are you applying the CLF LMT? You must apply it via the clip contextual menu (similar to IDTs). Otherwise, it won’t work properly.

Even then, however, it will still exhibit artifacts w/ “digital” colors that uncommonly occur in a film system (neg+print). In my experience this is common with PFEs for things like neon lights and bright objects that don’t “roll off” so nicely in digital as they do in film. For example, look at the neons in the frame below…

Although looking at the LUT3D in there, it would appear to be a mathematically modelled PFE. It seems too perfect to come from real scanned film.

It’s just that simple colors (like a green turtle kids swimming pool) tend to get “out of line” and create some funky noise.

Thanks!

Hello guys, I’m new to ACES and IDTs, and I thought I recreate the S-Log3/S-Gamut3.Cine IDT for learning purposes. SLog3_to_linear is pretty straight forward, the math is included in Sony’s technical summary. But I can’t for the life of me figure out how the S-Gamut3.Cine to AP0 matrix is built.

This is what I use for SGamut3.Cine to XYZ conversion:
0.599083921 0.248925516 0.10244649
0.21507582 0.885068502 -0.100144322
-0.03206585 -0.027658391 1.148781991

This is what I use for XYZ to AP0 conversion:
1.0498110175 0.0000000000 -0.0000974845
-0.4959030231 1.3733130458 0.0982400361
0.0000000000 0.0000000000 0.9912520182

When I multiply the second by the first, I get this matrix:
0.628928026 0.261327446 0.107437466
-0.004871248 1.089316043 -0.075476644
-0.031785338 -0.027416436 1.138732467

But according to IDT_Sony_SLog3_SGamut3Cine.h it should be this:
0.638788667 0.272351434 0.088859899
-0.003915906 1.088073231 -0.084157325
-0.029907202 -0.02643258 1.056339782

Can you really rebuild an IDT by the information provided in Log data sheets (log to linear formula, color primaries)? What am I missing?

Your concatenated matrix is correct for an absolute colorimetric conversion to ACES. But the IDT needs to include a chromatic adaptation from D65 to D60. I believe Sony use the Bradford matrix.

Correction: I just checked, and CAT02 chromatic adaptation produces a matrix which matches the one Sony give.

1 Like