I have discovered that when exporting from AE to ME using H.264 my final output colours/gamma doesnt match my AE viewport.
However, if I export to DNxHD directly from AE then the colours match. What's strange is that if I then take this DNxHD and convert it (with the exact same settings) using ME, it also correctly matches!
So why the shift when going straight to ME from AE?
What are the complete color management settings you're using in Ae?
And what in Me?
Sorry, I did intend on including those. Here you go:
AE: 8 bpc, sRGB, colour management on
I don't see any setting in ME, it's just the default H.264 set to same as source. I tried a preset like Vimeo 1080p but this resulted in the same issue.
In Ae, set the project settiungs Color tab to depth of 32 bit float, and the working space to HD TV Rec.709.
That should take care of things.
Occasionally, people do need to turn off the linearize color spaces option.
Because that sets the ciomplete and proper Rec.709 color management up. Which is what you need.
Ae allows the user quite a number of choices for color managment, does nothing automagically. So if you don't set it, it don't do it.
Me, like PrPro, has a more hard-coded color management internals quite different from Ae.
That's been a tripping issue for many users over the years.
Not trying to be difficult here but this still does not explain why the exporting from AE first and then converting in ME respects the colour profile but sending it straight to ME does not.
Also this was not an issue in 2019 versions, as you can see reported by other users on the bug page for ME.
Because Me doesn't "see" the same color management as Ae. Export directly from Ae, you bake in Ae's settings. Queue to Me, it get's the way Me does things, which is different.
This is the bits in the file header here. Those bits aren't seen of course, but they do matter to the players showing the media.
So basically the link between the two is broken and it cant send colour settings over/interpret them correctly, so if your working space is sRGB then it's impossible to get an accurate render out of ME unless you first render it out of AE first?
That's a load of assumptions there. And things that might seem logical, but I've been through enough explanations of color management in-person and online to know, aren't actually associated the way many think they are. I'll leave the long technical explanations to others more versed in them.
The basic answer goes back to the old just the facts ma'am stuff:
AfterEffects allows a wide range of user-settings for color management. As many users have other needs, that is in general a "plus" for Ae.
Premiere Pro and its associated render engine MediaEncoder do not have the wide-ranging color management options of Ae. Both PrPro and Me are hardcoded based on the assumption of working in straight b-cast spec Rec.709. Using the sRGB primaries, D65 white point, gamma of 2.4 (in semi-darkened room), brightness of 100 nits on the monitor. They are starting to add some user choices, but don't have much yet.
That is just how different Ae and PrPro/Me are in color management practices.
Because of those major differences, if you do a project in Ae that will need to be processed afterwards in either Me or PrPro, you need to set the Ae project color managment to those that Me and PrPro are hard-coded to work with.
It isn't a "broken" or "buggy" situation, actaully. It's just the applications have always had different needs for color management. And there's always been a path from Ae correctly into PrPro/Me after you learn what it is.
Ok thanks for clarifying Neil.
So based on this, can I conclude that it is now technically impossible to work in sRGB in AE and then send directly to ME and have it render an H.264 which will match my viewport? The only way to do this is to export directly from AE... which you can no longer do because Adobe removed H.264. So you now have to introduce a second step of first going out to another format, and then using ME to do the conversion.
Or, as you described, changed all of your AE colour settings to match ME's..
You work within what the applications are designed to do. It's all you, as a user, can do. None of us users can make Avid or Resolve or PrPro or Ae do anything differently than how they work.
So given the above: if you're working a project in Ae, and are sending out so someone running Nuke, you set Ae up to give you the file Nuke will work with correctly. If it's going to Avid, same thing. And ... rinse & repeat, same thing for PrPro/Me.
You set your project to give you the output needed where that file is going. NOT what you perhaps "like" to work with in Ae.
My project IS set to the output I need, this isn't just what I 'like' as you put it, it's the specified requirement of my deliverable file. An sRGB H.264 mp4. So what do I do?
The full specs for most any H.264 video file would be to follow Rec.709 specs. A "simple" sRGB setting in Ae will not follow the full Rec.709 specs.
So I would posit, that for a usable video file in H.264, your settings need to be Rec.709. There is no other standard used professionally.
So if I have understood correctly, if my final delivery is H.264 and I want colour/gamma to match my viewport in AE, then they only way to achieve this is to have my working space set as Rec.709 in AE?
For a 2D animation, if my source 'footage' is all sRGB still images, and my delivery is web (Vimeo, Youtube) should I still adhere to this Rec.709 workflow as both of those platforms still require H.264.
There seems to be a lot of conflicting info online regarding this, mainly that most of the web andmost monitors are sRGB therefore you should have an sRGB working space. But if Vimeo and Youtube both require H.264 then I'm guessing this is incorrect and you should actually be working in Rec.709 still?
Thanks for your time
What I think you're missing in how you're thinking about this is the difference between "video" and essentially a "vfx plate". Both of which, in your case, share sRGB primaries for a color space.
Again ... video shares the sRGB primaries with stills, but has additional specs standards applied to it.
So when prepping for video use, you apply the full standards for Rec.709. Which still involves sRGB primaries. So for the monitors, it works within the same color space, just with additional specs applied also.
I work as a contributing author for MixingLight.com, where my "beat" is teaching pro colorists how to work in PrPro when they can't work in Resolve or Baselight for some reason. So I spend a lot of time with colorists and their issues.
A very typical thing for a colorist is to get 'plates' from the vfx specialist, that they then drop in as a replacement for the clip in the edited sequence, prior to grading it. And they typically have to apply an IDT ... input display transform ... to get that plate into the same color space as the rest of the sequence/project.
So it's quite normal to work in vfx in a different color space/standards than the video project itself. But to use the vfx output in the video project, you must get that vfx clip/comp/plate into the color space of the video project before it's usable.
But to oversimplify and put this in laymans terms; if my workflow only involves AE, and my delivery is web (YouTube/Vimeo H.264) and my source footage is all 2D sRGB assets (still images and illustrator artwork) and my one essential requirement, which doesnt seem like a lot to ask, is that my final H.264 matches colour/gamma of my AE viewport, then you're saying the only way that this is possible is if my AE working space is set to Rec.709?
Are you delivering video content?
Then, YES, it should be Rec.709 ... which is THE proper video standard. All video content other than the theatrical formats of DCI/P3, or HDR. And if it's standard video, where you're delivering does not matter.
If you're delivering still images, use whatever.
Yes, I said - Youtube/Vimeo (H.264)
So I just tested your theory, set my working space to Rec.709 and exported via ME to H.264.
But the resulting MP4 still does not match my AE viewport..
On my system, with HDTV Rec709 set in Ae, anything I see there matches on my ref monitor, when sent to PrPro, and in Me. So I wonder what setting somewhere might be off in yours?
Color management is a pain in the patootie, btw.
Tell me about, I just didnt have this issue in older versions of AE/ME (and I know other people who didnt either).
In AE do you 'use display colour management' enabled or disabled?
My system is pretty tightly calibrated to Rec.709, and then ran a profile. I don't use the display color managment option.
If say the monitor is not calibrated to Rec.709, then one should use the DCM setting option.
Blinking obvious ... um, not nearly.
I work for and with colorists daily. The amount of time & effort they put into managing color on their systems is mind-boggling for most editors. One of the more commonly used threads in colorist discussions is problems with "CM for X media, but not Y media on this sytem/app setup".
Because as noted, CM is a right royal if necessary pain in the patootie.
So after some further experimentation I have discovered the following and would appreciate your input here.
Please can you take a look at the attached workflows, you can see where the colour/gamma shift occurs. I think this makes sense, based on what you have described re sRGB vs REC709.
As you can see, if I set my working space to REC709 in AE then my viewport matches my source if I have CM ON, but if I turn this off then it matched my H.264 output. So my question is, if the only way to have accurate representation in AE's viewport of my final H.264 output is to set my working space to REC709 and turn CM OFF, do I need to convert any sRGB content prior to import, or transform/adjust this in AE to match the source?
Hopefully that all makese sense..
Just FYI. My monitor is factory calibrated sRGB and is Windows 10 is using the supplied profile for this. It is not a wide gamut display and it is locked to sRGB.