AE h264 ODT vs display color space

Hello guys!
I am studying Aces because where I work we are starting sperimenting with vfx and collaborating with different department (we’re not really a vfx company).

We are thinking about creating a workflow in Aces, starting from capturing live action shoots with a sony alpha 7s, conforming and editing with (probably) AE or Davinci, vfx with nuke and last step probably again in AE (I really hope to bypass ae and use davinci but it is not a decision I can take).

Anyway, our situation is: once we have all the vfx shots done in nuke, exported as .exr with let’s say aces cg or the native slog3 sgamut3.cine we are going to import them in Ae for the grading and final touches. We know that our delivery format will be in h264 .mp4. So in Ae, set in aces, is it better to work with display color space set to srgb or rec709?
I know that h264 embed rec709 so my first thought would be to work in rec709 (even if my display is srgb) and set the output color space for the h264 in the render queue as rec709.
Does this make sense to you?

How can I be sure that the mp4 played with vlc on my pc, therefore my monitor, is 1:1 to what I see in AE?

probably it is a dumb/basic question but I’d like to know from you the best practice…

from my tests if i keep everything in srgb and export an mp4 with odt set to srgb,when I play in vlc next to ae seems to be 1:1. On the other hand if I set the odt to rec 709 this is slilght different… and this is ok. But from my knowledge you cannot put srgb inside an mp4 which will always be rec709… I am missing something for sure…

thank you guys for your time and for helping me


It’s a question I’d hoped to be basic but unforetunately has a complicated answer which isn’t related to ACES…

With the work we do at our facility we pretty much fully ignore the Rec.709 standard and grade on 2.2 sRGB 120nit calibrated monitors. In context of an ACES workflow the choice of ODT “wouldn’t matter” as long as we’d pick the same on export as chosen on viewing. But we actually don’t color manage at all and exclusively use sRGB graphics and graded footage from Resolve (graded at Rec.709 managed but displayed on 2.2 gamma) that gets combined in to non managed AE or PR. From there the export is done ‘as is’. The resulting file is always tagged as Rec.709 because there’s no control over this in AE or PR. But for web this works for us for most applications.

With that said:

I’d say this is a vaiable strategy. But perhaps others here are able to provide better practices.

We rarely need to deliver for broadcast but in those cases we do treat and manage to Rec.709 on a Rec.709 monitor.

1 Like

As mentioned by Shebbe, a point worth looking at is how the exported media is “tagged”.
There is another project part of the ASWF related to providing guidelines for media encoding that could be a great use to not just let AE decide however he wants to encode your media (I don’t know exactly the options available in AE):

This implies having to touch the command line to use ffmpeg but it is totally worth it to get a more granular control at how you media is encoded.

1 Like

Well…thank you guys for your support! you gave me a lot info to think about…
So far i’ve tested that keeping everything in sRGB and exporting a mp4 h264 from AE should give me a 1:1 video file that, by eye, match what I see inside AE.

I am gonna study your link and test as much as I can.

thank you!

(Accidently replied to Shebbe)
Regarding tags:

I always tag files as Rec709 Rec709 (1-1-1) when I do masters for youtube, because both Gamma 2.2 and sRGB tags will force youtube to alter the video during the encoding by applying some curve, not sure what exactly, but something like a difference between srgb and some gamma or something like that. Or at least this was true last time I tested it.
Gamma 2.4 tag, same as Rec709, will let the file stay as is (without any curve applied by youtube). But Rec709 tags is what you get after downloading any video from youtube.

So my logic is that: I can’t control the faulty ICC color management across different browsers, apps and operating systems, but at least if a client will upload the file to youtube, then download it and compare to the original in a video editing program or any video player, they will look the same.

1 Like

Thank you Anton!
can I ask you your workflow? I mean when in nuke or ae with aces I set my viewer in srgb since my monitor is srgb. Then when I write out the mp4 as output transfor I set srgb. If I reopen this mp4 in ae it says it’s a rec709. So I could set everything in rec709 but my monitor is still srgb so I am worried about this missmatch, I am grading something that I will see differently… hope this make sense…
thank you for your help

I’m a colorist, so I don’t use AE.
But since it’s a discussion about sRGB, displays and ODT, maybe it worth it to double check (not it specs) that your display actually has sRGB EOTF, not Gamma 2.2 (and I’m not saying that it shouldn’t be Gamma 2.2 or that Gamma 2.2 is a bad thing).
So you may probably find this thread interesting: sRGB piece-wise EOTF vs pure gamma

Maybe it will give you a better understanding of what is Rec709, sRGB, why they are different from Gamma 2.2 and 2.4. There are so many misunderstandings, wrong interpretations or just incorrect naming (even in Nuke, which has a name Color Space for by default a 1D curve in Read node), so just matching the names everywhere in all software and displays rarely gives the expected result.

And maybe this one Where exact numbers of Rec709 formula came from? And a question about P3

1 Like

thank you very much anton!
I’ll read all your links, this for sure will help me.

Thank you for your time

1 Like

