DaVinci Resolve: Issues regarding InvODT.Academy.P3DCI_D65sim_48nits.a1.1

Issues regarding InvODT.Academy.P3DCI_D65sim_48nits.a1.1 in DaVinci Resolve

Stockholm based company Filmlance wants to be able to:

initially perform an HDR-TV grade, via ODT.Academy.Rec2020_1000nits_15nits_ST2084.a1.1, in front of a monitor with the calibrated white point 0.3127 x and 0.329 y (6 500 Kelvin);

subsequently perform a D-Cinema grade, via ODT.Academy.P3DCI_D65sim_48nits.a1.1, in front of a Christie Projector with a calibrated white point according to SMPTE RP 431-2 and SMPTE ST 431-1, i.e. 0.314 x and 0.351 y (near 6 300 Kelvin);

finally perform the D-Cinema mastering via ODT.Academy.DCDM_P3D65limited.a1.1.

Please, try to answer the following two questions!

• Should Filmlance trust DaVinci Resolve’s “ACES Output Device Transform” named “P3-DCI (D65 sim.)” although red (unexpectedly) is offset as high as blue?

• Why does not DaVinci Resolve’s “ACES Input Transform” also named “P3-DCI (D65 sim.)” perform a perfect inverse? Note: The inverse “P3-DCI (D60 sim.)” seems to work, but not the inverse “P3-DCI (D65 sim.)".

The test to be replicated, please:

• Use a shot with a Grey Card, 18% reflectance, e.g. ARRI’s frame “Isabella.112782.ari” downloadable at https://www.arri.com/resource/blob/67438/a87188ffbb425d3f42d013793f767b93/2018-acesreferenceimages-data.zip

• Use Projects Settings / Color Management / Color Science: ACEScct; ACES version: ACES 1.1; ACES Input Device Transform: Alexa; ACES Output Device Transform: No Output Transform (i.e. ACES 2065-1 AP0 straight out).

• Use a Window Node to lower the gain towards black regarding everything else in the frame than the Grey Card area.

• Use the Primary Offset Node to balance Red and Blue to the Histogram position of Green:

• Change “ACES Output Device Transform” from “No Output Transform” to “P3-DCI (D60 sim.)”! The below behaviour is hopefully correct as the red channel has become higher than blue and green to compensate for the greener DCI white (as described in the code at https://github.com/ampas/aces-dev/blob/master/transforms/ctl/odt/p3/ODT.Academy.P3DCI_D60sim_48nits.ctl):

• Deliver a video. Import that video and, to that specific Clip, enable “ACES Input Transform” “P3-DCI (D60 sim.)”, i.e. the inverse! Put the Project Setting “ACES Output Device Transform” into “No Output Transform” and one seems successfully back. DaVinci Resolve’s Inverse-version regarding D60 simulation seems to work:

Now the same test regarding D65 simulation, that is critical to Filmlance:

• Change “ACES Output Device Transform” from “No Output Transform” to “P3-DCI (D65 sim.)”! The below behaviour is hopefully correct as the blue channel has become higher than red and green to compensate for the greener DCI white (as described in the code at https://github.com/ampas/aces-dev/blob/master/transforms/ctl/odt/p3/ODT.Academy.P3DCI_D65sim_48nits.ctl). However, the red channel is unexpectedly offset, nearly as high as the expected blue – is that correct?

• Deliver a video. Import that video and, to that specific Clip, enable “ACES Input Transform” “P3-DCI (D65 sim.)”, i.e. the inverse! Put the Project Setting “ACES Output Device Transform” into “No Output Transform” and one has an unexpected problem. DaVinci Resolve’s Inverse-version regarding D65 simulation seems to be wrong:

Thanks for all your help, in advance!

Kind Regards,

Lars HAGLUND
Filmlance International
Stockholm, January 20, 2020

1 Like

Hi Lars

Welcome! Thanks for your first post.

Steve
ACESCentral Admin

Good catch Lars. That would appear not to be an error with the Resolve implementation, but with the original CTL for the inverse ODT.

https://github.com/ampas/aces-dev/blob/master/transforms/ctl/odt/p3/InvODT.Academy.P3DCI_D65sim_48nits.ctl seems to be missing the inverse of the D60 to D65 CAT matrix.

You should raise an issue on the AMPAS GitHub.

Oh, one other thing. I see no reason to doubt Resolve’s implementation of the forward transform. It appears to match the result of the CTL. The red, as well as the blue being raised is correct.

I have created an issue on Github, and a pull request for a fix.

Thank you Nick Shaw and Scott Dyer,

It feels really good to hear that the critical ODT truly is correct - and that the, in practice seldom used Inverse-ODT, will be edited and merged in as a bug fix in the 1.2 release.

Kindly,
Lars HAGLUND
Filmlance International
Stockholm January 24, 2020