The QuickTime Gamma Bug

The QuickTime player causes H.264 and MPEG-4 encoded video to look washed-out. It’s commonly referred to as the “QuickTime gamma bug,” but it’s really a reduction in contrast, which converts the full range of pixel values (0-255) to the more limited pixel value range defined in in rec.601:

Y 16-235
U 16-240 (128 = the zero value)
V 16-240 (128 = the zero value)

The problem is not always possible to fix, so it’s important to understand what’s going on.


There are actually two different problems, which tend to be conflated with each other:

Problem #1: If you use Adobe After Effects CS5 to encode QuickTime H.264 video on a PC, After Effects will first modify the pixel values to boost the mid-tone brightness, by applying a gamma of (1/0.88). Each output_pixel is equal to (input_pixel) ^ 0.88. Here is the input/output transformation curve for RGB gray scale values: The maximum deviation occurs for an input value of 88, which is increased by 12 pixel values:

The value swatches below the graph show how input values are changed:

  • The top row shows the original RGB gray scale pixel swatch values
  • The bottom row shows how the original pixels are changed after the AE gamma shift.

The green line is a reference that shows no change in pixel values (Y = X). In the AE preview window, the image that you see does not reflect the gamma modification. AE does not apply this gamma boost when encoding using the QuickTime animation codec. You can’t turn off this gamma adjustment by fiddling with the settings in the After Effects File > Project Settings Window, or by using color-managed content. If you want to “undo” this gamma modification, then you need to add a filter to your video timeline in AE: use the Gamma/Pedestal/Gain filter, and set a value of 0.88 for the red, green, and blue gamma.

The situation for the QuickTime MPEG-4 codec is even worse: After Effects adds a gamma boost of 1/0.73, causing a maximum deviation of 30 pixel values for an input pixel value of 88.

Adobe Premier exhibits the same behavior when using the Adobe Media Encoder. I don’t know if Adobe products add the gamma boost when running on a Mac, or if Final Cut Pro adds a gamma adjustment.

If you encode using QuickTime Pro instead of After Effects, you don’t get this gamma modification.

Problem #2: The QuickTime player does not properly display decoded H.264 or MPEG-4 video: It lowers the contrast significantly, in order to convert from full range pixel values (0-255) to rec.601 pixel values. Threads on the internet talk about how the QuickTime player adds a “gamma shift”, but that’s mostly incorrect: there is indeed a tiny gamma shift, but the effect you see is dominated by a change in contrast. Here is the input/output transformation curve for some RGB gray scale values:

The green line is a reference that shows no change in pixel values (Y = X). The red line shows the transformation applied by the stand alone QuickTime player after decoding pixels from an H.264 bitstream. For example, a decoded value of 0 is transformed to a value of 22. The blue line shows the composite result of having both the After Effects gamma boost before encode, and the contrast shift of the QuickTime player after decode. The H.264 algorithm itself doesn’t significantly change the brightness/contrast/gamma of pixels: In areas of no detail / flat color, the H.264 algorithm changes pixel values by at most 2 pixel values out of 255 for a high quality encoder setting.

The value swatches below the graph show how input values are changed:

  • The middle row shows the original pixel swatch values
  • The top row shows how the original pixels are changed after the QuickTime player contrast shift, without the AE gamma shift.
  • The bottom row shows how the original pixel values are changed after the AE gamma shift, and the QuickTime player contrast shift.

In general, the result of this contrast shift is that your encoded H.264 video looks really washed out when viewed in the QuickTime player. It is particularly bad for rendered animation, which tends to rely on deep blacks and shadow detail.


Why is After Effects adding a gamma boost? Who knows.

Why is the QuickTime player adding a contrast shift? It seems that after the decoding process, when converting from YUV values to RGB values, the QuickTime player selects from one of several possible YUV-RGB conversion methods, each of which may have a different transformation matrix.  Some of these matrices add the contrast shift, and some do not.  It’s not apparent how to coax the QuickTime player to use the matrix that doesn’t impose a contrast shift.

Other decoders offer a way for the user to specify whether to perform the contrast shift between the full range of decoded values (0-255) and the more limited range of values for rec.601.  Here are screen shots from ffdshow and VLC:



The QuickTime Player contrast shift does not happen when playing back video encoded with the QuickTime Animation Codec.


There are several ways to trick the QuickTime player into not performing the contrast shift when displaying a decoded H.264 bitstream:

Straight Alpha (not recommended): In the QuickTime player, you can change the alpha setting of the video track to “straight alpha”. In this case, the QuickTime player assumes you are attempting to blend a foreground video track with a background, and QuickTime will disable the contrast adjustment, to facilitate accurate matching of a matte color. To set the alpha to straight, select Window > Show Movie Properties, then click on the Video Track line item in the top list, then in the tabbed panel on the bottom, click on the Visual Settings tab. Then for the Transparency item, chose Straight Alpha from the drop-down menu. Now close the properties window and save your .mov file using File > Save. However, this method is not a good approach. Setting the alpha in this way forces QuickTime to consume a lot more CPU cycles to play the video: Even without another video track in the background, QuickTime is probably doing an extra multiply for every single pixel. For small video dimensions, like 480×360, on a fast machine, you won’t notice a difference; but for larger video dimensions, or on a slower machine, you will get jittery playback because the QuickTime player will run out of CPU cycles and start dropping frames. So, not really a solution.  Bear in mind that this hack does not undo the gamma adjustment applied by After Effects.

X264 option on the Mac (great if you have a Mac). If you have a Mac, then you’re in luck.  People running QuickTime Pro on a Mac report that there is a definitive solution that doesn’t require hacks. Takashi Mochizuki has created an open source H.264 encoder inside a QuickTime codec wrapper.  You an use this encoder instead of the default Apple codec:

When playing back an H.264 bitstream generated by this encoder, the QuickTime player will not perform the contrast shift.  This codec uses the x264 codec along with some functionality of FFmpeg, but unlike FFmpeg, it uses the ICM OS X libraries to create the .mov container.  One of the key aspects of this codec is that it allows you to set color profile tags and gamma tags in the .mov file.

X264 option on the PC (Does not exist yet) If you are on a PC, you are out of luck: the above mentioned codec wrapper is not available for Windows. But it’s not for lack of trying.  I tried using the FFmpeg utility with the libx264 codec to create .mov files, and it doesn’t solve the problem.  I also tried modifying the color profile information that is embedded in the H.264 bitstream; no luck.  Then I recompiled the FFmpeg utility, and modified the source code to add color profile tags and gamma tags to the .mov container file.  But sadly, no combination of these modifications caused the QuickTime player to display the video correctly.  I suspect that the reason the Mac-based codec works is because the OS X SDK that creates the .mov container is probably doing something different than the corresponding functionality in FFmpeg.

The TIFF hack: You can add a secondary video track, consisting of a small TIFF image, and place this new track below your main video track so that it remains invisible. Adding this new track causes QuickTime to slightly change it’s behavior: it will partially restore the original contrast: without the TIFF hack, a decoded pixel with a value of 0 will display as 22: with the TIFF hack, it gets 27% of the way to the correct value of 0, and displays with a value of 16. So the TIFF hack is a “1/3 solution” at best. Not recommended. But in case you want to try it: Create a small TIFF image, with a size of 32×32. Open the TIFF image in QuickTime. Do Edit > Copy. Then open your video file in QuickTime, and do Edit > Add to Selection and Scale. The TIFF image will appear on top of your video track. Then move the video track below your main video stream: Do Window > Show Movie Properties, then click on the Video Track containing the TIFF image in the top list, then in the tabbed panel on the bottom, click on the Visual Settings tab. Then for the Layer value, increase the value to push the TIFF track under your main video track. Now close the properties window and save your .mov file using File > Save.

Gamma tag strippers: There are various utilities on the net that claim to strip out a “gamma tag” in a QuickTime bitstream. Supposedly, when the gamma tag is removed, the QuickTime player won’t perform the gamma/contrast shift. But these gamma strippers don’t seem to work, at least when playing the video on a PC.

Result matrix

If also considering the popular MPEG-4 codec, and various players (VLC, MPC, Firefox QuickTime Plugin), then the gamma and/or contrast change that you see depends on which combination you are using:

  • Whether you encode using After Effects or QuickTime Pro
  • Whether you use the QuickTime H.264 codec or the QuickTime MPEG-4 codec
  • Which player is used to view the video: QuickTime player (with or without the straight alpha fix), MPC, VLC, or the Firefox QuickTime plugin
  • Further, how VLC is configured is important: in the preferences, under Video, you can specify the output renderer, and whether hardware acceleration is enabled.  You can specify a default or GDI renderer.

The results vary widely:

Encoding MPEG-4 using QuickTime Pro
Player Result
Firefox gamma boost: Y = X^0.88
MPC increased contrast
VLC: default + HW accel correct display
QuickTime, straight alpha fix gamma boost: Y = X^0.88
QuickTime, no straight alpha fix contrast + gamma adjustment
Encoding MPEG-4 using After Effects
Player Result
Firefox gamma boost: Y = X^0.73
MPC increased contrast
VLC gamma boost: Y = X^0.82
QuickTime, straight alpha fix gamma boost: Y = X^0.73
QuickTime, no straight alpha fix contrast + gamma adjustment
Encoding H.264 using QuickTime Pro
Player Result
Firefox correct display
MPC slightly increased contrast; very close
VLC contrast + gamma adjustment
QuickTime, straight alpha fix correct display
QuickTime, no straight alpha fix contrast + gamma adjustment
Encoding H.264 using After Effects
Player Result
Firefox gamma boost: Y = X^0.88
MPC correct display
VLC: GDI correct display
QuickTime, straight alpha fix gamma boost: Y = X^0.88
QuickTime, no straight alpha fix contrast + gamma adjustment


On the Mac, just use the open source x264 codec.  However, I have not personally verified that using this codec solves the problem 100%: it might provide only a half-solution, similar to the TIFF hack.

On the PC, depending on your needs, it might be worth it to buy a cheap Mac, for the purpose of using the Mac-based X.264 codec wrapper, to generate .mov files that don’t have the contrast shift.  You can buy a used Mac Mini from eBay for about $500.

But if you still encode on a PC, using the QuickTime MPEG-4 or H.264 encoders, there are a limited combination of authoring tools / codecs / players that allow correct playback of video, without gamma shift or contrast adjustment.

This entry was posted in gamma and tagged , , , . Bookmark the permalink.

29 Responses to The QuickTime Gamma Bug

  1. Mehmet Kozal says:

    As someone who have read maybe 100s of pages about this subject, I don’t know how I’ve missed this article. Nice one.

  2. Nick Wood says:

    This is an excellent investigation of the H264 export problems. Thank you very much.

  3. Nick says:

    Excellent article, thank you. All the grey hair I have was caused by some variation of a Quicktime import/export/playback problem. This article proves that indeed it is a complex matter and not just a “Quicktime Gamma bug”.

    Maybe one wish: could you differentiate between playing back something with the Quicktime Player on Windows and OS X? In my experience there’s a huge difference between the platforms, even though the gamma is supposed to be the same since Snow Leopard.

  4. Pingback: Making Entertaining and Engaging Video Game Trailers

  5. Frihetsrevolutionen says:

    THANKS! Have been doing screenshots all day comparing in-out VLC vs QT. When uploading to Vimeo videos usually keep colors as seen in VLC.

  6. Johnston says:

    How would you take it from a PC to a MAC for the xH264 encoding? Encode it to an Animation file first on a huge hard drive?

  7. The H.264 nonsense cost me a high profile client several years ago. The network exec was insisting on a H.264 encoded Quicktime and I could not make one that looked right.

  8. Pingback: The QuickTime Gamma Bug | vitrolite | איגוד עורכי תמונה וקול בישראל

  9. Bill Ravens says:

    Using a PC, when possible, create a proxy file out of your NLE(In Avid Media Composer you create a QT Reference file) then use the proxy to encode to H264 in a program like MPEGStreamclip. This will avoid the gamm bug.

    I find it extremely frustrating and disillusioning that such a widely used and accepted application as Quicktime has carried this persistent bug for so many years. What are these people thinking? Or not, as the case may be.

  10. Frank says:

    Isn’t this all just a marketing ploy on the part of Apple to make video look like crap on a PC, but great on Apple devices? What other reason could there possibly be for this not being fixed over so many years?

  11. Great article! I’ve been searching for ages for a codec that will allow me to compress the quicktime animation codec with no loss of data , and preferablly using a hardware accelerated codec like h.264 , but I’ve not had any luck so far. I need something that will 100% presever the 24bit color of every pixel with ZERO loss in data, as the images are being used to store volumetric data and any compression artifacts destroy the spacial data. So far only the ANIMATION codec seems to give me what i want from a movie, and PNG and TIFF files for images.

  12. LV says:

    The VLC settings fixed the playback for me! Amazing! Other than that, if you upload your video to Youtube/Vimeo they play h264 correctly, so that’s great for client previews…

  13. C. Kinder says:

    On Windows in the Quicktime player’s “QuickTime Preferences” you can disable Direct3D video acceleration. This fixed the low contrast problem I had with the h264 and foto jpeg codecs. I also prefer this solution over the “straight alpha” workaround since Premiere seems to have problems playing back quicktimes using “straight alpha”.

  14. Marc says:

    Tearing my hair out over this still in 2014. Is this the same problem seen today? This seems to affect all quicktime outputs including Prores for me, which is incredibly frustrating. Up until I read this, it felt as though the problem lied with the fact the Quicktime X tries to colour manage but tags everything with the “HD” colorspace…which is incorrect.

  15. Pingback: Awesome But Broken: The State of Web Video (Part 1) | POV Films Blog | PBS

  16. Ash says:

    Wow, was searching for a solution for this way back when h264 had come out and even today we’re all looking around for a proper non-os specific fix to it! That is just crazy!
    Sounds like it really is Apple’s way of making everything quicktime look good only when generated from a Mac (not to detract from the main topic but this is sooo frustrating) – Am having to constantly deal with clients giving us a tough time for this. And it doesn’t help that the .h264 format looks so damn brilliant in all the trailers on the apple website but they haven’t bothered to share it with the rest of the world!
    That said, such a well written article! Wish I’d seen it as soon as it came out. Bookmarked your site if these are the kind of gems you’ll publish! Many many thanks!
    I mostly run on PC’s but am now considering buying a Mac just to be able to do this right – well done shneaky Apple! Well done indeed!

  17. digame says:

    Hi, I am experiencing the Gamma Shift Bug Issue, too. What´s really strange is, that after I managed to convert the MOV files into MP4 / x264 with ffmpeg / Avanti (on a Win7 system), the Gamma Tag seems to be still in the MP4 files, because if I try to convert those files with any other converter the output looks “bleached-out” again.
    And what´s even stranger than that, is that the same MOV files did not “bleach-out” after the conversion, just a couple of days ago. As if there was a “Time-Bug” inside the files, which just got activated?
    I am no video-noob, but this is freakin´ me out!
    If anyones knows a solution to this Gamma Shift Bug on a Windows OS for good, than I could chill the freak out, finally.

  18. digame says:

    Wondershare Video Converter Ultimate seems to do the trick, of getting rid of the darn tag. 😀

  19. Alex says:

    Hello there,
    i am a student from Germany and currently working on my bachelor thesis concerning problems like the gamma shift. I´m trying to figure out the best way for encoding broadcast-video for playing on a PC/Mac.
    My question: Is there any way to show a waveform/vectorscope of what my computer display is showing? I want exact graphs of what quicktime/VLC is doing with my video files!

    Thx for your help and this post about the gamma bug!

  20. Pingback: The State of Web Video: Awesome But Broken (Part 1) | POV Films Blog | POV Blog | PBS

  21. Pablogreg says:

    This is the best thread on the subject… Thanks for sharing…

  22. jonjon358 says:

    This is indeed a very thorough explanation…but it’s 6 years old now. Has anything major changed?

  23. Kavin says:

    I’m tearing my hair out with this issue!!! I downloaded the x264 encoder. It won’t even export with premiere exporter, is gives me the compiling error 3. It will export through AME but it still looks washed out. VLC shows the colors perfectly as I see them in Premiere. But when I upload the exported video to Vimeo, I see it in the washed out version! I’ve burned three full days trying to fix this issue. I updated my Nvidia CUDA driver, I’ve tried everything!

  24. Marcus Frendberg says:

    I find that adding an adjustment layer with Lumetry Color set to soft light and 60% op tweaked sat to 154 and exposure to 1,1 on top of the whole thing salves it most of the time. I hate this bug.

  25. Erik Vos says:

    Please remove the tip to download the H264 encoder on Takashi Mochizuki site! It is NOT working with 32bit processors. Perhaps the best solution is the Marcus’ tip above: “adding an adjustment layer with Lumetry Color set to soft light and 60% op tweaked sat to 154 and exposure to 1,1 on top of the whole thing”. HATE this bug even soo.

  26. Pingback: Premiere Proで書き出した動画の色が変わる問題【QuickTimeガンマバグ】 | Indieemotion

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s