Welcome to native OCIO/ACES support in After Effects!

[Christine Goldby]

It’s a big day for Beta. In today’s Beta build (23.1.0 build 44), you are getting not just one, but two new features to take out for a test drive. Introducing native OCIO/ACES support in After Effects! 

I’ve attached documentation for a deep dive into the feature, including a Quick Start guide which is copied below.  

We would love to hear your feedback, including what you think of the workflow, and whether you get the results you expect. 

As always, thank you so much for participating! 

Quick start 

1. File > Project Settings 
     a. Create an After Effects project and select Color Engine as OCIO color managed.
     b. Select the appropriate OCIO configuration file.
       i. We are shipping the ACES configuration ACES 1.0.3 with the application bundle.  
       ii. NOTE on ACES 1.3 Configurations 
   In addition to the default ACES 1.0.3 configuration, there are now two beta configurations from OCIO which are compliant with ACES 1.3 (ACES CG v0.2.0 (Beta) and ACES Studio v0.1.0 (Beta)). These are still under development, but they do include new features and enhancements setting the stage for ACES 2.0, such as the ability to set the Rules in the config file to an assigned color space. We will update these to the release 1.3 versions once they are available. 
     c. Select a Working Color Space 
     d. Select a Display Color Space2. Add some media (EXR, etc.) to your project 
     a. Media Color Space is automatically assigned a default color space (specified by the default role) 
     b. Media Color Space can be overridden via the Interpret Footage dialog accessed by right-clicking the footage in your Project panel 

3. Create a composition  
  a. Composition window shows color converted content 
    i. Color conversion - Media Color Space to Working Color Space 
    ii. Color conversion - Working Color Space to Display Color Space 
  b. Use the Display Color Space dropdown in the composition toolbar to change which display transform you are viewing 

4. Export the composition 
  a. Add the composition to render queue 

  b. Select the Output Color Space in Output Module Settings > Color dialog 

5. Use OCIO Color Space Transform effect to apply any color space transform to your layer, especially if you need to apply an effect or CDL/LUT that was created in a different color space. 

6. Use OCIO File Transform effect to apply a LUT or CDL to your layer. Make sure to change the color space using the OCIO Color Space Transform if required for that LUT/CDL, and then apply another transform to bring it back to the working space you are using.

[Joanna26443531nz2j]

Wow, thank you for all answers.

I actually haven't had time to go into OCIOv2 - since it's still in Beta I thought I'd just wait.

The monitor color profile thing.

You are right when it comes to monitors that have hardware  calibration - then everything is easy and we can output a specific theoretical color profile to the video out and the monitor will do the rest.

Unfortunately only the professional monitors have hardware calibration. I like all my machines, including laptops to display the same colors so I calibrate them with software calibration which finally exists as a monitor profile in the OS.

So the actual monitor color transfor should be done inside the aplication, after it gets the display color profile from the OS - that's what the Use Display Color Management was for - it took the scene space color values and pushed them through the display color profile and then to the monitor.

This workflow right now is not working. And I don't see why not. Right now after OCIO spits out color values for a pixel to display in Comp Viewer,we are exactly at the same point were we were with the old CMS with the Use Display Color Managemnet turned off and sRGB selected as scene color space.. Just enable that switch and let us turn the function on with OCIO CM as well.

[futureSpooker]

How were you able to get the OpenColorIO plugin from fnord to recognize the official ACES 1.3 OCIO v2.1 config.ocio? Every time I try it it keeps telling me no "default" color space found. This happens with both the CG and Studio configs. Any help would be appriciated.

[justins29082732]

@Christine Goldby In your attached documentation, you'll need to adjust the bit depth in your Project Settings screenshot from 8-bit to 32-bit in order for ACES to work properly.

Thanks team. Been waiting a long time for native OCIO and am excited to test this out thoroughly.

[Christine Goldby]

Ack! Good catch @justins29082732 , totally right. We'll have to update that.

[moebius90009]

still not updated? 

[Christine Goldby]

@moebius90009 - try downloading it again. I just refreshed the link so hopefully it picks it up this time.

[Filip26812379jdvc]

So this happens.

After inspecting the file - those are pixels where one of the channels has a negative value.

During the normal workflow with the OCIO plugin - they just get converted to 0s, and that particular background is just black. But the new OCIO CM makes these pixels glow like a christmas tree 🙂

[Shebbe]

With which config is that happening? Did you test with the same config loaded on the fnord OCIO plugin?

[Filip26812379jdvc]

Both 1.03 and 1.2. It is not happening with the same config and fnord plugin.

[NamrataAgrawal]

Hi @Filip26812379jdvc ,
Thanks for your feedback. 
What are the steps you are trying where you are getting the unexpected results with the files having negative values?

