ACEScg Workflow for DaVinci Resolve
Learn how to properly create ACEScg plates for VFX compositing and Color, as well as the often overlooked best method to load and conform those ACEScg plates back into Resolve to avoid scaling filters creating negative pixels.
Here is the link to Thatcher Freeman’s Linear to Log DCTL’s on github - https://github.com/thatcherfreeman/aces-transforms/tree/master/Linear%20to%20Log%20Conversions
Here’s the link to join my free email list to get my deliver page presets and shot namer script covered in the “Pro Sources Sequence Finishing Workflow” tutorial - https://mailchi.mp/creativevideotips/shot-namer
Mastering ACEScg in Resolve: Non-RAW Workflows and The Linear Scaling Problem
If you are doing high-end finishing work, building a solid source sequence is a critical first step. While working with Blackmagic RAW footage makes this process relatively straightforward, complications arise when you need to process non-RAW footage (like H.265) or when you need to resize those linear plates during the conform.
A major technical pitfall in this workflow is the "linear scaling problem," where resizing linear images introduce negative pixels (out of gamut). Below is a comprehensive guide on how to properly convert non-RAW footage to ACEScg, why you should choose specific codecs like DWAB or PIZ, and how to solve the scaling issue using DCTLs.
Converting Non-RAW Footage to ACEScg
If you are starting with footage that isn't RAW—for example, 10-bit Log H.265 from a Sony FX3—you cannot simply debayer it directly to ACES. Instead, you must manually transform it.
The Color Page ACES Transform
Use the ACES Transform effect to move your footage into the ACES pipeline:
Input Transform: Select the specific log format used in-camera (e.g., Sony S-Log3, S-Gamut3 Cine).
Output Transform: Select ACEScg.
Gamut Compression: Do not apply gamut compression at this stage. Since you are writing to EXR sequences, the file format can easily store negative values caused by camera noise or high color intensities without clipping. The point at this step in the workflow is to fully retain data from the original footage.
ACEScg (AP1) vs. ACES 2065-1 (AP0)
You might wonder why we use ACEScg (AP1) instead of the larger ACES 2065 (AP0).
AP0 (Big ACES): This is typically required for archival masters, such as Netflix archival. It’s a wasted stretch of data in my opinion.
AP1 (ACEScg): This uses a smaller, more practical gamut that matches ACEScct. For advertising and commercial work where the final deliverable is often ProRes HQ, AP1 is preferred and remains future-proof for HDR workflows.
Rendering: EXR Codecs and Settings
When setting up your render on the Deliver Page, ensure you disable any timeline nodes used for viewing (like a Rec.709 transform) so you don't bake them in. For the codec, you have two main options:
DWAB (45): Highly recommended for advertising workflows. It is not lossless, but it keeps file sizes small (similar to ProRes 444) and is "far more than good enough" for most high-end work.
PIZ: A truly lossless compression codec. Use this if you need to retain the absolute best grain detail and storage space is less of a concern.
Linear Scaling Problem
Once you bring your ACEScg EXRs back into Resolve for the conform, you face a hidden danger: Resizing.
Negative Pixels Can be Created
Any time you scale an image—whether through the Edit Page inspector or by using a timeline with a different aspect ratio—Resolve applies a resize filter (like Sharper or Lanczos) to remap the pixels.
The Vulnerability: Linear light data naturally contains many values near zero (very dark).
The Filter: To create sharpness, resize filters often "undershoot" values mathematically. When applied to linear data that is already near zero, this undershoot pushes pixels below zero, turning them negative.
Sven with the Noir Grade channel does an excellent explanation of negative or out of gamut RGB code values.
The Pipeline Trap
You cannot fix this by adding a "Linear to Log" conversion node on the Color Page. According to the DaVinci Resolve image processing pipeline, Edit Sizing happens before the Color Page. By the time the image reaches your node graph, the resize filter has already done the damage.
The Solution: Input DCTLs
To avoid creating negative pixels, the image must be converted to Log before it hits the edit sizing engine.
The Workflow
The most effective solution is to use Input DCTLs (specifically those created by Thatcher Freeman) applied at the Media Pool level.
Download: Get the ACES DCTLs from GitHub. These are pasted into your LUTs folder.
Apply: In the Media Pool, right-click your EXR sequence, select LUT, and locate the DCTLs.
Select: Choose AP1 Linear to AP1 ACEScct.
Why DCTLs Instead of LUTs?
It is crucial not to use a standard .cube LUT for this conversion.
LUTs Clamp Data: Standard LUTs clamp all data above 1.0. Since ACEScg EXRs contain "super bright" data far above 1.0, a LUT would flatten that dynamic range into "gray mush".
DCTLs are Full Float: DCTLs operate with full floating-point math. They do not clip data, allowing all the highlight detail to pass through unharmed while safely converting the image to Log for resizing.
By following this workflow, you ensure a safe, artifact-free pipeline that preserves the full fidelity of your footage from start to finish.
