Note: This article was published in November 2016 and made publicly available to support the launch of AcesCentral.com
Updated November 2016 to clarify Resolve 12.5.3 use of ACES 1.02 vs 1.03 versions
ACES 1.03, ACEScct & DaVinci Resolve 12.5.3
Ok, I lied! In Part 3 of this series I mentioned I was concluding our Getting To Know ACES series, but a recent development has pulled me back in!
With the release of DaVinci Resolve 12.5.3 was an announcement that should be very interesting to anyone following this series – new ACES enhancements and workflows.
Resolve 12.5.3 introduced support for ACES 1.02 (really, ACES 1.03, but we’ll talk more about that in a moment), which includes a new ‘flavor’ of ACES called ACEScct..
In this Insight, with the help of ACES workflow expert Nick Shaw, who edited this article and corrected many of my math mistakes, I want to discuss ACEScct and how it’s different (and maybe better than ACEScc) but how in many other ways is the same as ACEScc.
You’ll also see ACEScc & ACEScct in action and how they differ when grading in a video at the end of this article.
If you haven’t already, be sure to check out the previous three installments in this free series starting with Part 1.
Finally, before we jump in, be sure to check out the ACEScentral portal sponsored by AMPAS. The ACES team is pushing this site for anyone interested in ACES – both from a creative & technical standpoint.
ACES Version Confusion
When Blackmagic announced Resolve 12.5.3 it was the first time that most people had heard about an update to ACES since the 1.0 release last year.
Resolve 12.5.3, both in documentation and within the application lists ACES 1.02 as the latest officially supported release of ACES.
But the confusing thing is ACEScct was announced as part of the ACES 1.03 specification. This point is made clear by taking a look at the ACES-Dev Github site and the change log for 1.03
Both Nick and I can confirm that Resolve 12.5.3 has a faithful representation of ACEScct, but this means it must support ACES 1.03 and not 1.02 as listed right? Is there just a typo in Resolve?
Due to the open source development of ACES, Blackmagic most likely started implementation of ACEScct while 1.02 was the current version of ACES and when an experimental version of ACEScct was committed to the dev branch , but 1.03 had not yet been officially released.
Blackmagic Resolve product manager Peter Chamberlain pretty much confirmed this in a Lift Gamma Gain Post
To quote Peter’s post:
‘The 12.5.3 update is to ACES 1.0.2 spec but we also added the new ACEScct color correction working space transforms that are in ACES 1.0.3. The balance of 1.0.3 is still in progress so we didn’t list as a 1.0.3 update but did want to let you know about the ACEScct transforms.’
To sum up: ACEScct is officially part of ACES 1.03, however, Blackmagic implemented ACEScct ‘early’ while not fully implementing 1.03.
In my personal opinion, this move is not only confusing, but again as Blackmagic has done before – a little counter to the standarization attempts of AMPAS with the offical ACES specs.
For backward compatibility when working with ACES, it should be pointed out that offically ACEScct is part of the 1.03 specification (and not 1.02 as the Resolve user interface suggests).
ACEScc vs. ACEScct – It’s All About The Toe!
In previous installments of this series, it was noted that ACEScc was the preferred and most approachable version of ACES available to DaVinci Resolve users.
I made this recommendation because no one grades in linear ACES 2065 (2065 is used for archival & file transfers), and ‘DaVinci ACES’ is not ‘real’ ACES.
While ACEScc has become the defacto standard for colorists when using ACES, not every colorist has been happy about how ACEScc ‘feels’ especially when it comes to lift operations.
This is true because ACEScc uses an actual log curve.
But for many colorists, that log curve feels different in the shadows compared to the encoding of traditional film scans.
Nick has a perfect phrase to describe how lift operations feel in ACEScc (note: I steal this for the video below but is origin is all Nick!):
‘It’s like blacks are stuck to 0 on the waveform, just like a piece of gum on the floor.”
Why does this happen?
It happens because ACEScc uses a true Log curve – and as it gets closer to representing linear zero (true black) it can never actually get there!
To put this in math terms – the log of 0 is negative infinity. Technically, math nerds know: The log of 0 is undefinable.
For a more faithful technical explanation here’s how Nick puts it:
‘A reduction of one stop is a halving of the amount of light, and a true log curve like ACEScc decreases by the same amount for each stop. A one stop reduction reduces the ACEScc value by 0.057.’
‘But if you keep halving something, it gets smaller and smaller, but there is always something left, even if it’s infinitesimally small. And it certainly never gets below zero.’
The ‘keep going, but never get there’ of ACEScc is why attempts to lift deep shadows feel like as Nick puts it you’re ‘peeling gum (signal) off the floor, stretching it slowly’.
And for many colorists, that’s not a good feeling.
To be honest, in the films that I’ve graded in ACES I’ve never really felt this was a ‘limitation’. But now that I understand this behavior I can totally see how it drives some colorists crazy.
ACEScct to the rescue!
The principle goal of ACEScct is to address the way that shadow behaviors work. Shadow adjustments now feel more like what colorists expect with a traditional film scan.
ACEScct does this by introducing a ‘Toe’ to the encoding—and ‘Toe’ is the ‘T’ in ‘cct’.
ACEScc & ACEScct are identical above 4.5 stops below middle gray (note: both also use AP1 Primaries) and below that, ACEScc continues to extend its log curve while ACEScct morphs into a straight line.
This transition allows ACEScct to actually get one to true 0 black (and into negative values). Keep in mind, linear 0 is a positive value in ACEScct.
IMPORTANT: On a log vs. log graph like the one above, the logarithmic curve (ACEScc) is actually shown as a straight line vs. the linear curve (ACEScct), which actually becomes a curve. Nick assures me this is correct! But yes, it’s confusing!
You can see from about -4.5 stops below middle gray and above ACEScc and ACEScct are actually exactly the same!
Stated differently, ACEScct simply changes the behavior of the grading controls in the shadows. This makes it a natural alternative to ACEScc.
As an added benefit, a few colorists I’ve talked to (who have recently started projects in ACEScct) have said it fixes the ‘gum off the floor’ effect. They’re noticing less shadow noise – which is probably due to less pulling or stretching of the shadows and more of a straight lift.
I’ve mentioned several times that ACEScct was designed to feel more like a traditional film scan.
That might mean a few different things depending on who you talk to (Cineon for example). However, many colorists I know love how the LogC working space feels (which is different than the ACEScc log curve).
In the graph above you can see that ACEScct is similar to LogC. For colorists who like the ‘feel’ of LogC, and who have balked at how ACEScc feels, ACEScct may be a great alternative.
Limitations Of Working In ACEScct
While ACEScct seems awesome, it might not be the best fit for your color pipeline – yet.
Since ACEScct only appeared in version 1.03, if you have to interact with others in your pipeline who are using software not yet updated to ACES 1.03 then you need to stick to ACEScc (please don’t update in the middle of a project!)
Remember, ACES is all about a pipeline! Avoid the temptation to jump right to the latest and greatest without checking with vendors or other people you’re interacting with.
Plus—if ACES Proxy is/was being used on set and ASC-CDLs were generated, then you’ll need to stick to ACEScc.
ACEScc and ACES Proxy share the exact same curve. Because of the toe in ACEScct if it’s used, CDL values in the shadows will not look the same.
Should I Be Working In ACEScct?
Like many things in the world of color, there is no right or wrong! ACEScct is simply an alternative to ACEScc. Nothing changes about the overall workflow.
If you’re going to work in ACEScct and do a VFX handoff then you’ll use Nick’s DCTL to generate your LUT for the VFX handoff.
The bottom line?
If you’re about to start a new project and want to give ACEScct a try, go for it! Just remember to check with other folks in your pipeline and make sure their software supports ACES 1.03 and ACEScct.
I’m starting another feature using ACES in late December. I plan on using ACEScct so I’ll report back with my experiences. Just remember, as with any workflow, please do a little testing before you jump in on your next project.
In Future Installments Of This Series
In part 3 of this series we explored a VFX handoff and roundtrip. What I didn’t show you was how an ACES workflow is handled in a VFX application like NUKE.
In the next installment, Nick Shaw will jump into this series as a Mixing Light contributor.
Using NUKE, he’ll show how to take shot handoffs, setup ACES workflows and render shots back out for the colorist.
Nick will fill in the missing section of Part 3 that I called ‘VFX Magic’!
Finally, we’ll wrap up this introductory series on ACES by answering some questions from Mixing Light members (and non-members too, since this series is free). If you’ve got a question that you don’t want to publicly put into the comments,please use the Contact Us form.
Specific topics include using your own custom DCTL scripts (custom IDTs), ACES vs. other color management systems and a few other interesting questions.
VIDEO: Setting Up Resolve To Use ACEScct & Comparing To ACEScc
Now that we’ve discussed ACEScct and compared it to ACEScc, you’ll see how this works in DaVinci Resolve.
In the video below, I’ve set up a project in Resolve with ACEScct. We’ll compare how the grading controls work vs. switching the project over to ACEScc.
As always if you have questions or things to add to the conversation please use the comments below!