Page 1 of 1

Discrepancies using a “pseudo” ACES workflow with OFX

PostPosted: Wed Jan 16, 2019 9:48 pm
by Theo Ribeiro
This post is a mirror of a post I created on the ACES forum but may find some interest or insights here?

The latest versions of Davinci Resolve (from 15.2.2 but maybe since v15?) allow for creating a very powerful “pseudo” ACES workflow using DaVinci’s new ACES Transform OFX plugins. It also allows for using tools designed to work in Davinci YRGB colour Science inside a full fledged ACES workflow within DaVinci.

The scope of this post is not to dive deep into all the possibilities of both scenarios but to explore what I found to be a slight discrepancy on the rendering that DaVinci applies to an Alexa LogC image when you create a pseudo-ACES workflow using ACES Transform nodes (in YRGB colour science) as opposed to setting your Colour Science to ACES (ACEScct in my case) on the colour management preferences.

The pseudo ACES workflow was briefly described in a previous post:
https://acescentral.com/t/luts-that-emulate-the-aces-workflow/1334/11?u=theoribeiro

I’m no colour scientist, rather a curious cinematographer who is very interested in colour so forgive me if my tests are very empirical and the results not exactly conclusive.

I created three testing scenarios to see if the results were the same when processing both a 16bit Linear Grey Ramp and the classic ARRI Isabella.dpx test image.

Scenario 1 consisted of Setting Resolve’s Colour Science to ACES on the colour management preferences.
Scenario 2 used a “pseudo” ACES workflow using ACES Transform OFX plugins in two nodes.
Scenario 3 used Lattice in conjunction with Resolve to create a 128^ sized CUBE LUT in Lattice that concatenates 5 corresponding ACES CTLs and then processing the files using the generated LUT in DaVinci Resolve (I tried processing the DPX files in Lattice but the results were very poor).

I analysed the images layered on top of each other on a timeline using the “Difference” blending mode (and looking at a waveform of the result) and I also plotted a waveform that reveals the contrast curve applied by the 3 different methods from the linear grey ramp imeges.

The results showed that Scenarios 1 and 3 produced virtually identical results with minor difference that I’m chosing to attribute to Resolve’s LUT rounding issues as it’s not using mathematical transforms but a LUT instead.

Scenario 2 was different from the other two and the main difference occurred on the mid to top end of the contrast curve. I don’t have a proper way of judging volumetric colour differences but they look perceptually the same so:

Curve Red.jpg
This image Shows the two curves layered on top of each other. The Curve in red represents Scenario 3 and the curve in white Scenario 1 notice the difference on the upper part of the contrast curve.
Curve Red.jpg (147.47 KiB) Viewed 284 times


Also, if I layer the grey scale images on top of each other but change the overlay mode to multiply, it reveals the part of the curve that is really different:
Multiply_2.2.1.jpg
Multiply_2.2.1.jpg (54.98 KiB) Viewed 284 times


The difference that exists is barely perceptible in real world images and thus I hadn’t noticed it before when testing the “pseudo” Workflow but with these tests I now realised it’s there and it’s really bugging me.

This testing only proves that there is a difference in DaVinci’s processing when using the specific ACES version, IDT and ODT combinations I didn’t test any others so I won’t assume anything.

If anyone has any insights I’d love to hear them. I’l probably post this on Blackmagic’s forum and Lift Gamma Gain to try and find some more insight :slight_smile:

Scenario 1: Setting Resolve’s Colour Science to ACES on the colour management preferences using:
    Colour Science: ACEScct
    ACES Version: ACES 1.1
    ACES IDT: Alexa
    ACES ODT: Rec.709
    Preset Node LUTs in: ACEScc AP1 Timeline Space
    No other nodes or colour corrections applied

Scenario 2 uses a “pseudo” ACES workflow using ACES Transform OFX plugins o two nodes:
    Colour Science: DaVinci YRGB
    Timeline Colour Space: Rec.709 Gamma 2.4
    Node one ACES Transform OFX plugin is set to:
      ACES Version: ACES 1.1
      Input Transform: Alexa
      Output Transform: ACEScct
    Node two ACES Transform OFX plugin is set to:
      ACES Version: ACES 1.1
      Input Transform: ACEScct
      Output Transform: Rec.709
    No other nodes or colour corrections applied

Scenario 3 is creating a 128sized CUBE LUT in Lattice that concatenates 5 ACES CTLs and then processing the files using that LUT in DaVinci Resolve.

    Lattice CTL Sequence in ACES 1.1 is:
      IDT.ARRI.Alexa-v3-logC-EI800.ctl
      ACEScsc.ACES_to_ACEScct.ctl
      ACEScsc.ACEScct_to_ACES.ctl
      RRT.ctl
      ODT.Academy.Rec709_100nits_dim.ctl
    Resolve Settings are:
      Colour Science: DaVinci YRGB
      Timeline Colour Space: Rec.709 Gamma 2.4
      3d Lookup Table Interpolation: Tetrahedral

Original DPX test files and result DPX files on the link below for anyone interested:
https://www.dropbox.com/sh/lew0qvrykw7w29o/AABaqFhdaVsJtE6dttJRPHHWa?dl=0

Re: Discrepancies using a “pseudo” ACES workflow with OFX

PostPosted: Fri Jan 18, 2019 12:22 pm
by Theo Ribeiro
A bit of an update on this for anyone interested:

Nick Shaw back at the ACES Central forum suggested that DaVinci Resolve could be choosing a different Alexa IDT when using the OFX plugin as opposed to the one ACES on the colour management system was using.

The issue is that there are several variants of the Alexa IDT (more than any other camera I think) and since neither the plugin nor the colour management system lets you choose which specific IDT to use, we really don't know which one they are using since they are all under the "Alexa" blanket.

I did the same batch of tests but this time trying to find some more unambiguous IDTs.

I ended up testing both IDT.Sony.SLog3_SGamut3Cine and the Blackmagic Design Film IDT and with them, indeed there is no difference whatsoever in the results.

It seems then that the OFX plugin is choosing a different IDT for the Alexa then the colour management system.

I’ll try and find out which but at least it really seems to be only an IDT choice issue and not anything else in the chain of operations.

It also means that apart from the odd automatic IDT variant choice, the “pseudo” ACES workflow is rock solid in terms of it’s transforms which is a comfort.

Re: Discrepancies using a “pseudo” ACES workflow with OFX

PostPosted: Fri Jan 18, 2019 5:20 pm
by deezid
Thanks for the test.
Came to the same conclusion when I got excited after Resolve 15.2 was released with the new ACES plugin. There's an ever so slight difference. Glad it's only the IDT which is different.

Will definitely make use of this workflow in some projects. (Maybe try to convert to ACEScg at the end and export as EXR and compare to the "real" ACES workflow)