ACES 2.0 DCTL in Resolve 20.1

Very pleased to see that Resolve 20.1 has added support for DCTL parametric ACES 2.0 Output Transforms. Congratulations to @rohitg and the rest of the Resolve team.

So now, for example, if you want a 600 nit P3-D65 transform, instead of the stock 500 nit one, you can just use:

DEFINE_ACES_V2_PARAM(PEAK_LUMINANCE: 600.0,
                     LINEAR_SCALE_FACTOR: 1.0,
                     LIMITING_PRI: { 0.68000, 0.32000, 0.26500, 0.69000, 0.15000, 0.06000, 0.31270, 0.32900 },
                     ENCODING_PRI: { 0.68000, 0.32000, 0.26500, 0.69000, 0.15000, 0.06000, 0.31270, 0.32900 },
                     EOTF: 0,
                     IS_SCALE_WHITE: 0,
                     OUTPUT_COLORSPACE_TAG: P3D65_1000nits_15nits_ST2084)

__DEVICE__ float3 transform(int p_Width, int p_Height, int p_X, int p_Y, float p_R, float p_G, float p_B)
{
    const float3 result = AcesOutputTransform(p_R, p_G, p_B);
    return result;
}

Note that the list of colourspace tags has not changed, so you are limited to the list from ACES 1.3. So in the example above it is tagged as being 1000 nits, because there is no tag for 600 nits. This will still display correctly on an XDR display.

Perhaps in future Resolve could infer the appropriate tag from the parameters.

4 Likes

Does the nit level of the color space tag even does something? If it triggers Resolve’s internal clamping which already happens in too many places then I would support adding unclamped color space tags to get rid of it. This behind-the-scene clamping after every node at timeline level has been my bane with Resolve since I prefer to have all display clamping done intentionally in the output transform a single time so all out-of-bounds intermediate values are preserved. As a workaround, I either use DaVinci YRGB or Davinci YRGB RCM in custom mode with a 10000 nits timeline (if I need the color-space aware tools).

I’m not sure. I wondered if it might set the MaxCLL metadata, but I haven’t checked.