Would you be willing to post the files, so we can take a look on our side?

If you prefer not to share publicly, you can DM me a link to the files. Thanks.

[NamrataAgrawal]

Hi, We have replaced the beta config file (ACES CG v0.2.0 (Beta) and ACES Studio v0.1.0 (Beta)) with the release v1.0 (ACES CG v1.0 and ACES Studio v1.0). 

New changes are available from Beta build (23.1.0 build 60).
Please give them a try and keep sharing all your feedbacks.
Thanks.

[Shebbe]

Thanks for the updated configs. I have a small point about the names. If the idea is to have multiple ACES configs in release all should have a clear naming convention. I know the studio/cg configs are versioned but the ACES version itself is now missing from the folders and thus in the list in the selection. Consider naming these too and if you think it is too confusing to have 2 times a version number I'd remove the package version not the ACES versions, because that is much more important to know the differences. Especially if ACES 2.0 will also sit alongside it when it releases.

I'd do it like this:

[Shebbe]

Oh, and one more note actually. It was brought up before but is there a specific reason why ACES 1.0.3 is currently there? If you feel the need to support the 'legacy' LUT based OCIOv1.0 configuration it should be ACES 1.2 instead.

If it was up to me I wouldn't even add it because there is no need to support it on launch. Everyone can use ACES 1.3 for new projects and later ACES 2.0. This removes the need to include 267MB of data.

Plus it removes another option in the managed list that may add confusion to new users not that familiar with ACES yet.

Any OCIO ACES user that once OCIO AE releases wants to use OCIOv1.0 configs for whatever reason always has the choice to manually add it in AE's OCIO folder, through env vars or manual selection.

[Lars HAGLUND]

Dear all,

ACES 1.3 introduced the "ACES 1.3 Reference Gamut Compression" (RGC, see under "Looks" at https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/releases/tag/v1.0.0).

The RGC is mutually agreed to be "always baked-in", except when exporting ACES 2065-1 based exr-sequences to VFX-artists. The VFX-artists must then always actively choose to initially bake-in the RGC!

Hence, it is critical in "Interpret Footage > Color" to add a sentence checked (enabled) by default: "The ACES 1.3 Reference Gamut Compression (RGC) is inserted by Adobe After Effects as the very first transform regarding this aces_interchange (ACES2065-1, Linear AP0) footage - as the footage itself has not the RGC baked-in."

If the sentence is actively disabled by the VFX-artist, then should the "Description" part of "Interpret Footage" tell that AE does not insert the RGC regarding that specific footage (e.g., in order for the VFX artist to perform better green screen keying etc., but loosing absolute matching to subsequent colour grading of other always RGC-enabled clips in the same scene).

