How to Set Up ACES in DaVinci Resolve for Multi-Camera Projects

ACES helps on multi-camera jobs when several cameras have to feed one managed grading pipeline. It only works if every source is identified correctly before matching starts. Resolve won't reliably infer that one angle is ARRI LogC3, another is Sony S-Log3/S-Gamut3.Cine, and a third is Blackmagic Film Gen 5. It won't guess that the drone file is baked Rec.709 either. You have to tell Resolve what each source is. So the setup runs in a fixed order. Configure project color management once. Assign an input transform to every source, batched by camera. Pick the output transform for the display in the room. Then test all of it on a short timeline before anyone makes a creative decision.

Mixed cameras need matching input transforms, not one shared guess.

The basic ACES path in Resolve

In an ACES-managed Resolve project, the image moves through three stages. Source color space and camera encoding enter through an IDT, or Input Device Transform. Resolve converts that material into the ACES working environment, where you grade the image. Resolve then converts the result to your monitor or delivery target through an ODT, or Output Device Transform. The two settings that most often create visible problems are:

The ACES Input Transform tells Resolve what the source is.
The ACES Output Transform tells Resolve what display or deliverable you're targeting.

If either one is wrong, the picture can still look plausible enough to delay diagnosis. A wrong IDT can look like a creative contrast choice. A wrong ODT can look like a monitor issue. A double transform can look like bad exposure. Build the project so those questions are settled before anyone starts making creative decisions.

Project color management

Open Project Settings and go to Color Management. For grading work that benefits from log-like controls, choose ACEScct as the color science. ACEScc is also available, but ACEScct has a toe in the shadows that many colorists find easier to grade with than the fully logarithmic ACEScc response. Follow the spec if a studio, platform, or show LUT pipeline specifically requires ACEScc. Otherwise ACEScct is the more practical default for Resolve grading sessions. Then set the ACES version approved for the job. If no version is required and your Resolve version offers ACES 1.3, that's a reasonable choice, because 1.3 includes the ACES Reference Gamut Compression option. On ACES 1.3, turn on Apply ACES Reference Gamut Compress before the grade starts and leave it on. Don't toggle it halfway through a job. It changes how saturated out-of-gamut colors are handled before creative corrections are applied. For a mixed-camera project, that leaves four project-level settings:

Color science: ACEScct.
ACES version: the version approved for the job, with Apply ACES Reference Gamut Compress enabled on ACES 1.3 unless the show spec says otherwise.
ACES Output Transform: the ODT that matches the calibrated monitoring target.
ACES Input Transform: leave it unset unless the entire project uses one camera color space.

Once this is set, save the project and communicate the settings to anyone else touching the grade. Color management is a project decision, not a private preference on a shared show.

Per-source IDTs for mixed-camera projects

The project-level ACES Input Transform is useful on a single-camera project. On a multi-camera project, it's the wrong place to solve source interpretation unless every camera used the same gamma and gamut. Picture the common case. A-cam is ARRI LogC4 and B-cam is Sony S-Log3. C-cam is Canon Log 2, the drone is D-Log, and the screen recordings are Rec.709. A global ARRI LogC4 IDT forces every non-ARRI clip through the wrong transform, so the timeline is already incorrect before grading begins. Assign IDTs per source instead. In Resolve, you can right-click clips in the Media Pool or timeline and assign an ACES Input Transform at the clip level. The exact menu location varies slightly by Resolve version. The principle doesn't: the clip gets its own input transform, overriding the project default. Organize sources before assigning transforms so you can work in batches. Useful bins on a mixed-camera show:

A-Cam ARRI LogC4, B-Cam Sony S-Log3, C-Cam Canon Log 2
Drone D-Log
Stills, Graphics, Rec709 Archive

Confirm four things per batch before you assign anything: the recording format and gamma, the gamut, and the camera generation. Camera reports, file metadata, or the DP/DIT can supply them. Then select the matching clips and assign the correct ACES IDT to all of them at once. After assignment, open a representative clip from each camera and compare them on scopes before grouping or matching. Write a short project note listing the IDT choices. The next colorist or assistant will need it, and so will the online editor and the conform artist.

Camera generations matter

Camera names alone aren't enough. “ARRI LogC,” “Blackmagic Film,” and “Sony Log” don't identify a transform. A few common places people get burned:

ARRI ALEXA LogC3 and ARRI LogC4 are different and need different transforms.
Blackmagic Design Film Gen 4 and Gen 5 shouldn't be treated as interchangeable.
Sony S-Log2 and S-Log3 are different, and Sony gamuts matter too.
Canon Log, Canon Log 2, and Canon Log 3 are different encodings.
Panasonic V-Log/V-Gamut shouldn't be treated like generic log.
DJI, GoPro, phone HDR, and drone “flat” profiles may not have complete ACES support.

A camera report that says only “shot log” isn't enough to assign an IDT confidently. Go back and ask for these:

Camera model and recording mode
Recording gamma and gamut
Firmware generation, where it is relevant
Whether any LUT was burned in

RAW sources

Resolve can often debayer RAW sources into the ACES pipeline using camera metadata and supported camera SDKs. That's convenient. Still open the Camera RAW settings and confirm what Resolve is actually using. For RAW clips, pay attention to:

Decode using camera metadata versus project settings.
Color science or generation settings, especially for Blackmagic RAW.
ISO, white balance, tint, and exposure metadata.
Whether the clip has been transcoded to a non-RAW mezzanine file before it shows up in the Resolve project.
Whether editorial proxies were made with a baked LUT that isn't present in the camera originals.

RAW still leaves room for mistakes. Resolve only has accurate source information if the conform points at the original media rather than a flattened or LUT-baked intermediate.

Baked Rec.709 and graphics

Not everything in a multi-camera timeline is scene-referred camera footage. The same sequence can hold archival clips and screen recordings. It can hold graphics, subtitles, and logos. It can hold phone videos, social media exports, and editorial temp renders. None of those belong under a log camera IDT. If a clip is already display-referred Rec.709, assign an appropriate Rec.709 input transform. The alternative is to keep it on a separate display-referred path, depending on the project design. Either way, don't pretend it's log. A baked Rec.709 file pushed through an S-Log3 IDT comes out low contrast, oddly saturated, or wrong in a way that wastes matching time.

Already finished Rec.709 material should not be treated like camera log.

Graphics need their own handling. A lower-third designed in sRGB on a computer display may not behave like camera footage under ACES. Decide whether graphics arrive as display-referred elements, scene-linear EXRs, or something else, then hold that rule for the whole show. For SDR broadcast-style work, a graphics white level around 100 nits is a common practical target. Follow the show's finishing spec when one exists.

Multicam clips

Resolve's multicam tools are useful for editorial, and they hide the source-level differences that matter to color. Build a multicam clip from several camera formats, then look only at the multicam container, and it becomes easy to miss that the angles need different IDTs. So assign source IDTs before creating multicam clips. Each angle then enters the multicam structure already interpreted correctly. If the multicam edit already exists, inspect the underlying source clips. The transforms have to be attached to the actual camera media, not just adjusted visually on top of the multicam timeline. For finishing, teams often flatten or decompose multicam edits back to original clips once picture is locked. That makes the color timeline easier to audit, easier to group by camera, and easier to conform if something relinks badly. If you keep multicam containers live through color, build a small test timeline with one shot from each angle and confirm that IDT changes behave as expected before grading the whole show.

Choosing the ODT

The ODT should match your reference display and monitoring environment. Treat it as the display transform that tells Resolve how to show ACES-managed image data on your target display.

The output transform should match the display you are actually judging.

For common finishing scenarios, the ODT decision looks like this:

For SDR broadcast or standard video monitoring, use Rec.709 for a calibrated Rec.709 display, commonly around 100 nits with BT.1886 or the facility’s specified gamma.
For HDR PQ mastering, use P3-D65 ST.2084 with the nit level that matches the mastering display, such as 1000 nits if that's the approved monitor target.
For web graphics review on computer displays, sRGB may be useful for review, but don't treat that as a broadcast Rec.709 master unless the delivery spec says so.
For archival ACES outputs, use no display ODT only when you're intentionally exporting ACES data for another managed stage, not for normal client viewing.

Set the ODT to the display being used for approved monitoring, then create separate output passes for different deliverables. Don't grade on an HDR ODT and render an SDR master without a proper SDR trim or transform pass.

The viewer and the reference monitor

Resolve's GUI viewer is fine for interface work and quick checks. A calibrated video output path is the correct reference for finishing decisions. On macOS especially, display profiles and viewer color settings can affect what you see in the interface. An ACES workflow can therefore look different in the GUI viewer than through SDI monitoring, depending on system settings and Resolve preferences. For serious finishing, trust a calibrated external display fed through a proper video I/O path. If the GUI viewer and the reference monitor disagree, don't “fix” the grade to make the GUI viewer feel better until you understand the display path. That's how teams accidentally compensate for the wrong thing.

Where Premiere Pro and Media Composer fit

Premiere Pro, DaVinci Resolve, and Media Composer can all be part of a professional multi-camera workflow. Each has a different role when the job is an ACES-managed finish. Premiere Pro is often used for editorial on projects with mixed codecs, proxies, and quick-turn review exports, graphics included. It has color management features, and it can carry viewing LUTs and basic transforms for editorial review. On an ACES grade, Premiere is commonly the offline or finishing edit environment. The locked edit then goes to Resolve, Baselight, or another dedicated color system. The risk is that an editor's viewing LUT or display management gets mistaken for the final color pipeline. Media Composer is built for longform editorial and shared storage workflows, and for turnovers and AAF-based post. It can support editorial color adapters, LUTs, and reference looks, but the final ACES color-managed grade rarely happens there. On an ACES job, Media Composer's main responsibility is to preserve the edit and its metadata, protect source timecode, and hand over a clean turnover. DaVinci Resolve is the most direct of the three for setting up and finishing an ACES grade. Color management, per-clip input transforms, and RAW controls all live in one environment, and so do the scopes, the grouping and trimming tools, and delivery. Edits can still happen elsewhere. If Resolve is your color finishing system, it should be the source of truth for ACES transforms and final monitoring. The practical division of labor is simple: let editorial systems help people edit efficiently, but don't let editorial viewing transforms become undocumented color science.

Turnover information that protects the ACES setup

A reliable ACES setup starts before the colorist opens the project. Hand over a timeline with duplicate filenames and missing camera reports, plus baked LUTs and undocumented transcodes, and the color-managed grade becomes detective work. For multi-camera ACES jobs, production and editorial should provide the information that affects color interpretation:

Camera model and sensor mode for each source.
Recording gamma and gamut, not just codec.
Camera generation or color science generation where relevant.
Whether LUTs were used only for monitoring or baked into files.
Original camera filenames with unique names across cards.
Camera reports, DIT reports, or at least a source map by shoot day and camera.
Reference exports from editorial with the temp look included.
Notes for any archival, stock, phone, screen recording, or drone material.

Use this information to build your bins and IDT assignments before matching cameras. If something is missing, flag it early instead of grading around uncertainty.

Unsupported sources

Some sources don't have an official ACES IDT available in Resolve. The camera may be too new or too obscure. It may be consumer-oriented, or recorded in a profile that ACES doesn't officially support in your Resolve version. The wrong move is to pick a random IDT that “looks close” and keep going without telling anyone.

Unsupported sources need deliberate handling instead of a random transform.

There are a few defensible ways to handle unsupported sources:

If the manufacturer provides a documented ACES IDT or technical transform, use that and document it.
If Resolve has a Color Space Transform option for the camera gamma and gamut, you can use a node-level transform into the ACES working space, but keep it as the first technical operation and label it clearly.
If the source is display-referred Rec.709, treat it as Rec.709 instead of forcing it through a log transform.
If the source is unknown, contact the DP, DIT, camera department, production company, or vendor before guessing.
If you must match by eye, isolate those clips, document that they're unmanaged or custom-managed, and avoid making them the basis for show-wide look decisions.

Separate official ACES-managed sources from best-effort sources. A mixed-camera grade can carry some best-effort material as long as it's documented. It becomes difficult to manage when every transform is treated as equally valid.

LUTs inside ACES

Most camera LUTs are designed for a specific input and output, often log camera space to Rec.709. Drop that kind of LUT into the middle of an ACEScct node tree and you may be feeding it the wrong color space. The LUT will still create contrast and color, but not the contrast and color it was designed to create. Use LUTs only when you know their expected input and output. A technical LUT belongs in the correct technical position. That means before ACES conversion, inside a documented custom input path, or outside the ACES-managed pipeline for editorial reference only. Creative show LUTs should be built or adapted for the working color space they're used in. This matters when matching cameras. If one camera has a manufacturer LUT applied and another uses a proper ACES IDT, you're no longer comparing cameras through the same pipeline. You're comparing two pipelines.

Matching cameras after the transforms

Once every source has the right IDT, camera matching has a cleaner starting point. Start with exposure and contrast, then white balance and saturation, and save the heavy look for later. Use scopes and whatever known references sit in the frame. Gray cards and charts help, and so do skin and wardrobe. Product colors, practical lights, and repeated set pieces work too. Group grades can help, but group by camera and source condition rather than by scene alone. An ALEXA Mini in LogC3 and an ALEXA 35 in LogC4 shouldn't automatically share the same pre-clip correction. A Sony FX6 and a Sony VENICE might both be S-Log3/S-Gamut3.Cine and still need different matching trims, because sensor and lens differ, and so do exposure and compression. A practical node structure keeps technical and creative work separated:

Source or camera balancing near the start.
Shot matching after the source balance.
Creative look at the group or timeline level.
Output-specific trims near the end, especially when making SDR and HDR versions.

Keep that separation intact as the grade gets busier. If you solve a bad IDT with a creative node, somebody may eventually copy that grade to the wrong shot and spread the problem. Before grading the whole show, build the test timeline. Take one representative shot from every main camera, plus the drone and the phone. Add one archival clip and one graphic, one VFX shot, and one of any oddball codec. Then work through it in order:

Assign the intended IDTs.
View through the intended ODT.
Make basic exposure and balance adjustments.

Now read the result. A correctly managed log camera should appear in a reasonable place before the grade, and a Rec.709 clip shouldn't collapse when it enters the project. Saturated lights shouldn't clip or shift in a way that looks unrelated to the photographed scene. Skin shouldn't require extreme corrections just to become plausible. If one source needs extreme corrections immediately, don't start matching around it. Go back and confirm the IDT and the camera metadata. Check the LUT history, and check whether the clip is an original or a baked transcode. In multi-camera ACES work, catching that problem early costs less than rebuilding late.

Common ACES failure modes in multi-camera timelines

ACES problems in mixed-source timelines usually come from setup mistakes rather than creative grading choices. The failures you're likely to see are:

Every camera is using the project-level IDT, even though the timeline is mixed-source.
A baked Rec.709 clip is being treated as log.
A log clip has both an ACES IDT and a camera LUT applied, creating a double transform.
ARRI LogC3 and LogC4 clips are being treated as the same thing.
RAW settings changed after grading started, shifting exposure or color temperature.
The ODT is set for HDR while the team is judging on an SDR monitor.
The GUI viewer is being trusted over the calibrated video output.
A VFX EXR is tagged as a camera log file instead of ACEScg or ACES2065-1.
Editorial proxies with baked looks are being compared directly to camera originals without understanding the LUT path.
Someone changed the ACES version or Reference Gamut Compression setting mid-project.

When something looks wrong, diagnose the transform path before adding more corrections. A bad transform can rarely be fixed cleanly with more secondaries.

VFX and EXR sources

VFX pulls need clear color instructions. If the show is ACES-managed, VFX vendors should know whether plates are being supplied as camera originals, ACES2065-1 EXRs, ACEScg EXRs, or something else. Those labels determine how shots come back into Resolve. For returned EXRs, assign the input transform that matches the file's actual color space. ACEScg is common for CG and compositing. ACES2065-1 is common for interchange. Don't assign an ARRI or Sony camera IDT to an ACEScg render just because the original plate came from that camera. Once VFX has rendered into ACEScg, the file is no longer camera log footage. When in doubt, ask the VFX vendor for the exact working and delivery color space. “It’s ACES” isn't enough, because you need to know which ACES color space.

Output and delivery passes

ACES makes it easier to target multiple outputs, because the output transform is separated from the scene-referred grade. Each output still needs its own review. An SDR Rec.709 master and an HDR PQ master are different deliverables, and so are a web sRGB export and an archival ACES file. None of them is one render with a filename change. For each output, set the ODT or export path on purpose, review it on an appropriate display, and render from a clearly labeled project version or timeline. If the job needs both HDR and SDR, don't assume the SDR version is approved just because the HDR grade is approved. Make an SDR trim pass. Also watch data levels on export. A correct ACES transform can still be undermined by a full/video range mismatch, codec tag issue, or platform-specific interpretation. Render a short test file and re-import it. Compare it against the timeline through the same monitoring path before committing to the full delivery set.

Source type	Typical Resolve ACES handling	Confirm before grading
Camera log footage with official ACES support	Assign the matching clip-level ACES IDT, such as ARRI LogC3, ARRI LogC4, Sony S-Log3/S-Gamut3.Cine, Canon Log 2, or Blackmagic Film Gen 5	Camera model, gamma, gamut, color science generation, and whether a LUT was baked in
RAW camera originals	Use Resolve Camera RAW settings and supported metadata to bring the source into the ACES pipeline	Decode settings, ISO, white balance, tint, color science generation, and whether the conform points to originals
Baked Rec.709 video, archive, or screen recordings	Assign an appropriate Rec.709 input treatment or keep it on a documented display-referred path	Whether the file is truly display-referred, whether it contains a baked look, and expected legal or full range
Graphics and titles	Treat according to how they were created, such as sRGB display graphics or scene-linear elements	Design color space, intended white level, alpha handling, and final delivery spec
VFX EXR returns	Assign the transform that matches the EXR color space, commonly ACEScg or ACES2065-1	Vendor delivery color space, whether the file is CG, comp, or plate-based, and any embedded metadata
Unsupported camera or unknown source	Use a documented manufacturer transform, a clearly labeled Color Space Transform, or isolate as custom-managed material	Source origin, gamma, gamut, LUT history, and approval from the DP, DIT, vendor, or post supervisor

FAQ

ACEScct is the best default for grading in Resolve, because its shadow response feels more natural for color correction than ACEScc. Use ACEScc only when a studio, platform, or show pipeline specifically requires it. Choose the latest ACES version approved for the job, and do not change that version after grading has started.

Only when every clip in the project was shot in the same camera color space and encoding. For mixed-camera timelines, assign the ACES Input Transform per clip, or per batch of clips, in the Media Pool. Each camera source needs the IDT that matches its actual gamma, gamut, and camera generation.

Do not treat baked Rec.709 footage as log camera material. Assign an appropriate Rec.709 input transform, or manage it through a separate display-referred path, depending on the workflow. The same applies to archival footage and screen recordings, to social media exports, and to some drone or phone clips that are already display-referred.

Choose the ODT for the display you are actually using for approved monitoring. For SDR grading, that usually means a Rec.709 output on a calibrated Rec.709 monitor. For HDR mastering, use the PQ or HDR ODT that matches the mastering display, such as P3-D65 ST.2084 at the target nit level. Do not grade under one ODT and assume another deliverable will look correct on its own.

First check whether the manufacturer provides a documented ACES IDT or technical transform. If not, use a clearly labeled Color Space Transform, and only when the source gamma and gamut are known. If the footage is already Rec.709, treat it as Rec.709. If the source is unknown, contact the DP, DIT, camera department, or vendor before guessing. Document unsupported sources so nobody mistakes them for fully managed ACES material.

Build a source map. For each batch of media, record the camera model, the gamma and gamut, the camera generation, the LUT status, and the assigned IDT. Aspect can store those fields alongside the assets, so assistants and colorists can filter and sort sources with custom metadata.