Back To Listings RSS Print

Brightness Issues with H.264 QuickTime Movies

Solutions - good and bad - to a long-standing problem.

By Chris and Trish Meyer | December 02, 2008

If you haven't encountered this problem yet, you will: 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 - such as inside QuickTime Player on the Mac, or on a web page viewed by Safari - but not in other contexts such as QuickTime Player on Windows, or the stripped-down QT Player inside After Effects.

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:



The image on the left is a frame from the uncompressed source movie; the image on the right is after encoding to H.264 in QuickTime Player Pro version 7.5.5. Similar results were obtained using Apple Compressor version 3.0.4.


(Interesting side note: The problem is exaggerated by my use of a color calibrator and custom profile for my monitor; this issue seems to be confirmed by others. The default Apple Cinema Display profile makes my monitor look bright, reducing the difference between the source and rendered movies - but the artificial brightening is still there. Engaging my custom profile darkens the uncompressed source file to where it should be, while the H.264 compressed result remains too-bright as before.)

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:

Good Solutions



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.



The x264 codec contains an additional Options dialog to further customize its settings.


If you are a Mac user, in the past I have said that the easiest place to download x264 is from MacUpdate. However, I have found that they (and most other sites) have outdated versions of the codec; I found the most recent version on this obscure Japanese site, as well as SoftPedia. The updated 1.1.6 version looks like h.264 at the most basic level, but when you click on Options, you get a lot more flexibility, including presets optimized for different media types. Windows users should try the Free-Codecs.com x264 page.

x264 is not without problems. The 1.1.0 version was slow, and would 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 (1.1.6 seems much faster; I don't have enough experience yet to judge its stability). 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.

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 FuelVFX, although it requires a bit of hunting: hover your cursor over the red bar, select Software, and then click on the QTGammaStrip folder icon. Make sure you also download the ReadMe.txt file, as it includes (extremely) terse instructions on how to run it inside Terminal. And even then, I've not had much luck with it.

next: "solutions" you'll find on the web which don't work

Page 1 of 2 pages 1 2 Next »

Editor's Choice
PVC Exclusive
From our Sponsors

Share This

Back To Listings RSS Print

Get articles like this in your inbox: Sign Up

Comments

Rob: | December, 02, 2008

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?

maze: | December, 03, 2008

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).

skimmas: | December, 04, 2008

( 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).

RC Fisher: | December, 06, 2008

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

maze: | December, 06, 2008

@ 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.

Chris Meyer: | December, 07, 2008

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.

Chris Meyer: | December, 07, 2008

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

maze: | December, 07, 2008

@ 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.

Chris Meyer: | December, 08, 2008

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.

Chris Meyer: | December, 08, 2008

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.)

maze: | December, 09, 2008

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.

Chris Meyer: | December, 09, 2008

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.

maze: | December, 09, 2008

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…

Jon Chappell: | December, 15, 2008

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?

Chris Meyer: | December, 15, 2008

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….

maze: | December, 15, 2008

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.

Torley: | December, 17, 2008

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!

maze: | December, 17, 2008

@ 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?

Chris Meyer: | December, 19, 2008

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

johna2f: | June, 03, 2009

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.

Chris Meyer: | June, 03, 2009

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

johna2f: | June, 03, 2009

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.

Chris Meyer: | June, 03, 2009

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

johna2f: | June, 15, 2009

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. smile

John

Chris Meyer: | July, 07, 2009

Bad News: I think the most recent QuickTime updates on Mac broke x264. It now crashes all the time for me when I select it as a codec in the QuickTime Player Pro export dialog. It used to this occasionally in the past, but a reinstall would fix it; this time, reinstalls, permission repairs, etc. don’t help.

Good News: Elgato’s turbo.264 HD does not seem to exhibit the gamma problem.

Bad News: I can’t quite get the same quality out of the turbo.264 as I could out of x264.

Good News: Elgato is working on it. When I know more, I’ll write up a new piece.

johna2f: | July, 07, 2009

Thanks for the update Chris. What version of QT are you using now? Just so I’ll be sure to avoid it! smile

georgechemy: | July, 28, 2009