In addition, another subject: The latest MacBook Pros, have very good pre-calibrated display capabilities regarding both HDR and SDR. As the general request to artists regarding VFX, Intros and Credits is to create ACES-based colours that works as creatively intended when adding an SDR-ODT as well as an HDR-ODT: please, make Adobe AE's Viewer to trigger Apple's ColorSync to display valid HDR/SDR colours! (Note: DaVinci Resolve has already that important display possibility in Resolve's Viewer when using these MacBook Pros).

Kindly, Lars

[Shebbe]

It's not mandatory to bake the RGC into VFX before starting compositing. From the ACES docs:

• Frame pulls for VFX should NOT have the Reference Gamut Compression baked in. The files should be debayered to AP0.
• VFX will have the flexibility to apply the RGC wherever is best for their compositing chain. This will often be the first node in the tree, but sometimes operations such as a despill on a bluescreen will need to be performed pre-gamut compression. Sending pulls to VFX in AP0 gives compositors the flexibility to fine tune and control their work.
• Once applied, the Reference Gamut compression should NOT be inverted before delivery.

On top of that I don't think a checkbox on the Interpret Footage -> Color tab is a logical place. The way OCIO is being implemented is color management agnostic. It has no bounds to ACES, other configurations could be run as well with different looks. Unless they'd totally separate ACES as a workflow option but retaining the ability to feed it custom configs it would make sense to add it there. This is why it's possible in Resolve. Also the reason why it's able to utilize the macbook displays because it's internally implemented. It would be a much better solution if Adobe would do the same eventually as it will also allow us to export stills to sRGB with embedded icc for example as it will understand the export intent via the ODT choice.

What is also missing is some extra plugins and functionality on the plugin side. OCIODisplay so we can export with baked display transform. OCIOLookTransform or add Look dropdown menu option on OCIOColorSpaceTransform so we can select looks like the RGC.

[Lars HAGLUND]

Thanks Shebbe,

Regarding specifically version 1.3 of ACES, the company I work for requires (mandates) that the VFX-artist adds the RGC in his/her work (i.e., on the plate once given to him/her without RGC baked-in). That method/procedure is described in the ACES docs. I.e. the colourist that receives the work from VFX, must be sure of that the VFX-artist has baked-in the RGC in order to match the surrounding clips in the scene (that according to the ACES 1.3 method shall have the RGC always enabled).

If not adding RGC on/off in "Interpret Footage > Color Tab", Adobe must please create a third "Effect" in addition to the two exisiting "OCIO Color Space Transform" and "OCIO File Transform" called "OCIO ACES 1.3 Reference Gamut Compression". However, such an implementation gives that the VFX-artist must know that the RGC uses AP0 Linear in/out, not AP1 Linear in/out, hence has to perform "ACEScg > ACES2065-1 > RGC > ACES2065-1 > ACEScg". I.e. there is a manual risc that could be avoided if having a default "RGC on" in "Interpret Footage".

In summary: right now the ACES 1.3 RGC is missing - it has to be solved - in some way.

Kindly, Lars

[Shebbe]

It's totally possible that a facility always uses RGC!:) I just wanted to clear up that the use of it itself isn't mandatory. As to it's implementation you are right. We need a way to implement it right at the IDT stage or later in the pipe through any means. Just also wanted to make clear that the implementation of OCIO itself, which is what Adobe is doing at the moment, doesn't really have any ties with ACES as a color managment option. But yea I hope they will come up with an elegant way to handle this.

[Filip23315833k75u]

Wait, in your company you actually return plates with different colors than you got them??? That is a huge pipeline nono. Everywhere I ever worked and everyone I ever talked to, compositing is absolutely forbidden from any color trasnformations, you give back exactly what you got - this way color grading can go in parllel to vfx work, later on they just copy grading over and it should all match.

[Shebbe]

No it's fine :). If the colorist/DI is using RGC for all their footage, the VFX pulls are exported without it so compositors have the freedom to insert it at a different stage if that makes it more practical for comping. Sometimes they need the unaltered data instead for certain operations. The renders that return to DI will have RGC already baked in (once!) so for those clips it will be turned off in their project resulting in a null with the originals because grading happens after RGC is applied.

[Lars HAGLUND]

Thanks Shebbe for the clarification in your correct reply to Filip!

When archiving "ACES 1.3" Graded Archival Masters (GAMs) this workflow gives that future users of those GAMs know that the IDT regarding the camera footage was followed by the ACES 1.3 RGC. I.e., this "RGC always on" workflow regarding the RGC is as important as the RGC-transform itself. When having many productions going on at the same time, one cannot have conform-technicians making telephone calls to all external VFX-artists regarding random use of the RGC or not. No, let us all follow the method in the "ACES Reference Gamut Compression User Guide" that Shebbe is linking to above.

Kindly, Lars

[moebius90009]

A good Tutorial about the whole stuff? I hope it's accurate 🙂

https://youtu.be/5nVbAJd1R_4

kudos to i_go_by_zak

[Dan Sturm]

This is super exciting, so thank you for this.

Do you have any plans for a setting to adjust clip/comp thumbnails in the project window? Currently, when using the OCIO workflow, the clip is linearized so the thumbnail is so dark it's basically unviewable (attached). I think other apps often include an option to use a lut on the thumbnails? Also, if this is already in the app somewhere, I apologize, I get lost settings easily.

Secondly, it looks like the Display Colorspace of "P3-DCI" matches Nuke and Resolve's "P3-DCI D60 simulation". I don't mind that you don't also have the D65 simulation as an option, but it might be worth noting which version we're using?

[Dan Sturm]

Also, this may be a lot to ask for an intial release / counter to the way AE wants to work, but I would personally love it if the media colorspace settings were in the project context menu, rather than inside of "interpret footage". I know I can "remember" and then "apply" the interpretation across multiple clips, but that affects more than just the colorspace settings and it feels like an antiquated way to set color on a bunch of things at once. It would be much easier if we could just select everything, right click and set colorspace from the context menu.

[moebius90009]

cool would also be an build in EXtractoR and Cryptomatte FX. Like you did for Track Matte

[Shebbe]

Secondly, it looks like the Display Colorspace of "P3-DCI" matches Nuke and Resolve's "P3-DCI D60 simulation". I don't mind that you don't also have the D65 simulation as an option, but it might be worth noting which version we're using?

By @Dan Sturm

Adobe doesn't change the configurations. The problem is they added a very old ACES 1.0.3 config when the latest OCIOv1 ACES config is ACES 1.2. DCI D60/65 is present there.

In the release version of the OCIOv2 configs with ACES 1.3 those are also available. If you want to match the Nuke 1.2 config just load that one manually, or through environment variables, or copy the config folder into the After Effects OCIO folder so it becomes an entry in the list.