ACES 2.0 DCTL in Resolve 20.1

Discussions - ACESNext VWG – Output Transforms
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.

6 Likes
2

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).

3

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

4

Awesome! Is there any documentation on how to use this? How do I make a transform? I would specifically want a p3/bt.1996 ODT (100nit) for regrading cine stuff on an oled under dim (not dark) conditions.

5

Documentation is in the Resolve Developer README. On a Mac the path is /Library/Application Support/Blackmagic Design/DaVinci Resolve/Developer/DaVinciCTL/README.txt

Also, there has been some discussion of custom ODTs in Resolve for a particular use case (P3 BT.1886) on the #aces channel of the ASWF Slack, but wanted to highlight a few findings here.

In testing, there are some questions about the EOTF enums described in the README. A few notes:

  • users porting parameter values from the CTL should note that the enum values the DCTL expects are not a 1-to-1 mapping to the enum values used in the CTL. Here are the options as documented for DCTL 
    • The EOTF fields correspond to the following Academy standard EOTF transforms:

    - 0: ST-2084 (PQ)
    - 1: BT.1886 (Rec.709/2020 settings)
    - 2: sRGB (mon_curve w/ presets)
    - 3: Gamma 2.6
    - 4: Linear (no EOTF)
    - 5: HLG
    - 6: BT.1886 with Gamma 2.4
    - 7: Gamma 2.2
  • the differences between a few of these enums are unclear - for example: Option 1 and 6 seem like they should be the same. Why are they listed twice?
  • Option 6 and 7 do not produce the expected result. (These bugs have been reported to Resolve)

[TODO] Once all this is sorted, pull the relevant info into the docs for guidance.

1 Like