Resolve 17 - ACES DCTL - Not quite there

Looking at the struct definition of the ACES Transform under the DCTL implementation:

(there's a typo btw... missing the INVERSE_EOTF definition)

typedef struct AcesTransformUserSettingParams
{
float yMin; // Black luminance (cd/m^2)
float yMid; // Mid-point luminance (cd/m^2)
float yMax; // Peak white luminance (cd/m^2)
float displayPri[8]; // Display primaries
float limitingPri[8]; // Limiting primaries
int eotf; // Display device EOTF
int surround; // Viewing environment
int stretchBlack; // Stretch black luminance to a PQ code value of 0
int d60Sim; // Is user D60 adapted
int legalRange; // Output to legal range
int skipRRT; // Skip the standard ACES RRT transform
} AcesTransformUserSettingParams;

This structure seems very rigid and appears designed more for Display referred transforms rather than Scene referred ones.

For example, why would I need to set yMin, yMid & yMax when all I am looking to do for an IDT is an inverse OETF of a camera's mapped scene values?

First I thought it might be a boolean to signal whether it is a device EOTF that needs preceeding RRT and thus operates on OCES values but I think you are right, there is a missing line in struct definition.

These luminance values are maybe used by Resolves colorspace aware tools somehow..? Not sure they are actually part of ACES transforms.

These are the actual descriptions:

Code: Select all

An appropriate ACES transform requires all of the following fields to be defined:
- Y_MIN: black luminance (cd/m^2), value must be float.
- Y_MID: mid-point luminance (cd/m^2), value must be float.
- Y_MAX: peak white luminance (cd/m^2), value must be float.
- DISPLAY_PRI: Display primaries, value must be an array of 8 floats wrapped inside a pair of curly bracket "{}".
- LIMITING_PRI: Limiting primaries, value must be an array of 8 floats wrapped inside a pair of curly bracket "{}".
- EOTF: Display device EOTF, value must be an integer value in range [0-5] corresponding to 5 ACES's defined EOTF, or a custom EOTF function name defined by user.
- INVERSE_EOTF: Input device EOTF, value must be an integer value in range [0-5] corresponding to 5 ACES's defined EOTF, or a custom inverse EOTF function name defined by user.
- SURROUND: Viewing environment, value must be an integer value of 0 or 1 to represent boolean flag.
- STRETCH_BLACK: Stretch black luminance to a PQ code value of 0, value must be an integer value of 0 or 1 to represent boolean flag.
- D60_SIM: Is user D60 adapted, value must be an integer value of 0 or 1 to represent boolean flag.
- LEGAL_RANGE: Output to legal range, value must be an integer value of 0 or 1 to represent boolean flag.

Looks like in the latest Beta 2 version the "ACES Transforms" reference Documentation has disappeared.

In case anyone else is wondering,

The Documentation is NOT available on the Windows version in the Developer section.

I found it on the Linux instance.

There's actually a new forum for version 17 that we're supposed to use.

17_Forum.png (67.51 KiB) Viewed 3033 times

Don't you ever tire from the incessant copy/pasting?

Seriously if you can't add any value to the discussion, please stop.

This thread was actually posted in the Developer section where it should have remained and not moved to the Resolve section.

Don't you ever tire from the incessant copy/pasting?

Not much else to do these days.

Asim, do you see a discrepancy in how ACES is implemented in resolve and how it "should" implemented?

The only discrepancy I would find in Resolve 15/16/17 at the moment is that the ACES implementation in RCM has a D65 white point, not a ~D60 white point as per ACES specs.

But this is something that's been there for a while and most users probably aren't aware of it or even notice for that matter. The other issues are more usability quirks (i.e. Color Checker behavior, lack of RRT in RCM etc.)

With that said, the reason for this thread is that the "ACES DCTL" feature introduced in Resolve 17 seems half baked to be brutally honest. The implementation appears to be heavily focused on ODTs rather than IDTs and the documentation around practical implementation is still very sparse.

I tried developing some IDTs using the specs and after a while just.gave.up. It seems to require hacks to get something usable for IDTs... like Apollo 13 duct-tape level.

The only discrepancy I would find in Resolve 15/16/17 at the moment is that the ACES implementation in RCM has a D65 white point, not a ~D60 white point as per ACES specs.

But this is something that's been there for a while and most users probably aren't aware of it or even notice for that matter. The other issues are more usability quirks (i.e. Color Checker behavior, lack of RRT in RCM etc.)

With that said, the reason for this thread is that the "ACES DCTL" feature introduced in Resolve 17 seems half baked to be brutally honest. The implementation appears to be heavily focused on ODTs rather than IDTs and the documentation around practical implementation is still very sparse.

I tried developing some IDTs using the specs and after a while just.gave.up. It seems to require hacks to get something usable for IDTs... like Apollo 13 duct-tape level.

for IDT, when we do need them, we leve the IDT in resolve"as is" (ACES space), so resolve does not do anything to the file and do the DCTL as we like form teh whatever color space to that ACES space.

BUT, I have someone else program that for me, i'm a donkey...

Yep. I just do a "No Input Color Space" and select the DCTL, but the new ACES DCTL feature in Resolve 17 is/was meant to make that whole process a lot easier by allowing that custom IDT/ODT directly inside the ACES workflow. The feature is nearly there... but still needs some work to make it usable.

The only discrepancy I would find in Resolve 15/16/17 at the moment is that the ACES implementation in RCM has a D65 white point, not a ~D60 white point as per ACES specs

Do you mean in the context of ODT-s? Because for example all exports I have received from Resolve as exr-s seem to match ACES OCIO config results.

I'm referring to the ACES Linear or ACEScc / ACEScct timeline setting in RCM. I haven't tested an export with ACEScg or ACESCC(t) ODT as yet.

The issue is only with RCM, not with the ACEScc/ACEScct Color Science modes

...
What’s new in DaVinci Resolve 17 Beta 8
...
Support for non-parametric DaVinci CTL IDT and ODT formats.
...

Thanks for listening

The ACES DCTL feature set is almost there


It would be great if the Custom IDT selection is also visible under "ACES Input Transform" at the individual clip level. Currently the only place the custom IDT can be selected is either in the Project Settings or the ACES Transform ResolveFX plugin.

...
What’s new in DaVinci Resolve 17 Beta 8
...
Support for non-parametric DaVinci CTL IDT and ODT formats.
...

Thanks for listening

The ACES DCTL feature set is almost there


It would be great if the Custom IDT selection is also visible under "ACES Input Transform" at the individual clip level. Currently the only place the custom IDT can be selected is either in the Project Settings or the ACES Transform ResolveFX plugin.

Sorry for the necro, how it works exactly, because I couldn’t not find in teh manual.

Are you talking about using a Custom IDT? It's very similar to how you would with other IDTs...

ACES DCTL IDT.jpg (73.04 KiB) Viewed 2061 times

If you're referring to installing these IDTs or an example of a custom IDT, have a look at my GoPro Protune IDTs on Github:

https://github.com/xtremestuff/protune-transforms/

Thanks, actually we have a custom ODT/RRT to install…..

That would go under the equivalent ODT folder...

Windows: %APPDATA%\Blackmagic Design\DaVinci Resolve\Support\ACES Transforms\ODT\
Mac: ~/Library/Application Support/Blackmagic Design/DaVinci Resolve/ACES Transforms/ODT/
Linux: ~/.local/share/DaVinciResolve/ACES Transforms/ODT/


I'm not sure why it was decided to have these at the individual user profile level instead of being configured at the global level.

If you're looking for Documentation, it's where the rest of the Developer documentation is... but you won't find the relevant .md file in the Windows instance. For that, you need to look at the Linux or MacOS instances.

Edit: Looks like the md file is gone with the more recent versions of Resolve. Everything seems to be incorporated into the DCTL README file now - even on Windows.

That would go under the equivalent ODT folder...

Windows: %APPDATA%\Blackmagic Design\DaVinci Resolve\Support\ACES Transforms\ODT\
Mac: ~/Library/Application Support/Blackmagic Design/DaVinci Resolve/ACES Transforms/ODT/
Linux: ~/.local/share/DaVinciResolve/ACES Transforms/ODT/


I'm not sure why it was decided to have these at the individual user profile level instead of being configured at the global level.

If you're looking for Documentation, it's where the rest of the Developer documentation is... but you won't find the relevant .md file in the Windows instance. For that, you need to look at the Linux or MacOS instances.

Edit: Looks like the md file is gone with the more recent versions of Resolve. Everything seems to be incorporated into the DCTL README file now - even on Windows.

Thanks, appreciated.
I will pass along the info.