Any ACES ODT has tone mapping and some other things for look (which together are called RRT - reference rendering transform, or something like that) + some encoding, that is inverse of what will the display do with the signal. Earlier it was like RRT+ODT, now it’s like RRT is a part of ODT. Not sure about that. So let’s call the look part RRT.
So, ACES sRGB ODT has RRT, that is look and tone mapping + sRGB curve. That sRGB curve is the inverse of the inverse-sRGB curve of a sRGB monitor. This sRGB curve in ODT makes the shadows darker, because inverse-sRGB curve of a monitor makes the shadows brighter. So they cancel each other out, delivering the RRT as a linear light being emitted from the display to our eyes.

But in case of ACES Rec709 ODT - it’s just a bad naming. It should be named Gamma 2.4 ODT, because its encoding part, its curve, is an inverse of gamma 2.4. And not the actual Rec709 curve (which shouldn’t be used basically anywhere and luckily it doesn’t). This ODT should be used with displays that have Gamma 2.4 curve. I call it curve, but the more correct name for this is EOTF - electro-optical transfer function.

But in reality, most of the consumer displays have pure gamma 2.2 as their EOTF. Most of them are still called sRGB and some of them has a sRGB mode, that usually use the actual inverse-sRGB EOTF. Even most of the TVs have gamma 2.2 as a default setting instead of gamma 2.4.

BUT there is NO Gamma 2.2 ODT by default in ACES. So no matter what you choose, it’s impossible to choose something completely correct. If you know how to edit OCIO file, you can get Gamma 2.2 ODT. I tried to edit OCIO v2 ACES config with no success.

Another topic is tags and ICC color management. I don’t understand, how they are intended to be assigned. We have rec709 tag. But no video file for the last maybe 15 years ever had the image, that is encoded with rec709 curve. So maybe we should tag it according to an intended display device? In this case we should tag it as gamma 2.4 (but in reality - gamma 2.2 would reflect the real world)?

And we have ICC color management, that usually works only if you are from inverse-sRGB EOTF displays club, not from Gamma 2.2 displays club. But it won’t work for sRGB club people, if the actual display has gamma 2.2, but will work for people from gamma 2.2 club. But if you decide to calibrate your display with a colorimeter and create an ICC profile, then ICC color management will always work for people from sRGB club, but never for people from gamma 2.2 club. But only for sRGB tag, at least for photos, not sure about videos. I don’t know what is going on in QuickTime player on MacOS with video files that are tagged one way or another, because I don’t use MacOS for the last maybe 7 years. But I think most people here know how exactly ICC color management works with different video tags on MacOS, so I would also love to hear more about this.

And let’s imagine that you decided to use just a ARRI LUT as you final display rendering transform (DRT). Let’s forget for now about P3 delivery. So you only have one option for all SDR displays (unless you generate different LUTs for different displays).
But here comes another thing - surround compensation. The post is becoming too long. To keep it shorter - until we get some correctly working and accepted standard in OS color management and ODTs with useable surround compensation, the safest way is to deliver just one master, no matter what display (gamma 2.2, gamma 2.4 or sRGB) this file will be played on. The difference between displays’ gamma 2.2 and 2.4 will serve as some kind of surround compensation (that also slightly shifts hues because of the gamma correction, but not that much, so we can ignore it for now). And sRGB display owners will see the shadows brighter. This is the safest option. So just choose between sRGB or Rec709 ODT by eye. I know it sounds like the worst advice, but what’s the purpose of all that if the end display will be usually a random one?

Regarding tags, as I said, I just set it to Rec709 Rec709 (1-1-1), since this is what youtube videos are tagged by youtube. But as far as I know, for example Baselight has a different default tag for Gamma 2.2 displays export, which is sRGB.

Also don’t forget to set AE composition in 32 bit (maybe 16 is ok too) and to render using trillions of colors. Otherwise it will truncate bit depth to 8 bits. I more often get 8 bit ProRes than the correct files from VFX artists who use AE or editors who use Premiere Pro and preconformed EDL workflow.

And regarding grading in AE:
For color grading you need realtime playback and the ability to quickly jump between the different playheads to compare shots. Ideally also a tool that would let you adjust colors and switch between the shots while still looking at the full screen image. So AE is not a perfect app for this task.

1 Like

Notice that the Rec.709 doesn’t define gamma curve for display device (only camera linear to scene). It’s been done later in the ITU-R BT.1886 document as a power law with a 2.4 exponent. So I guess the correct ODT name should be “BT.1886”.


Anton! thank you very much for all this information… This weekend I’ll take some time to carefully read the post and experimenting… I just scratched the surface of this topic… I’ve just got a copy of the Victor Perez’s book about the color management… I hope to get, at least, the main concept…
Thank you for your help!


The wisest thing to be done with that book would be to burn it.

Hello! Why? Is It that bad?

It is riddled with nonsense burgers, as can be evaluated from the title alone. Yes, that bad.

1 Like

Hey, if that helps, a couple of interesting links :

At the bottom of the Cinematic Color page, you may find some interesting links such as Charles Poynton´s website.


Thank you chris!
I think I have plenty of information to study on!

Really a great comunity!