I have been spending the better part of 2 days trying to figure this out. So far I have learned that Quicktime is displaying a gamma shift in the rendered video and that the actual file is okay, it is quicktime that is messing it up. This also goes for anything that uses quicktime, like safari, itunes, and similar players that use the Core Video hardware acceleration. Computers or Players that don't use hardware acceleration will show the same file correctly when played. But of course this is still an issue for anyone viewing your video on another computer with hardware acceleration enabled. To them your video will look faded.
It happens far worse on windows machines where the gamma is set to 2.2 (my mac was set to 2.2 until I found this nasty H.264 bug in quicktime rendering.) In the 2.2 gamma environment the shift in brightness is very pronounced. In the 1.8 mac gamma environment, it is less pronounced but still problematic enough that many of the studios that I know won't use Quicktime or the H.264 codec until this bug is corrected.
This problem is documented all over the web and it has caused major headaches for a lot of people for somewhere around 3 years. So far Apple hasn't done anything to fix it (or can't fix it) even though it is a persistent problem, especially for people who calibrate their monitors or people on PC's.
It's really frustrating and after hours of scouring the net for an acceptable solution, I still haven't found anything that doesn't involve simply not using quicktime or h.264. Here is one (partial) solution I found:
+This tip from Mitch Gates:+
+As you may have noticed, the current implementation of the H.264 compressor for Quicktime has the nasty side-effect of raising the gamma or black levels of the resulting movie file. In order to fix this you must have Quicktime Pro (otherwise the fix will not hold since you can't save the updated .mov). Here are the steps?+
+Open the QT+
+Go to "Window/Show Movie Properties"+
+Select "Video Track", then click the "Visual Settings" tab+
+At the bottom left, change the transparency to "Blend" then move the slider to 100+
+Change the transparency to "Straight Alpha"+
+Close the Movie Properties window, then play or scrub the QT. Your black levels should now look correct+
+Save over old .mov+
This is for PC's. On the mac you change the transparency to "composition."
The problem with this solution however is that doing this disables the settings that allow fast playback (playing the movie before it is completely downloaded.) Another issue with this solution is that, while it fixes the look of the video in Quicktime, VLC player still exhibits the 'washed out' look on the same file. Finally, this "solution" isn't actually a solution at all.
An interesting thing about this is that the video file itself is not really washed out as far as I can tell. There are a few things that point to this. One, exporting the h.264 file and changing the codec to "Animation" or "None" corrects the gamma shift and returns the colors to where they should be, but this increases file size dramatically. Second, I noticed that when I select the h.264 file and choose "get info" the preview thumbnail shows the poster frame with correct colors. Third, when I put the h.264 file online Safari shows it all washed out but FireFox shows it correctly. Strange...
At this point I think the only viable solution is to do this:
+MacInTouch Reader+
+I too have been plagued by this H264 problem for the past 2 years it seems.+
+I have a suspicion that if we polled the users experiencing this effect that it would result they all use custom or modified Display Profiles in the Display System Preferences.+
+My temporary (and somewhat silly workaround) has been to change my display profile to the standard "Cinema HD Display" instead of my user-created "Cinema HD Display Calibrated" profile.+
+It does alter the gamma of my display to a unpleasing value, but after changing it, the H264 export works beautifully. No gamma shift at all.+
+I have read all the suggestions on trying the quicktime "filter then colorsync" export and always got unsatisfactory results. My silly workaround always produces the best results. I just have to change the dang setting back after I export so my eye don't burn out of my skull.+
So it all comes down to a gamma shift on the part of Quicktime's render of H.264. You would think that after so many years of this issue going on Apple would have fixed it since they have documented that they know of the problem. A little baffling.
If you want to research this further, as I will continue to, just type "h.264 gamma" into google and you will find a ton of fellow frustrated users trying to figure this out. Most just switch to Sorenson 3 it seems or "un-calibrate" their displays when doing the render export. None of this is perfect unfortunately and I find myself using "Animation" even though the file size is insanely huge. It is better that having upset clients telling me that the video is washed out.
11th_door wrote:
The problem with this solution however is that doing this disables the settings that allow fast playback (playing the movie before it is completely downloaded.)
Actually, this can be fixed by using "Save As..." from the File menu and selecting "Save as a self-contained movie."
This adds the Fast Start information to the file.
The gamma issue is still a major pain in the butt however, but your posted suggestion of altering the transparency setting helps a bit. Thanks for that.
Working with uncompressed AVI useing QT to view on Mac and PC. QT won't play 79GB file. on either platform. Get audio, no video. If QT doesn't see it, Squeeze doesn't either. Need to compress to FLV.
The gamma shift also happens if you export to FotoJPG codec. And I found that changing the playback mode to composition decreases the performance of the playback 😟 This is really bad...
It is good (or not so good) to see that I am not the only one with gamma issues using Apple's implementation of H.264. I finally solved this one I think, or I should say I have a work around. I downloaded the x264encoder component from mycometg3 on the video download section of Apple's site. Using x264 to do my h.264 encoding (with Perian installed) completely fixed the gamma shift. I also had success (with Perian installed) using VisualHub to encode my h.264 with the "force ffmpeg" option turned on in the advanced pane. It now seems to me as though the problem is with Apple's implementation of Quicktime's H.264. I hope this fix helps, it seems to have cleared it all up for me.
I just tried x264encoder myself and it worked great! Thanks 11th_door!
From what I have noticed, this problem basically comes down to the fact that Quicktime's implementation of h.264 forces the exported video to have a gamma of 1.8 instead of 2.2. (or something like that)
Since the gamma level is then encoded into the h.264 file, it's appearance stays exactly the same whether you are in a 2.2 or 1.8 gamma workspace.
Try it and see for yourself...
Open your original video in quicktime.
Now open your display preferences and toggle the gamma back and forth.
You will see that the video's gamma changes along with the monitor.
Now open up your h.264 file and toggle the gamma.
You will see that the video stays exactly the same, even though the monitor changes.
This seems like a good idea, to make sure that a video's appearance stays consistent between mac and pc. The only problem is that it over compensates!!!
Without the option to choose 1.8 or 2.2 gamma during h.264 export, this feature is pointless and messes everything up.
Apple! You need to add the option to choose 1.8 or 2.2 on export! For crying out loud, figure it out.
Anyway I thought that was interesting.
11th_door, thank you for your recommendation. Works like a charm. And in my opinion the encode quality looks better from x264encoder than QT's built-in option. The only "problem" now is that the video's appearance changes between 1.8 and 2.2 gamma environments, just like the original file.
Update on x264encoder.
There is a way to make the exported file maintain a consistent appearance whether you are in a 2.2 or 1.8 gamma workspace. I'm thrilled I figured this out.
Choose x264encoder in the QTpro export pulldown.
Click Options
Click the Extra Options tab
Change the pulldown menu that says "No nclc atom" to one of the other options (I chose 6-1-6)
Make sure the "Add gamma 2.2 (legacy atom)" is NOT checked.
Hit OK and export your movie.
Now you have an h.264 encoded movie with correct gamma, and the appearance stays the same between 2.2 and 1.8 workspaces. (Confirm this by opening your display color preferences and toggling the gamma settings while your quicktime movie is open.)
-Andy
Awesome Andy, many thanks. I think this one is licked now, and after a long time too. I noticed also that doing my h.264 conversions in VisualHub with the "force ffmpeg" decode checkbox marked works for this as well.
Out of Curiosity, what does changing that pulldown menu actually do?
I have a similar problem but it manifests itself in Safari but not the Firefox?
The colour (I'm English hence the spelling) of my video (which I uploaded) looks both different from the same video when viewed with Firefox and in playback on my desktop with QuickTime. Is there any reason for this? Am I missing a trick with a color profile setting in QuickTime or Safari?
I have ticked the box in QT which enables Final Cut Pro color compatibility.
From My understanding, Ben, and I am no expert on this stuff, Firefox uses it's quicktime plugin differently than Safari. Safari will display it just like QT but Firefox ignores the gamma setting in the movie (perhaps it isn't supported on Firefox?)
Either way, Firefox tends to look better displaying your movies if you have been experiencing these gamma issues where QT is lightening the movie in h.264 codec. I can't verify if this is accurate since I haven't tested my movies on Firefox yet but there are several forums that have mentioned exactly the issue you are having. It is the same for viewing your movie in an app that uses ffmpeg instead of QT to decode the files for display (perhaps Firefox is using ffmpeg?) Either way, the x264 component seems to clear this up well as does using VisualHub with "force ffmpeg" decoding checked.
Andy, you were right about the nclc atom thing, it allows gamma compensation when switching from 2.2 to 1.8 and back. I just don't understand WHY? Do you know? It always bugs me not to understand how things work...
It would be great if Apple would fix this issue but from everything I have read online it has been going on for the better part of 3 years, at least I think the first posts I read on the issue dated from 2005 or 06, so I don't think an Apple solution is coming. Until it does, I can't use QT's h.264 implementation for encoding. Oh well, at least there is a workaround now.
Thanks for your thoughts 11th Door! What is frustrating is that the quicktime plug-in for safari, doesn't seem to use the same gamma adjustment as the quicktime program seems to. I don't understand why this would be the case. Firefox, final cut pro and quicktime all work fine yet it doesn't in the browser.
Very annoying and apple should look to resolve this.
Sorry for the delayed response... I am not actually sure what the nclc atom thing does. Wish I understood it better. I'm just glad to have a workaround now.
