Many attribute this to a bug introduced by use of a hidden, optional “gamma” tag (which is different than a full-blown color profile tag) inside QuickTime movies that is supposed to aid in cross-platform compatibility. Unfortunately, this tag is not exposed for the user to edit, and may be interpreted differently by different programs. It has been the cause of much grief among After Effects users employing color management, and has spread into the realm of web video.
I was recently bitten by this myself when I went to encode a batch of introductory video training movies going onto the DVD for the second edition of our book After Effects Apprentice
. Everything worked fine two years ago when we did the first edition, but something has changed since then, and now the same settings produce unsatisfactory results:
After a lot of research and experimentation, I’ve found two solutions that work around this problem. I also found several “solutions” that either no longer work, or which cause other problems. Let’s start with what works:
There is a free (under the GNU General Public License) H.264 codec available known as x264. It installs quickly and painlessly into QuickTime, and appears as another codec in its list: Just choose “H.264 (x264)” instead of “H.264.” Its main screen looks identical to the normal H.264 codec, so you can use your exact same settings, but it also includes additional options that may be reached by clicking on the Options button inside the QuickTime Standard Compression Settings dialog.
x264 is not without problems. Although it claims to be faster than the standard codec, I found it slower; I suspect it was written for PPC and is running under emulation on my Intel Mac. It also will occasionally fail for me during a compression (especially when exporting multiple movies at once) with an otherwise benign, non-specific error; re-exporting works fine. But the good news is, it works - at least for me - looking fine in a variety of applications and platforms. I suspect the main difference is that it merely does not embed the dreaded gamma tag.
Thanks for the tip. I’m always trying to improve how my videos look on the web.
I’ve often had the opposite problem; uploaded videos appear much darker than on my monitor. These videos are being transcoded into Flash format using a codec unknown to me. The hosting sites I use the most is blip.tv and youtube.com. Can you cast any light on this issue?
Posted by Rob on 12/02 at 06:43 AM
I have been working with this problem for some time. Our studio uses color calibrated cinema displays; we use a 2.2 gamma on all of our monitors for a variety of reasons. I found a different solution; adjusting the gamma on output. I wrote up my findings here (much easier to link to my wordy findings than make an absurdly long comment here).
Posted by maze on 12/03 at 09:44 AM
( Partial text from: http://mograph.net/board/index.php?showtopic=17776&st=0&gopid=151609&#e;ntry151609;)
anyway the article seems to have some incorrections:
«QuickTime movies re-exported from applications such has QuickTime Player Pro using the H.264 codec (a common format for web content) appear brighter than the original in some contexts [...] but not in other contexts such as QuickTime Player on Windows, or the stripped-down QT Player inside After Effects.»
1. At least the videos encoded on windows machines will show the gamma shift on quicktime player for windows.
2 GammaStripper from FuelVFX - it as been reported not to work. Never worked for me (I’m on Windows).
Posted by skimmas on 12/04 at 02:44 AM
I had this very problem Yesterday. I thought it was a color space issue. I had recently upgraded all of my video apps, was using FCStudio 1, I didn’t experience this problem but I haven’t been working a lot with FCP in the past few months. Well so I do some quickie Dailies, w/TC burn, for some interviews I shot and I had the issue with the H264 footage. I have recently moved to shooting with a Sony EX1 so I am still refining the workflow. I will try the x264 codec and see if that fixes it.
Thanks
Robert C. Fisher
Posted by RC Fisher on 12/06 at 11:15 AM
@ Robert
I have been working with EX1 footage for a little while now. I definitely recommend throwing a gamma adjustment at your footage when you output to h.264; just use compressor to adjust it by 1.3 or 1.4 and your footage will look great. Check out the link in my previous comment for more info.
Posted by maze on 12/06 at 01:57 PM
As mentioned on page 2 of the article, I would really advise against making your render artificially darker in order to compensate for QuickTime Player making it brighter on the Mac. For one, not all players or browsers make it artificially brighter, so your darkened movie will now be too dark inside those players. For two, Apple will hopefully fix this someday (a fix is rumored for the next major OS upgrade), and at that point your darkened content may play back correctly - which will be too dark.
Posted by Chris Meyer on 12/07 at 10:09 AM
Skimmas, sorry to hear the Fuel gamma stripper does not work on Windows. I only go over to Windows to test and do no development work over there, so I did not get to test the Fuel stripper there (although I was suspicious that the instructions were the same as for Mac).
Here’s another one to try: Register at FranticVFX.com, and use this link: http://support.franticvfx.com/download/file.php?id=364
There is also discussion of it on their support forums: http://support.franticvfx.com/
Please let me know if it works.
thanks -
Chris
Posted by Chris Meyer on 12/07 at 10:17 AM
@ Chris
This is definitely a good point. But I don’t see it as ending up this way, as currently Final Cut Studio is altering the video as you can see here. Until Apple releases an update for the Final Cut Studio which gives users control over how the studio handles gamma, we are stuck with it. Besides, if I am just correcting what Final Cut is messing up, my product should look fine no matter what happens for the end viewer.
Posted by maze on 12/07 at 01:27 PM
An important point here is that FCP is not altering the video; it is altering how the video _is displayed_. By rendering with an added gamma adjustment, you are altering the pixels themselves to compensate for a display issue that pops up only in some situations.
Me, I think it’s better to “do no harm” to the underlying pixels, and tackle the display issue. Which, in the H.264 case, can be done either by stripping the gamma tag, or using an alternate codec that does not set the tag in the first place.
And to be clear, I’m talking about the H.264 case. What FCP does to footage saved with other codecs is another issue.
Posted by Chris Meyer on 12/07 at 04:50 PM
Okay - here is further proof of what I was talking about.
If you are on Mac, view the following movie - which was encoded using the normal Apple H.264 codec - under Safari, and under Firefox. It is washed out under Safari, and correct under Firefox:
http://www.provideocollective.com/videofiles/08a-3DAxisArrows_wo.mov
Now view the following movie - which was encoded using x264 - under Safari and Firefox. It is correct in both:
http://www.provideocollective.com/videofiles/08a-3DAxisArrows_x264.mov
This is why I say DON’T pre-process your video to be darker. If I did, the first movie above would have been artifically dark in Firefox.
(BTW, why was Safari too light in the first example? Because it “honors” the gamma tag, and Firefox does not. This results in the same display error as you see inside QuickTime Player.)
Posted by Chris Meyer on 12/08 at 03:45 PM
Its interesting, because I use an app called GammaSlamma for stripping gamma tags from .png files for this exact reason for use on the web - Safari renders the gamma tags and then colors won’t match with HTML/CSS coded colors.
However, here is a link to an h.264 video which has had the gamma adjusted as I was talking about. The file looks the same in Safari and Firefox: http://idcphotography.com/blog/bruce-dorn/the-5d-mark-ii-meets-u-boat-commander
Do you think that this problem is more related to QuickTime and ColorSync, or is it originating from within Final Cut Studio? Personally, my experience has led me to believe that it is QuickTime as the problem has happened for me on both Windows and OS X.
Posted by maze on 12/08 at 05:20 PM
Thanks for the links!
On my color-corrected monitor, it is indeed a bit darker in Firefox than in Safari. When I use the default Cinema Display profile (which is overly bright to my eyes), the difference is much much smaller. I believe the Apple gamma correction inside Safari is attempting to bring the movie “up to” the brightness it feels it should be at, which is why the result is more exaggerated under my custom profile which is darker than the stock Apple profile.
The problem is apparently introduced by Apple applications adding the gamma tag to the rendered QT, plus Apple applications reading the gamma tag on display. The x264 codec does not write the gamma tag; Firefox does not read the gamma tag.
Posted by Chris Meyer on 12/08 at 08:18 PM
Thanks Chris, I have enjoyed this discussion. I am also using a calibrated monitor - I have an Eye-One Pro, calibrated to 2.2 gamma, D65, 120 luminance.
With the advances that flash-encoding has made recently, I might just give up on h.264 for final output on the web unless Apple does something soon…
Posted by maze on 12/08 at 09:02 PM
Apple is planning to change the OS gamma to 2.2 in Snow Leopard to be in line with Windows PCs and TVs. Maybe Snow Leopard-created content will not have this problem, anyone know?
Posted by Jon Chappell on 12/15 at 09:14 AM
That’s the hope. And also precisely why I advocate against artificially darkening your content in the meantime.
BTW, Maze, no reason to give up on H.264 - the x264 codec has been working fine for me. If it’s good enough for Google Video, DVKitchen, etc....
Posted by Chris Meyer on 12/15 at 09:18 AM
Yes! A glimmer of hope. And if Apple finally gives up on thinking they are smarter than us on gamma, I will be very happy and my head will hurt less.
Posted by maze on 12/15 at 10:40 AM
Thanks for doing this research, I really appreciate it. This is a significant problem — it’s sadly still too awkward for me to work around, and for some reason, exporting with x264 from QuickTime on Windows still produces a movie that’s visibly lighter than exporting with H.264 from QuickTime on Mac.
I wish I could make better use of my Mac Pro, but this is quite a crimp. Also sad is when Mac software devs are blamed for this QuickTime problem.
Does anyone have fuller instructions for “QTGammaStrip”? I wasn’t able to get it to work successfully from the Terminal.
Thanks in advance!
Posted by Torley on 12/16 at 05:29 PM
@ Torley
I couldn’t get the x86 (Intel Mac) build to work correctly. The PPC build works fine.
Also, for Chris: I have been working with a lot of 5D Mark II footage, which (as far as I can tell) is RGB (More specifically sRGB) and has a 2.2 gamma tag. Final Cut documentation shows that the Final Cut assumes that you are working in a 1.8 gamma and automatically boosts the display gamma to 2.2 in the canvas and viewer (In order to approximate a TV...and show the correct 2.2 gamma). I was wondering why blacks were crushed and color was too contrasty, especially when the camera didn’t show that during capture. I realized that because my display is calibrated to 2.2, D65 Final Cut was just displaying the files incorrectly. Therefor I am color correcting to the incorrect color. This would explain all of the output wrestling I have had to do… I re-calibrated my monitor to 1.8 Gamma, D65 and now the footage looks correct in the canvas/viewer. Also, when comparing footage corrected in both calibrated settings I found the 1.8 corrected footage looked freakin’ great on a 52” HDTV when burned to DVD.
Now, I know that a broadcast monitor is the way to go since Final Cut isn’t doing anything to the footage, just how it is being displayed. Unfortunately I don’t have one. Can this be playing into how files are looking upon output, and do you think that Snow Leopard will force Final Cut developers to make some changes to the handling of gamma?
Posted by maze on 12/16 at 07:03 PM
For QTGammaStrip to run, both it and your target movie must be in your root user directory (i.e. “chris” on mine). Then run the terminal command in the instructions, replacing the movie name with the name of your movie.
That said, on my Intel Mac, it ran, but claimed it couldn’t find the “gama” tag. I ran another more destructive gamma tag stripper, and even after that I still had the brightness issue.
So, soon I am going to update this piece with what’s been learned since it was written, and probably move it over the CMG Keyframes (as that’s where our archive-worthy stuff is supposed to exist).
And yeah, previewing through a real monitor really is the best way to go for broadcast work (I was focusing on web content here).
On the one hand, I can’t wait until all apps are color managed. OTOH, color management is already a big headache; I know it will inflict a lot of pain for everyone to become educated on the subject.
Oh, well - if this was easy, everyone would be doing it. (Actually, from the looks of YouTube, everyone _is_ doing it - just not necessarily well...)
happy holidays -
Chris
Posted by Chris Meyer on 12/19 at 09:40 AM
Hi Chris;
Thanks again for posting this, and putting to rest the fact that those other solutions just don’t work!! So 2 years after you wrote this and this is still an issue. Unbelievable. Have you come across any recent solutions? My usual workflow is the following:
- I export out of AE using H.264 at best quality.
- The I open that up in QT player and re-export again using H.264 (which makes the file smaller).
I’ve even tried exporting out of AE using Animation, and then using H.264. Same result. No change. Does “Enable the Match Legacy After Effects QuickTime Gamma Adjustments option in the Project Settings.” solution work?
thanks;
J.
Posted by on 06/02 at 05:41 PM
Well, half a year after I wrote this; not two. But you won’t believe how many big sites are still posting videos with this problem. (Or, maybe you will.)
Go read Art’s extensive piece on the subject for more info:
http://provideocoalition.com/index.php/aadams/story/quicktime/
The legacy gamma switch when rendering from AE won’t help, as you change it to another codec (h.264) later.
I am trying to get an Elgato turbo.264 to see if it behaves any better; I’ll post when I know more (http://www.elgato.com/elgato/na/mainmenu/products/Turbo264HD/product1.en.html)
fingers crossed -
Chris
Posted by Chris Meyer on 06/02 at 07:18 PM
Thanks Chris. Will definitely try x264 tonight and see if that solves the dilemma. So I’m assuming the correct process is exporting out of AE using Animation, and then compressing to H.264 from QT pro using x264, right? Hope this works. At least it will be a viable solution for now. Definitely let us know how Elgato works out.
J.
Posted by on 06/02 at 07:37 PM
QuickTime Animation out of AE, to x264 in QuickTime Player Pro - that’s my workflow. (But also read Art’s piece, including the follow-up http://provideocoalition.com/index.php/aadams/story/the_quicktime_conundrum_solved_by_our_readers/)
Every now and then x264 returns an error; manually removing the codec from the QuickTime folder and re-installing it fixes it.
good luck -
Chris
Posted by Chris Meyer on 06/02 at 07:46 PM
Hi Chris;
Been using x264 for a few weeks now. Man, what a lifesaver!!! My renders are finally looking the way they should. Thanks again for opening my eyes to this. 
John
Posted by on 06/15 at 09:20 AM
Speaking of the dreaded gamma tag, if you already have a bunch of already-encoded, problematic content, you can occasionally find QuickTime gamma tag strippers out there. Fellow PVC writer Mark Christiansen turned me onto one available from 
