I'm obsessive about observing patterns, and even moreso when not enough is being done to connect the dots and put the pieces together. This includes computer bugs, especially those which don't seem to be very troublesome on the surface, but infact have painful, entrenched roots that dig into you, causing much agony — like The Ruins.
The QuickTime H.264 gamma shift bug is one of those issues.
Here's what I've gathered so far:
- It can make movies exported via H.264 (an overall excellent codec) look unwantedly lighter.
- It's been a problem (or at least noticed) for over 2 years, since 2005.
- Numerous workarounds have been prescribed, but most are kludgy and unreliable.
- Ironically, it only affects Mac movies. Exporting QuickTime on Windows doesn't exhibit this.
- Apple has yet to fix it as of QT 7.5.5. There exists no elegant fix for it… yet.
I've heard of this bug for awhile, but it didn't affect my workflow until I got a Mac Pro. Recap of my setup: I edit video in Sony Vegas on Windows, then export it to a QuickTime-compatible format. I was hoping the Mac would speed up things, but saidgamma shift has been quite frustrating.
Additional observations:
- It affects QuickTime (QuickTime Player's File menu > Export), Compressor (included with Final Cut), After Effects (according to this), Stomp, and other apps which use QuickTime for encoding.
- It doesn't appear in all situations. E.g., if you play the movie files in Windows, they appear with the same gamma. But if you play them in Mac Firefox or Safari, they don't. I tried Mac VLC and they have the same gamma, albeit both are lighter.
- It doesn't affect all source codecs.
- It affects uploaded videos. Which means by then, it gets hardcoded.
More details about the last 2 points: Photo-JPEG seems fine, whereas Animation is not. This is based on comparing my Mac encodes to encodes done solely on PC before. Some've reported otherwise, but I tested this by exporting from Sony Vegas into those codecs, then bringing the separate files to the Mac side and exporting them to the same destination MP4 settings. I use the non-containered "Movie to MPEG-4" instead of "Movie to QuickTime Movie". Vegas has its own, broken MP4 implementation — they didn't license Apple's so I use this intermediary method to get better overall quality.
As a demonstration, here's clips I uploaded to Vimeo. The first comes from Photo-JPEG (looks right), and the second is Animation (too light):
It may be subtle, but nevertheless notable. Animation codec can be lossless, but also results in much bigger filesizes. I'd rather have some minimal lossiness to get correct gamma on my way to the web. Here's another side-by-side view. Again, the Photo-JPEG version (and its stats) are on the left, clickthrough for fullsize:
And this shows they both look the same in Windows:
Note they are both lighter than on Mac. This is because I've deliberately set my Mac to a lower gamma because I like the dramatic-looking curve, which is the opposite of how it's usually done, since PCs are 2.2 and Macs are 1.8. I may adjust this further to taste soon, but color correction nitpicking aside, the point is: they look the same.
Related resources
I've been intently tracking updates and compiling progress related to this problem, as numerous people have noticed it but aren't sure what to call it other than "movies look too light/bright" — so "gamma shift" will do.
- Brightness Issues with H.264 QuickTime Movies – The best article I've found so far. Debunks some of the common myths, mentions a hidden tag is what's causing this. I tried the tag stripper and it didn't work. Then I mentioned it to Neil, who made Stomp.
- Fix QuickTime Gamma Shift – From the usually-golden Video CoPilot. This didn't work for me at all. The previous article recommends not doing this.
- QuickTime 7: H.264 Export Issues – From MacInTouch. Some of the earliest mentions of this problem.
Needless to say, there are numerous more threads and pages which echo the above. I'm thankful to have a separate PC box. If you don't, exporting from Windows QuickTime, even virtualized or Boot Camp, isn't an effective solution since it's so inconvenient and slower. H.264 can be a hog to encode, even on the fastest Mac Pros, and the accelerated solutions I've seen so far have been dismal. But I don't give up hope that Apple will fix this. It's surprising because it's such a major problem for video professionals, a core Mac userbase.
What I'm going to do next: continue experimenting. It seems Vegas -> Photo-JPEG .mov -> Mac QuickTime H.264 .mp4 is viable as I've mentioned, but I'll need to test this further.
If you have useful info to add, shout it out in the comments!
{ 16 comments… read them below or add one }
This may well be due to your color calibration. The mac calibrates everything you see on every screen, and if it includes embedded profiles it'll take those into account.
Windows vista ONLY calibrates photo images, and any calibration of other stuff is done on a per-application basis. From what I gather it can't use different profiles for multiple attatched monitors either. So on a dual monitor setup under vists it's quite possible to be looking at 5 different colorspaces in different windows while you are working on a project… and as I did before switching back to Mac, go completely insane!!!! muhahaha!
So it is possible that what you are seeing is correct behavior: ie. if you ajust gamma on the mac to darken you're telling the color system your monitor is too bright in the midtones. If you then export and that gamma metadata is anywhere in the exported file, then the mac will dutifuly ajust the colors to the "correct" value. As the crazy gamma is contained in the metadata any platform that pays attention to it will display it bright, and any that ignore it will display it as you saw on screen.
I may be misunderstanding your workflow here, but it is highly likely that something similar to this is going on due to the different ways that colorspaces are handled by mac OS, windows OS *shivers*, and any of the pro apps you're using to mess with your video (which likely bypass windows color management completely.
You may be able to sort it out by ensuring everything is set to sRGB colorspace across both platforms, but I'd keep researching before trusting my judgement.
Aha! Just read a bit and yups it's metadata. Oh well, good luck sorting it out
I don't know if any of this will help but…
I've started using Vimeo for a client this past year. I use byteful.com's recommendations for Quicktime export settings (on my Mac) for use when uploading .mp4 to Vimeo. These are the settings I've used to export movies from iMovie and to export from QuicktimePro (Mac) – I haven't experienced any washed-out .mp4 movies.
http://byteful.com/blog/2008/01/how-to-encode-video-for-a-podcast/#settings
Byteful Video Settings
- In the “Video” tab -
Video Format: h.264 (most efficient video codec for the web)
Data Rate: 1500 Kbps, Optimized for Download
Image size: 640×360 for widescreen, 640×480 for fullscreen
Frame rate: Current
Key frame: automatic (best to choose auto with h.264, it’s very smart)
• Click the Video options button and choose:
Encoding Mode: Best Quality (multi-pass) (which looks much better)
Restrict profiles to: Baseline (which makes it compatible with all iPods, as long as you’re using 1500kbps data rate and not much higher)
• Click “OK”
- In the “Audio” tab -
Audio Format: AAC-LC (music)
Data Rate: 128kbps (can be set it lower if there is no music)
Channels: Stereo
Output Sample Rate: 44.100khz
Encoding quality: Best
- In the “Streaming” tab -
• Check “Enable Streaming” and leave the numbers as they are (this allows your movie to download as it’s playing. this is also known as “hinting.” go figure.)
Here's another interesting article on byteful.com about the gamma issue:
http://byteful.com/blog/2008/07/how-to-fix-washed-out-h264-video/
Note: I have the "Perian" plug-in for Quicktime installed, I've always used it with Quicktime. I've read that some ppl are recommending this plug-in as a fix for the gamma issue. I've always had Perian so I'm not sure if this is why I have not experienced the gamma issue myself. Perian enables Quicktime application support for additional media types and is a free, open source Quicktime component.
http://perian.org/#detail
Ok, I just read the byteful.com articles referenced above and saw that you (Torley) had already left comments on those articles – but I'll leave them in my post for other's reference.
Perhaps it is Perian that is keeping me from having this issue?
I have my Mac monitor calibrated to 2.2 gamma using Moncao if that is relevant
@Pavig: Ah yes, I think I've seen that explained in some of these places I looked. I still consider it a bug due to un-expectedness and inconsistency across codecs.
@Sahoni: I've posted in a number of places. Thanx for your research! I have Perian installed too, mainly for playback of different media types.
Part of the continuing mystery for me is why Photo-JPEG -> H.264 .MP4 works fine, but Animation -> H.264 .MP4 doesn't.
I've finally replicated the bug when exporting to .mov using Quicktime (Mac). I've always exported to .mp4 file format so that's why I've never seen this bug before
As I am new to video creation… is there an advantage to using the .mov file format instead of .mp4? Especially since they are being uploaded to Vimeo anyway? The .mp4 files sizes appear to be much smaller than .mov. I am tying to understand your methodology to make my own workflow more awesome!
Mahalo!
I am using After Effects, and I found that using the hd709 color profile fixes the color shift. It also seems to decrease file size even more, not sure why. With and without the color shift vids uploaded to flickr…
http://flickr.com/photos/philfoss/tags/h264/
@Sahoni: I haven't found a strong advantage in my usage for using .MOV. From what I understand, that wraps whatever codec you choose in a container which may be more flexible for editing within QuickTime Player.
This may be woefully uninformed, but http://en.wikipedia.org/wiki/QuickTime#QuickTime_file_format seems to support that. Now, it's important to be cross-platform, be able to upload to the web, etc.
@Phil: I'll have a look, thanks for chiming in!
Well I thought I'd chime in with my decent fix… I'm using Premiere Pro CS3 (on XP) and I found the easiest and quickest way to fix the gamma issue is to go to Image Control > Gamma Correction, and then add that to your clip. Then change the default setting of '10' to '15'. Then when you export as h.264 the washout seems to be pretty much gone. You can experiment with this for a better setting but for a quick fix, its good.
@Chris B: I don't use Premiere but thanks for sharing. Am curious to hear what other Premiere users think of that?
Mine is fluctuating. Mine worked without having the Match Legacy Gamma Adjustment on and then off then on. I did something which seemed to overwrite a setting and reset something. Not sure.
Try this.
In project settings, Turn on the Blend Colors Using 1.0 Gamma.
Render something in the render que. My video suddenly got darker and the results were darker than normal.
I went back, checked it off, re-rendered it, and it worked out perfectly.
Hello again, Torley.
I saw your site as a recent referrer, and I thought I'd stop by and follow up on your progress. Have you settled on a method that works best for you? I'm so glad you've collected many different solutions here, and I'm wondering which one seems to work the best.
Thanks again.
@Byteful: Thanks for following up! I haven't found a better solution which is consistent and without caveats. It's weird because I *just* went from Photo-JPEG -> H.264 MPEG-4 on my Mac yesterday, but it was lighter, despite my earlier experiments working as described above.
Argh.
So, I continue to encode QuickTime H.264 via my Windows PC. Wish I could use my Mac Pro (Mac OS X, not Boot Camp of course) for this.
Brightness problem on export from Final Cut to Quick Time
I and my friends have always had this problem- the video looks great in the Canvass but when it is exported to Quick Time it looks washed out. I just stumbled upon this support article http://support.apple.com/kb/HT2912 . It says
Tip: While it is possible to recalibrate Apple displays via the Display Calibrator Assistant in Displays preferences, users should leave the gamma of their monitors to the 1.8 Standard Gamma setting when working in Final Cut Pro. ColorSync settings are not used by either Shake or Final Cut Pro for automatic color calibration or compensation of any kind.
QuickTime Movies Issue
When importing a QuickTime movie created with Shake into Final Cut Pro, users may notice a difference in the displayed gamma of the image. This is because Final Cut Pro automatically lowers the gamma of sequences playing in the Canvas on your computer's display. The gamma of QuickTime images remains untouched when the sequence is output to video or rendered as a QuickTime movie.
What causes this?
Final Cut Pro assumes that all RGB image files are created with a gamma of 1.8. When RGB image files are imported into Final Cut Pro and edited into a sequence set to 8- or 10-bit YUV rendering, the gamma is automatically boosted to 2.2 in an attempt to match the other video files in your project. This boosted gamma is then used when the sequence is output to video or rendered as a QuickTime movie.
During playback on your computer's monitor, Final Cut Pro lowers the gamma of the sequence playing in the Canvas to 1.8 for display purposes. This is to approximate the way it will look when displayed on a broadcast monitor. The still image clips in your sequence are still boosted when the sequence is output to video or rendered as a QuickTime movie.
I use a Spyder by DataColor to calibrate my monitor to Gamma 2.2. I thought that was what I was supposed to do. I could create a special profile to use with Final Cut and set the gamma to 1.8. Would that solve my problem?
There might be an additional issue at play under Windows, for some people depending on your graphics card. h264/MP4/Sorenson movies will look washed out with blacks too high and whites too low.
When apps use hardware acceleration (hardware overlays) on nVidia graphics cards, some manipulation occurs by the nVidia driver converting from YUV to RGB.
Open the nVidia Control Panel and go to 'Adjust video color settings' under the 'Video & Television' group (generally the next to last on the list). Under "2. How do you make color adjustments?" click on "With the NVIDIA settings" instead of "With the video player settings", and then click on the Advanced tab. An option that says "Dynamic Range" appears, select "Full (0-255)" instead of "Limited (16-235)" and save.
This will happen with YUV-based codecs like H264, Sorenson, Motion JPEG, etc. RGB codecs like Animation, PNG or TGA aren't affected (but shouldn't look washed out to begin with, barring any additional Gamma issues going on.) There might be equivalents on other cards (ATI, Intel) or it might not be a problem in those cases.
Thank you Bob M !
Hey,
perhaps Perian (http://perian.org) could help you with your export problem.
You could also set up a output problem in quicktime (under windows and Mac (???)):
Open Quicktime player itself, then Edit/Preferences/Quicktime Preferences/Advanced.
Under Video, uncheck "Enable Direct3D video acceleration", then select "Safe mode (GDI only)", apply/OK. (I'm not sure whether the uncheck is necessary, but it's what Apple told me!) Then reboot, open QuickTime again and try to play the video correct.