HDTV (Rec. 709) vs Rec.709 Gamma 2.4 - Video Output
I'm experiencing a very confusing issue with color working space and output. I don't know if it's intended, a bug, or I'm misunderstanding something.
The best part is... if I set the OUTPUT color profile to Rec.709 gamma 2.4 it perfectly matches the project working space of HDTV (Rec.709)
But If I set the color space of the Project to Rec.709 2.4 and not HDTV (Rec.709) the test chart looks off.
I know ProRes has a history of horrible gamma issues with interpretation in applications, but the fact that I need to set a different output color profile to match the project working color space has me spooked.
Am I misunderstanding something? DNxHD has the same problem from what I can tell. We need to render to a video format so postings can be sent without re-compiling an image sequence (that doesn't have this problem for some reason).
Any insight is greatly appreciated.
The problem with outputting using a 2.4 gamma "709" profile is that Rec709 is not, and has never been, a source-referred signal of gamma 2.4. The 2.4 gamma is a display profile not an encoding profile.
The SOURCE REFERRED (i.e. camera) gamma is a parametric curve that is roughly the inverse gamma of 1.9-2.0 (i.e 1/2.0 for a curve of 0.5).
This is intended to play through a display that has a gamma higher than 2.0, although the actual display specs are NOT part of the Rec709 specification. When Rec709 was originally developed (circa 1990) playback was through CRT displays which tend to have an output gamma of 2.2-2.4 or so, depending on how the contrast and brightness is set.
This results in a total system gamma of around 1.2, and NOT a purely linear 1.0 in-to-out transfer. This is done to preserve the perception of the scene's contrast while viewing in a darkened living room. It wasn't until a few years ago that the ITU finally defined a standard for viewing (rec1886) that defines a display monitor with a gamma of 2.4, and Rec2035 which defines the viewing conditions of said darkened living room. (and just a few years before that, EBU tech3325 stated it should be gamma 2.28).
But the Rec709 SIGNAL spec (i.e. the way it is encoded in the output file) has NOT CHANGED - it is still a parametric curve with a gamma close to 1/2.0 — this means it is wrong to encode it with a 1/2.4 (0.42) gamma. It should still be encoded with a ~0.5 curve.
PROFILE ISSUES and 16-235 LEVELS:
There are two other things that may be tripping you up here. First of all, there are a lot of Rec709 profile floating around out there, and they are not consistent, some are "simplified", and some are just wrong. This includes profiles that ship with Adobe products.
But also: black and white levels are NOT 0 and 255. The Rec709 spec defines that Black is 16 and white is 235 for 8 bit, and 64/940 for 10 bit. NTSC (Rec601) was the same way. But After Effects usually works with black at 0 and white at 255 (or 0.0 and 1.0 in 32 bit), this is known as "full range". On output, black is supposed to be mapped to 16 for 8 bit or 64 for 10 bit "video" files. While in the spec, black is allowed to go lower than 16 (super black) and white higher than 235 (superwhite). But as far as the specification is concerned, 16 should be the darkest color on the monitor, and 235 should be the brightest.
You'll notice in AE when you bring in ProRes 422 footage, you can't even change the color interpretation:
And it's technically not an "embedded" profile — it's a "calibrated" profile, that is, it's a "standard" set by the ITU, and AE is "interpreting" it. And despite having the "interpretationRules.txt" file, YUV / Y'CbCr type files don't allow you to choose the INPUT colorspace in AE.
Legal Video Levels:Even the Arri Alexa when shooting in LogC mode aims for the legal levels. The reason the numbers don't indicate a black at 16 inside After Effects is that AE maps 16 to 0 if you setup your workspace inside AE as a 0-255 space.
So in essence AE "hides" the true levels being input/output from the system. And unfortunately their use of terminology and the way the dialogs are set up makes it all the more confusing.
COLOR MANAGED vs COLOR CALIBRATED WORKFLOWS
What is important is to MONITOR your workspace with a 2.4 display emulation, I'll discuss this later under "workflow", but it is important to remember that normally playback is not "color managed" it is "color calibrated", which is quite different in meaning.
Remember that color TV and film were around a long time before ICC color management. Those workflows managed (and still do today) because the camera, display, and the broadcast chain in between are all calibrated to a set standard of color and transfer curves, etc.
ICC color management is very different — the idea is to convert the digital color values of image data from one color space, then into an intermediate "connection" colorspace (usually CIEXYZ) that is neutral, and then converting it to the other space. There's a ton of math to make that happen which is why AE slows down so much when color management is on), it's more efficient to just have everything calibrated, as it is in a broadcast chain.
One advantage of color management is the ability to emulate different forms of output using Display Color Management, where your calibrated and properly profiled monitor can display different view conditions, such as Rec1886, while working in a completely different space like 32 bit Linear Gamma (1.0) and P3 primaries.
Side note: if you are using Display Color Management, checking/unchecking "Compensate for Scene Referred Profiles" will cause a Rec709 clip to appear visibly lighter/darker — but it does not change the RGB values.
Which brings us back to profiles. The 2.4 gamma Rec709 profile is a VIEWING profile, useable for proofing or emulating an output monitor. It is for display only, it is not a profile to be used for encoding the TRC into your output (unless you specifically want to "bake in" that crunched look).
An example workflow is (using a Linear gamma 1.0 workflow with a Rec709 output target).
1) Set the project colorspace to 32 bit Linear, and an unbounded sRGB or Rec709 profile (sRGB and Rec709 have identical primaries and whitepoint). Turn ON "Compensate for Scene Referred Profiles".
I recommend Elle's "Well Behaved" V4 profiles, downloadable here: https://github.com/ellelstone/elles_icc_profiles/tree/master/profiles I've found these to be the most accurate of profiles, with true Rec709 TRCs.Setting for workspace:
2) Setup a custom Display Simulation, using Rec709-elle-V4-rec709.iccas the first output stage, set "Preserve RGB" so that the display profile (a Rec1886 aka a Rec709 @2.4 gamma) takes this data and then displays it the way a 2.4 gamma monitor would.
Setting for simulation:
3) Now do all your work — when you output, you output to the Rec709-elle-V4-rec709.icc profile, which put on the standard Rec709 TRC, but it will look the way you were working on it when you send it through a 2.4 gamma reference monitor. Essentially, once you output the video, color management is over. Downstream it is being played back in non-managed (but hopefully calibrated) displays.
This ended up a bit longer than I intended, but I hope it was helpful. This very question/problem comes up about every two weeks, partly I think because Adobe isn't doing a very good job explaining how to use their color management. Adobe still has tutorials online suggesting using ProPhoto as a working space for film and video, which is a terrible space to use — it uses a D50 Illuminant, while Most film and video is based (or very close) on D65, and ProPhoto is way too big and creates negative color values and imaginary colors that can wrap around and result in bad values in DPX outputs and other unpredictable garbage.
VFX & Title Supervisor
Wow! That's not a post, that's a reference work! Thanks.
KGAN (CBS) & KFXA (Fox) Cedar Rapids, IA
Long time lurker...
A fantastic post indeed. In fact it's one of the best on colour in After Effects, but I'm still unclear and I've been smashing away at this subject for a while now. My situation is extremely similar to the above, hence the following addition; though my main concern is consistency across multiple generations of post work:
I work primarily with CG image sequences. I have a 32bit linear project, with an sRGB working space. A single sequence of linear openEXRs resides on my only timeline. I make corrections, I create a master video (DNX RGB 444).
Q1. Upon export, the output profile defaults to my sRGB working space. Why does the same file import with profile Rec.709 Gamma 2.4?
I can return the clip to its original perceptual state in AE by either changing the interpreted profile, or by using the Change Colour Profile effect, but is there a reason why the profile is being changed for me? Is it a deliberate correction, or an error?
Q2. What should I expect to see from the same DnX 444 clip on the same workstation inside Adobe Premiere? What about if an export (again DnX 444) from Premiere made its way back to AE?
Q3. On other flavours of DnX, why is it again that the input profiles of such flavours aren't adjustable? Is it as this page of the Adobe forums suggests?
It's funny, colour. Two Charles Poynton courses later and I understand less about After Effects than I did when I started. 😉
Massive thanks to any readers.
Hi Nick, thank you, lemme address your questions:
NICK ASKED: Q1. Upon export, the output profile defaults to my sRGB working space. Why does the same file import with profile Rec.709 Gamma 2.4?
Before I answer first let me mention that:
1) sRGB and Rec709 are THE SAME except for the gamma (transfer curve). sRGB and Rec709 have the same chromacity, meaning the same color primaries and the same white point.
2) Video is not "color managed" in Quicktime, though sometimes there is a tag relating to a gamma curve.Video is not color managed outside of the AE application, you can't embed a profile in a Quicktime for instance. "Color Management" means that you use an ICC color profile to convert from one color space, into another colorspace, using either an intermediate "connection" color space (usually CIE XYZ), or a "device link" profile. With "video", you encode using a set of specifications with the intent to play via a display that is calibrated to a related set of specifications. This is a "calibrated color workflow" not a "color managed workflow".
3) When you output from After Effects, the output color profile you used is NOT, repeat NOT associated with the Quicktime file. What AE puts into the Quicktime headers (called ATOMs) is based on the codec, resolution, and file type, and may or may not include a tag for a specific gamma. But not your method of output. If you want to see what the Atoms are, you can download the free AtomInspector.app from apple.
4) Now to answer YOUR question: Files are imported based on the "Interpretation Rules.txt" file, found in ~/Library/Preferences/Adobe/After Effects (and there is also the file "AE_MediaCoreQTCodecRulesCS6.xml" which is in application support that deals partly with how video is tagged on output).
In Interpretation Rules you can tell AE how a particular file type is to be imported and what profile to interpret it as, for RGB type files (DNX 444 should be settable here).
When it comes to Y'CbCr type video files (like ProRes 422) things are less flexible, as this kind of file "apparently" can't be handled directly by the Adobe CMM and ICC profiles, so AE has a separate way to handle these, and it is much less flexible than the Interpretation Rules file, it's the "AE_MediaCoreQTCodecRulesCS6.xml" for AE and the "MediaCoreQTCodecRulesCS6.xml" for AME and Premier. Both files are located in the ~/Library/ApplicationSupport/Adobe/Common — there is very little documentation on this file unfortunately, and it seems to have no control on clor SPACES, just color ENCODING.
••• So to answer your questions the long way around: The file is output without "relevant" colorspace information if you are outputting to Quicktime, and it is IMPORTED based on the interpretation rules file. If you are doing DNX 444, then you should be able to set your Interpretation Rules to use the profile you want on import.
NICK ASKED: Q2. What should I expect to see from the same DnX 444 clip on the same workstation inside Adobe Premiere? What about if an export (again DnX 444) from Premiere made its way back to AE?
There are no "interpretation rules" for PP or AME as far as I know, their interpretations all happen in the "MediaCoreQTCodecRulesCS6.xml" file.
NICK ASKED: Q3. On other flavours of DnX, why is it again that the input profiles of such flavours aren't adjustable? Is it as this page of the Adobe forums suggests?So this is all about the difference between RGB and Y'CbCr/Yuv etc.
As I mentioned above, Y'CbCr color encoding cannot use the regular color management engine. It's important to remember that Y'CbCr is not a colorspace, it is a color encoding type, and it is used mainly to reduce the amount of data in a file.
ICC based color management is all about converting from one color space or gamut to a different space or gamut. While I am not an engineer for Adobe, I am guessing that they are not able to use the regular ICC profile based CMM for Y'CbCr encodings, and had to write separate code for this file type. 422 video is not only Y'CbCr but the color data is ALSO down sampled so the color information is at a lower resolution than the luminance. I don't believe this is not something that ICC color management is designed to deal with — and actually I don't think you'd want to. IMO ICC based color management is actually a BAD FIT for working with film and video. I no longer use color management in the output modules, leaving them to "Preserve RGB" and then using LUTs such as those from OpencolorIO on the output comp to get into the delivery container.
BUT FOR YOU: Get into the Interpretation Rules.txt file and set the rules you need for you DNx 444 files.
VFX & Title Supervisor
Thanks for the answers.
A big thing for me is the importance of AE's footage interpretation rules (Q: "Why is it doing that?" A: Because you've not configured it to do differently."). The exposing of AE config in a somewhat raw form led me to believe that it wasn't for adjustment by monkeys (me), when even its existence explains that AE isn't stating "THIS is de facto how things are", it's only working to rules that are a user's responsibility to set.
Another big take away was that there is nothing preserved in the Quicktime file regards colour profile. This was admittedly something of an assumption ("Output profile" at first inspection feels like metadata). So the output profile is actually a final burnt in transform that occurs upon render, is this right? In the case of 2.2/ 2.4 gamma, you could use the output module to adjust the gamma for 'typical' HDTV/ sRGB targets?
Overall, the big struggle for me has been keeping a handle on the actual coded values that are committed to computer memory at every step in the journey from (for me) render to delivery, and separating them from any on the fly operations applied by software and display. It's becoming clearer as I continue to hammer away, but's proving to be one heck of a journey which more often than not leaves me feeling like a total child.
Actually, having thought further about the second paragraph, while the general principle may be correct (final adjustment to coded values before committing to disk), I'm not sure that my example of 2.2/2.4 is at all correct.
Another (another) area that I'm currently trying to separate out is encoding vs display, and I think I might be confusing the two. I fact, isn't it that the two exponents assume the same footage coming in, only adjusting at the display for different viewing environments?
Sorry if I'm starting to veer off topic. My original aim appeared very similar to this thread's creator; though I may now be deviating a little.
I think you had the right idea in paragraph two.
Nick Asked Another (another) area that I'm currently trying to separate out is encoding vs display, and I think I might be confusing the two. I fact, isn't it that the two exponents assume the same footage coming in, only adjusting at the display for different viewing environments?
Not sure I understand your question.
Think of Display Color Management the same as "Proof Colors" in Photoshop.
As to your display:
1) Unless your monitor has internal LUTs, you "calibrate it" using the display's contrast and color sliders, while using an Xrite i1 Display Pro and appropriate software. Let's assume your calibration target is sRGB. If it is calibrated perfectly this means that linear data from the graphics card is displayed with an sRGB monitor gamma (approx 2.2).
2) In ADDITION to calibrating, you also create a system display profile for this monitor (again using the i1 Display Pro). This profile tells the system how to send a particular color to your display. If your display is perfectly calibrates, then the transfer curve in the profile is a straight line. But more commonly it will be curved a bit to correct for deltaE errors in the calibration.
3) Now in Display Color Management, AE will convert the workspace to the display space by setting the signal gamma as:
So if the workspace gamma is linear (1.0) and the monitor is gamma 2.2, then that's 1/2.2 i.e. 0.4545
4) If you "simulate output", then in addition to applying the 0.4545 curve, an additional curve adjustment is added to emulate a device that is different that your display. If your display were calibrated to "HDTV", and you selected the "HDTV" simulation, you would see no difference with simulation on or off.
None of this display stuff has any bearing on the output encoding. this is just how the workspace gets presented to the graphics card and monitor. Your output encoding is determined by the codec and output module. settings.
VFX & Title Supervisor
Nick Said: "Why is it doing that?" A: ...........THIS is de facto how things are", it's only working to rules that are a user's responsibility to set.
Yes, but unfortunately, Adobe does NOT choose the "correct" way to do things for all workflow or environments. I've been burned by Adobe's idea of how something should be transformed in colorspace more than once, and it's led me to a workflow that does not "rely" on what Adobe thinks or wants be to adhere to.
Even some of the ICC profiles that Adobe ships with AE are technically wrong, or labeled in a way that leads to confusion. And woe betide anyone that actually follows some of Adobe's documentation on color management as it is rife with "doing things the wrong way", at least for feature film and TV work in a Hollywood workflow.
Nick Said: So the output profile is actually a final burnt in transform that occurs upon render, is this right? In the case of 2.2/ 2.4 gamma, you could use the output module to adjust the gamma for 'typical' HDTV/ sRGB targets?
Yes, if you are using color management in the output profile, it will perform a final transform based on the output profile selected. But a common error is using the wrong output profile. For instance, Rec709 defines a signal gamma that refers to the source (i.e. camera) and this is the profile that should be used for output. Rec 1886 defines the monitor/display value, which is different than Rec709 — but the monitor defined in 1886 EXPECTS to see video that is USING the Rec709 curve. So if you choose the 1886 curve as an output profile (sometimes called the Rec709 Display or Rec709 2.4 gamma) THIS IS WRONG.
The AE Output Module behaves relative to the current Working Space. If your working space is elle_v4_sRGB, 8 bit, and not linear, and you output to an 8 bit video container using the t=same profile as the working space profile, the output will have the same RGB values — and in fact the RGB values will be the same if you select "Preserve RGB" in this one instance.
But instead, to take advantage of the best that AE has to offer, we more typically want to working in a linearized workspace, and this means we have to have some way to accurately display what we are working on. Most of the time this means using color management via "Display Color Management".
But this ALSO means that you need to plan your workflow, including choosing Interpretation Rules, working chromacities, and output transforms. Adobe's implementation of linearized working space is half-baked, with badly written documentation, misleading dialogs or labels in the UI, and inconsistent results depending on a few factors.
For instance, in linearized mode:
Nick Said: Overall, the big struggle for me has been keeping a handle on the actual coded values that are committed to computer memory at every step in the journey from (for me) render to delivery, and separating them from any on the fly operations applied by software and display. It's becoming clearer as I continue to hammer away, but's proving to be one heck of a journey
Pretty much every film/TV oriented system uses LUTs for color conversions. After Effects seems unique in using ICC based color management for this task. Having climbed this leaning curve and gone way farther down the rabbit hole than I ever intended, I'm going to say that the ICC CMM workflow is not the best idea for film/TV work. ICC based color management emerged from the need to convert display RGB values to print CMYK values — but the needs of film/TV are very different.
I have an advantage in that I started with AE before it ever used "color management", and to work in a linearized space I used Stu's eLin setup they developed at The Orphanage. By moving all the transforms to adjustment layers in comps (which is what eLin does), you'll gain a much better understanding of what is going on behind the scenes in the AE color engine.
Alternately, download the free version of Nuke, and play around with LUTs in there. I think that could really help understanding whats going on. For that matter, download the OpenColorIO plug-ins for AE, and try using them instead of AE color management.
VFX & Title Supervisor
[Andrew Somers] "I think you had the right idea in paragraph two."
My confusing comment was largely a muddled take on your explanation that using the 2.4 curve in the output module is incorrect, given that the expectation of BT.1886 is a BT.709 transfer function. In fact, there is something fundamental about the relationship between gamma compression and subsequent expansion that I'm still trying to grasp. Is it that both BT.1886 and sRGB expect the same gamma encoding, but overcompensate to varying degrees due to different viewing conditions? Both curves "bend" the compressed values back out, but slightly past their original scene linear state?
[Andrew Somers]... rabbit hole ...
Correct, but it's surprising how fascinating the journey has become the further down I've fallen. It also strikes me that, for something as important as controlling the exhibition of colours should be so easy to ignore/ misunderstand/ etc. I don't think many would first pick up AE thinking "Gamma, what fun...", compared with those who are enticed by top-line motion graphics wizardry; though as time passes it becomes increasingly apparent that the former is required at the bottom to support everything 'wizardry' further up.
Finally, and only for clarity (on the off chance that someone other than me finds this thread useful):
[Me] "Overall, the big struggle for me has been keeping a handle on the actual coded values that are committed to computer memory at every step in the journey from (for me) initial 3D render to delivery... "
It's was the journey from acquisition to delivery to which I was referring, not only the final output transform (...as if the last bit wasn't confusing enough!).
All in all, huge thanks again.
One for the road...
For the sake of my sanity I'll note that I've hopefully found the answer to my remaining confusion.
The problem I was having was a lack of clarity regards BT.709 and sRGB with regard to OETF vs EOTF. I read a lot about sRGB vs BT.1886 and a lot about BT.709 vs BT.1886. What I couldn't grasp is that, with the gamma compression defined in BT.709 and the subsequant expansion standardized in BT.1886, what on earth is sRGB expanding? Well, is it that both opto-electrical and electro-optical transfer functions are in the sRGB spec!? Hopefully it's that obvious, but for me it's really the missing piece of the puzzle.
A couple of articles that I found interesting along the way:
I'll bog off now. Thanks Andrew for the time taken to put such great responses together.
Hi Nick, yes it is that obvious regarding sRGB: both the ENCODE and DECODE/DISPLAY characteristics are defined in the spec, while Rec709 only defines encoding (written circa 1990) and display wasn't officially defined until Rec1886 in 2011, over 20 years later (!!)
As for the difference in encoding:
The sRGB gamma results in a brighter image assuming the monitor is adjusted the same — and therein lies part of the problem. Monitors have ADJUSTABLE GAMMA, it is the control usually called "brightness" (the control usually called "contrast" adjusts the white level).
The other thing that sRGB defines is that BLACK is at 0 and WHTIE is at 255, as opposed to 16/235 as in Rec709.
Rec709 is a bit unique in that it only defines the encoding spec. sRGB is a derived from Rec709, but the developers wanted to define the viewing conditions and characteristics both because computers are used in brighter office environments (as opposed to a dark living room) and also because of the legacy of existing computer files (jpeg etc) that were all roughly at a 1/2.2 gamma.
Put another way, sRGB is "Display Referred" while Rec709 is "Source Referred" (note that I will no longer call Rec709 "scene" referred, as it's not scene referred the way that an EXR is, for instance. I think it is more appropriate to call Rec709 "source" referred or "camera" referred).
And yes, this is a very abstract and confusing subject. It took me a long time to really get a handle on it. Not helping of course is that it's hard to describe in words, plus Adobe has done a very poor job with documentation, a poor job labeling controls and workflow, a poor job including useful ICC profiles... etc.
VFX & Title Supervisor
Hey Nick, to add, I just ran across this info graphic that (hopefully) should make the Rec709/Rec1886 issue very clear:
VFX & Title Supervisor
Good lord I have to save this post in my tech book 😉