Let me convince you further with my human story: I bought Stomp because you rock voip, but because of this issue (I haven’t managed to get that other gamma tag stripper to work), I still export to H.264 from QuickTime Player Pro on Windows. Being able to do it as a batch from Stomp would accelerate my video production process greatly. Some background: I’ve made 230+ video tutorials which have nearly 4 million views ( http://secondlife.com/video ), and aside from hard numbers, they’ve made 1,000s of people happy. So by solving this so I can work quicker, your fine work on Stomp would result in even more delight! Naturally online payments, I’d be compelled to sing your praises.

jockey: | August, 07, 2009

Yes this x264 codec solves the problem in QT (you do not need to enable the Final Cut gamma correction setting), and it works in Movist, but I had no luck with Mplayer and VLC. The colors there still washed out. Any idea?

johna2f: | September, 29, 2009

Hi Chris;

I was curious if you’re on Snow Leopard yet, and whether the latest Quicktime (X), still has this issue? I haven’t been bold enough to upgrade yet, so wanted to find out if that was the case. Still using x.264 (and after you last comment, have avoided upgrading my QT).

J.

Chris Meyer: | September, 29, 2009

Hi -

I have not moved over to Snow Leopard yet, and unfortunately I am now pessimistic about this curing the problem, at least in QuickTime Player. Even though Snow Leopard is supposed to move the Mac to the same system gamma as Windows - 2.2 (vs. 1.8 for prior versions of the Mac OS) - I have heard reliable reports that “QT Player between Snow Leopard and Windows show different images, with the Mac one being appreciably lighter.” So I think there are still some issues, at least with QT Player. (This has become even more of an issue for me, because h.264 movies from my new Canon 5D mkII also show gamma shifts between QT Player and After Effects. I’d have written something about it if I had a solution…but currently, I don’t.)

In slightly better news, I had been doing some experiments with the Elgato turbo.264 HD software+hardware compression combination, and I am happy to report that at least initially, I did _not_ see any gamma shifts. OTOH, the Elgato is not optimized for the very low data rates I prefer, yielding significantly worse results than h.264/x264 at the same very low data rate targets. Elgato is aware of it, and working on it. When I have good news, I’ll share it.

good luck -
Chris

Chris Meyer: | October, 31, 2009

Just discovered the latest, greatest version of x264. Version 1.1.6 is available at http://www003.upp.so-net.ne.jp/mycometg3/ Note .that most other places (such as VersionTracker) only have 1.1.0. I have updated the main article to reflect this. The updated 1.1.6 version looks like h.264 at the most basic level, but when you click on Options, you get a lot more flexibility, including presets optimized for different media types.

johna2f: | November, 02, 2009

Thanks Chris. smile I noticed its also now called “Encoder” and not “Codec”. Will definitely give it a try. Appreciate the heads up.

jockey: | November, 02, 2009

I had this problem till this point. I mean I still still have it, but for example uploading an flv file (mov to flv with adobe media encoder) to youtube it will be correct again once it is uploaded. Strange. Before uploading it is washed out on my computer.

Terje: | April, 15, 2010

I found a solution that works for me (windows). Open the quicktime, export to targa and wav/aiff. open imagesequence and sound. Copy sound and add to image sequence. Export to quicktime H264. Takes a lot of time but for me gives a great result.

STONEY XL: | April, 21, 2010

Wow, just what I was looking for.  Funny I just went to check my displays under 10.6 and Apple shamelessly states “it is best to use the Mac Standard gamma of 2.2.”  Like the last 10 years of this problem never existed.  Had me going back and forth to the article to make sure I wasn’t going crazy thinking the standard used to be 1.8. Anywayz I just finished an edit for a music video I shot on the 1D Mark IV and was going crazy trying to figure out why my .h264s were coming out darker.  I had forgotten that long ago I had setup my Compressor custom setting to add +20 of contrast in order to get things looking right.  I’m sitting here googling “.h264s too dark,” been so long ago that I gave up on them solving the “brightness” issue.  But anywayz, cheers and thx for the links Maze and Chris. Oh and btw for me the 10.6 fix seems to work fine.  WYSIWYG from FCP 7 to QTP 7 & QT 8 to AE CS4.

jockey: | April, 21, 2010

Couple weeks/months ago I sent a message to Steve Jobs. Somebody answered and called me after I complained this unsolved issue. They tried to tell, that there is a misunderstanding in my mind as every display works differently and every software has a colour calibrating function. They did not say anything about how to solve it properly, just told me to buy a second display. Hahaha

Please login or register to comment