ACES 2.0 OT Candidate Testing - Package Preperation

Right now we have feedback and discussion about the ACES 2.0 OT Candidate testing spread over a few different threads.

I thought it might make sense to make a seperate thread that focuses specfically on the testing package itself, and related issues.

As things stand currently, I’ve got a WIP testing repo here:

(This is temporary, and will be migrated to a more offical home at some point)

It contains a nukescript with 3 test candidates, and 3 sets of LUTs exported from that targeting:

  • Resolve
  • Baselight
  • OCIO

There are 3 candidate transforms, referred to as A, B and C.

Candidate A

This represents a minimal departure from the existing ACES 1.2 transforms.
Some minor colour tweaks collectively known as the RRT Sweeteners have been removed.
The c9 (SDR) and SSTS (HDR) tonescales have both been replaced with the Michaelis-Menten Spring Dual-Contrast (MMSDC) curve, still applied as a per channel RGB lookup in the AP1 rendering space. Mapping down to the final display gamut is a simple matrix, as used in the existing ACES Display Transforms.

Candidate B

Is @jedsmith’s OpenDRT version 0.1.2 from GitHub - jedypod/open-display-transform: Open Display Transform is a collection of tools and experiments for rendering wide-gamut scene-linear data into an image for an SDR or HDR display device.

Candidate C

Is the ZCAM DRT, developed by @matthias.scharfenber and myself. For all the gory details, see the thread

Issues for discussion

Selection of Candidate A

There seems to be some growing momentem from @ChrisBrejon, @sdyer and others to swap out Candidate A from the warmed over ACES 1.2 transform, which uses AP1 as it’s rendering space, to something else with an improved set of rendering primaries. Potentially @jedsmith’s rgbDT could be a drop in replacement here, or something else. Hopefully we can hash out a plan here pretty quickly

Input shaper issues with Candidates B & C

@meleshkevich noticed he wasn’t able to hit the corners with either OpenDRT or ZCAM DRT with the LUTs provided in the WIP testing repo.

This bascially comes down to the shaper space I’ve used to prepare the data for the baked 3D LUTs (ACEScct curve, with AP0 primaries) not covering all the values needed to hit the extreme corners of the target display (taking into account highlight desat, and target gamut compression).

There are two potential ways we could look at solving this.

  • Replacing the ACEScct curve with another 1D curve that captures a much larger range of negative values in APO or AP1
  • Coming up with a new set of shaper primaries that place all needed input values in the positive range before hitting the 1D shaper.

Currently I’m experimenting with different sets of primaries. The plots below show an input cube run through the inverse of the P3 D65 SDR versions of each transform. With a made up set of primaries plotted out that seem like a decent minium fit. Ideally I’d like the same set of primaries for both, but as you can see, they both land their inverted values in different areas.

Based on various discussions in the meetings, I’m not worrying about inverting values from a Rec2020 display, or HDR displays, as hitting the extreme corners of those seems (for now) to be less essential.

I’m curious what other people’s thoughts are about this. Even if it’s not ideal, it feels like whatever transform we go with, it needs to be implementable as a 3D LUT in a reasonable way.

P3 D65 SDR Display values throught the inverse ZCAM DRT

P3 D65 SDR Display values throught the inverse OpenDRT

There is perhaps a related dicussion here about how realistic it is to expect DCC applications to actually allow you to land values out in these extreme positions. Whilst the transforms both allow you to reach the extreme corners of the display gamut in theory, that might not be possible in most real world scenarios.


What about PQ with a different scale than 10000? It doesn’t allocate as many code values to darks as AcesCc but that might be an advantage w.r.t. hitting yellows.

Here’s Jed’s huesweep node raised +5 exposure stops, viewed through the Nuke procedural for candidate C rev007,

Then through the OCIO rev007

Pretty much looking identical.

Compared to the Nuke procedural for candidate C rev008,

and the OCIO rev008

where it appears the OCIO is not quite able to reach those sharp corners of the procedural.

1 Like

I’ve made an update to the SDR/HDR comparison page, which now includes the new B transform.


I’m looking forward to checking these out in Resolve! Has anyone been able to successfully invoke the provided DCTLs via either an ACES Transform or project-level color management? No such luck here with Resolve 17.4.5 despite carefully following the readme and double-checking for any additional info in the Resolve DCTL Developer documentation.

Just tried with the Rec709 flavors via the ACES transform node and they seem to work fine.
Make sure to put them in your user’s Library/Application Support/etc… folder not the system’s one.
I put the DCTLs and the LUT cubes to
~/Library/Application Support/Blackmagic Design/DaVinci Resolve/ACES Transforms/ODT

1 Like

Thanks Andy – it was indeed a users vs system path thing :man_facepalming: