ACES workflow for VFX production (ACEScg)

In light of why we advocate for not doing VFX work on graded footage, here’s how we convert camera footage for an ACES workflow for VFX production.

We’ll be covering the workflow over these few steps.

Resolve: Plating
Nuke: Layout and Prep
Maya: CG Production
Nuke: Comp and Deliver
Resolve: Check!

Mandatory disclaimer:
Regarding ACES workflow for VFX, there are a few things you should know! Mainly understanding some basics of Color Spaces, video compression, chroma subsampling and bit depth. Here are some useful articles and videos that can help you to understand these concepts before we dive into our ACES workflow for VFX production.

Resolve: Plating shots

Alright, now that we have a general idea of what is going to happen under the hood, here’s one way we work with footage in a VFX pipeline that ensures we respect the pixel information until delivery.

Scene setup in Resolve (ACES)

Resolve is excellent at handling color and conforming a plethora of footages to one that will suit an ACES workflow for VFX pipeline. In our case, we’re talking about conforming everything to ACEScg.

There are a few ways to setup the Resolve for ACES conversion plating. Let’s use the one that has less things to click.

Resolve project Settings:

Highlighted in green (in the screeshot above) are the things that we need to set.

Color Science: ACEScc (ACEScct works as well. No difference to what we are doing)
ACES Version: Using the same version as the rest of the pipeline is recommended. But there’s usually no harm picking the latest.
ACES Input Transform: No Input Transform (We will be selecting this based on the clips later. If all clips are from the same camera, you can set this here too)
ACES Output Transform: sRGB (Only for viewing purposes, we will change later this when exporting.)

Plating from LOG footage

When plating from LOG, it is 1000% important to get the camera information. Without this information, our conversion might be wrong, and anything less than correct is not acceptable.

CAT FOOTAGE EXAMPLE TIME!~~

Here’s a LOG clip of our beautiful studio cat, Caipng! Right now, the colors look funky because Resolve is assuming our LOG clip is in ACES. And it’s performing all the necessary transformations required to display ACES on our sRGB monitor. Everything is working correctly, except that the input color space is not set. So let’s fix it!

Input Device Transformation

Apply an ACES input transformation to convert our LOG clip into ACES.
In our case, this was shot on a Blackmagic Pocket Cinema 4K Camera, in Film LOG, So we’re going to select “Blackmagic Design 4k Film Gen 3”

After the conversion, things look correct now!

FYI, a summary of the color conversion happening under the hood here:

Input Device Transform: Blackmagic Design 4K Film Gen 3 > ACEScc
Output Device Transform (Display): ACES > sRGB (Our monitor)

Plating for RAW footage

Plating for RAW footage follows the same general concept, except that RAW files are ‘digital negatives’ which Resolve, needs to resolve 🤣… So we need to specify the input device transform in the Camera Raw section of the Color Module.

Here we have a clip of a balcony, shot in Blackmagic RAW:

When Resolve is set up to work in ACES, RAW files usually end up being automatically processed correctly and viewed in the defined output transform color space. If for whatever reason your RAW file needs to be processed differently, head to the color tab and adjust the Camera RAW settings.

Under the color tab, and in the Camera Raw settings, choose the appropriate input data and Resolve will handle the rest. (If your Project is currently set up to view ACES in sRGB, you should see an image that is correct, like the one in the above image.)

If you are ready to plate the image, set the project’s output transform from sRGB to ACEScg. Similar to plating for LOG, it will look funky when ACES is viewed without an appropriate output transform on our 8bit monitors. But not to worry, the information here is correct for an ACEScg workflow.

Getting ready to plate in ACEScg

Change output device transfrom to ACEScg.
We’ve previously set the output transformation to accommodate viewing the image correctly on our sRGB monitors, now we want to output to an ACEScg workspace, we we have to change this setting here.

In the settings tab, under color management, we’ll now select ACEScg as our output transform.

The image now looks funky again, because our monitors aren’t able to display the copious amount of information in ACES. But that’s okay, we’re going to export all this information into a nice spacious EXR container for use in production.

Delivering plates for production (in EXR)

There are many different ways to deliver (export) clips from Resolve. In our case, we want to retain data especially those hidden in overexposed highlights, we’re going to use OpenEXR.

Export video as Individual clips. Every clip on the timeline will be exported individually.
Choose EXR, RGB half (ZIP Compression): This exports a 16bit compressed lossless EXR file which would be more than sufficient for most cinema level footage which usually ranges from 10-12bit, topping out at 16bit with RED cameras.
Choose the same resolution as the footage

Under file settings, choose what you like, but we prefer these settings:

Use the source name and add unique filenames. This helps with keeping things consistent and ‘traceable’ should anything go awry later on. (you can find the original clip)
Place your plates in a subfolder if you like
We usually change the frame padding to 4 (eg. filename.0001.exr)
Force the clips to start at frame 1.
Place clips in separate folders (if not it’s gonna get really messy with image sequences)

Nuke: Layout and Prep

Disclaimer:
Nuke has to be set up to work in ACES prior to this part, if not colors and values will not behave correctly.

Now, importing our exported ACEScg plate into Nuke should yield results consistent with what we saw in Resolve. Here in Nuke, read our plates as ACEScg Colorspace, and the viewer should be transforming all the ACEScg information correctly to display on our sRGB monitor.

We are now ready to work with our footage in Nuke ACEScg.

Maya: CG Production

An ACES workflow for VFX must include using these clips into some 3D software. And importing our ACES plate into Maya is straight-forward since the default working color space is ACEScg. All linear encoded files (like EXR) are read in “Raw”, so proper color management is performed automatically.

This should work the same for other 3D software like Houdini and Blender, as long as they are set up to work in ACEScg, and are reading our plates (color space) correctly too.

Nuke: Comp and Deliver

Now let’s give our cat Caipng, some floating magical pink thingies in comp.

Perfect. Now, here we have two ways to deliver our work from Nuke.

OpenEXR image sequence (ACEScg/ACES2065-1)
MOV ProRes 4444 file (ARRI V3 Log C EI800 Wide Gamut) <<preferred.

OpenEXR image sequence (ACEScg)

This is technically the ‘best’ output deliverable since it is virtually a 99.99% 1:1 export from whatever we work on in Nuke. The only issue with this delivery, is the file size. On top of that, most video production houses don’t like working with EXR image sequences; It’s slow to read, and cumbersome to organize.

MOV ProRes 4444 file (ARRI V3 Log C EI800 Wide Gamut)
Alternatively, what we find the ‘best’, is a reasonable compromise! Exporting in a LOG format that is widely used in the industry is something we’ve found to be both extremely compatible, and space-saving. too.

ARRI Log C is more or less the de facto industry standard for high quality digital cinema work. And more importantly, video production houses are generally well equipped with ARRI-based workflows. So this deliverable should make it easy to work with.

Export Comparison EXR(ACEScg) vs ProRes(ARRIv3LogC):

Here on the left, is a screen grab of the viewer in nuke. And the two columns on the right, you can see that both exports are virtually identical to the composite we had in Nuke. However, the EXR export is 20x larger than the ProRes export. Of course there is some data loss, so let’s see exactly how much data is lost.

In the second row of images, we took the exports and removed the original composite from it to see how much difference our export is from the original comp. Sampling the same pixel, at 100x exposure gain, we see that there the ProRes export has more data variance from the original image than the EXR. But to be honest, it’s very minimal and well worth the compromise.

Just to be doubly sure, we can always check our footage back in Resolve to see how well it holds up against the original LOG footage from camera. And see if there is any discernible data loss with the ‘compromised’ ProRes export.

Resolve: Check it, and send it!

The final part of the ACES workflow for VFX production, is kinda optional if everything else is done right. However, human error is a real thing, so checking our exports is highly recommended.

Bringing our exports back into Resolve, we can check if we’ve got our color management workflow correct. The same grade should behave the same for the original clip, as well as our exports (less the new CG element).

Importing our Nuke renders into Resolve to check

On initial import, you’ll find that the ACEScg EXR image (top right), and the ARRI LOG ProRes image(bottom) both look wrong. And you guessed it, we need to set our IDT (Input divide transform) to get them working right.

IDT: ACEScg EXR Image

IDT: ARRI LOGc ProRes Image

Comparison after IDT

Once we’ve applied the correct IDTs, we can see that everything lines up correctly. We’ve indicated which part of the image corresponds to the section in the parade scopes.

Green is the original LOG footage
Blue is the EXR ACES comp export
Orange is the ProRes 4444 ARRI LogC export.

As expected, there is some slight degradation in the data from the ProRes export. (The banding of data when the parade scopes are sized down like this) However, if we take a look at the just the scopes for the ProRes export, it’s actually not all that bad!

Parade scopes for ProRes ARRI LOGc export:

Grade Check
Finally let’s apply the same grade to all three clips to see if everything works correctly.

Some simple grade here for checking.. And hurrah! It works! Less the bleed from the glow adding a very slight tint of magenta across the cat’s face. This is something most colorists would be able to solve quickly, if required, however one could argue that the magenta spill is more ‘realistic’.

In any case, a slight nudge in the grade fixes this 🙂

At this point we can either fix our glow, or make a call to send it since we confidently know the export works!

Conclusion

The actual ACES workflow for VFX production in practice is a lot more straight forward, as this post covers quite a bit of extra basic and explanatory stuff. The important take away here is that we are aiming for a healthy balance of data integrity, file handling(size & speed), and low-friction across production software. This is something that plating into ACES, and exporting back as a high qality LOG file provides a reasonable balance of all three. For ultimate quality, delivering as an EXR image sequence would yield the highest quality results.

Please let us know if we made any errors or feel free to contact us if you have any questions! Cheers!