MOV gamma shift: how do you deal with it?

Samuel H

Samuel H

Major Contributor
I thought I had found a workflow that avoided the gamma shift associated with Apple's MOV (QuickTime) container, but I recently found out that it is very far from perfect...

When I load the dailies into the editor, I don't mind if there's a gamma shift: with the file in a high-bit-depth environment, it's easy to add a gamma correction and get back to something that looks like what I saw in-camera, without any impact on image quality.

Then, I know that exporting from Premiere or After Effects to very high-quality H.264 format (IIRC, the file extension is .mp4) preserves the colors. These files are hard to play back (none of my computers can do it smoothly), but I can then re-encode with Handbrake, to a more reasonable H.264 bitrate and .mkv container. There's an image quality hit because of the extra re-encode, but it's very small if the bitrate of the PP or AE export is high enough. And the final result is an H.264 file in .mkv container that preserves the in-editor colors and gets much better playback on nearly every platform (I think Handbrake is a tool made for pirates, or at least very popular in that world; THEY know how to deliver the product in a user-friendly format...).

And this is where the nasty suprise comes in: when I upload that file to vimeo or youtube, it is re-encoded, the gamma shift happens, and my pretty images look awful (a lot darker than they should).

Case in point, my recent zombie piece; all my beautiful shadow detail gone down the drain...
http://vimeo.com/40741414
(I'm not sure, but I think this didn't happen on vimeo until recently...)

So, my question is: how do you deal with all this?

If you export from PP or AE directly to MOV H.264, the gamma shift happens, but at least you get to see how it looks before it goes online. Right now, I think my way out would be to create two output files: I would create an mkv that looks as it should, with the workflow above, and then add a gamma shift to all my edit and export to MOV H.264 (tweaking so both gamma shifts cancel each other), to upload to vimeo or youtube.
 
Can you post a frame grab from before and after from the same software of this "gamma shift"? I can't see the original obviously, but your sample simply looks like it was crushed from 0-255 to 16-235 color range.
 
From my own personal experience, when exporting from AE as a lossless format (specifically Animation) I don't see a gamma shift if I bring my comps into Final Cut (my NLE of choice). However, when I export the master as a QuickTime .mov (H.264), the color shifts slightly and washes out the overall image. I myself, haven't come across any other solutions when dealing with H.264 but since it's such a robust little format, the workarounds are well worth the final results. As you suggested, I too would simply anticipate the shift(s) in order to compensate, before posting to Vimeo, etc. Unless anyone else has a trick up their sleeve that would eliminate this extra step, I'd say that's the way to do it, in spite of the platform you choose to edit with or what container your H.264 is in.

Just know your not the only one experiencing the hiccup :furious3:

Haha :thumbsup:
-B
 
Youtube is especially well documented as having this gamma shift problem with h.264. I was very annoyed at first, but my solution was simply not to use H.264 as an upload format anymore.

I started using WMV out of Sony Vegas (with their high bitrate preset for 720p), and it has been perfect. From CS5 its a bit more difficult, as their WMV support is very lacking. I'm sure there are other youtube-friendly formats to choose from as well.
 
ok, I had to check if it was a gamma shift, a 16-235 cut, or something else...

the bad news: it's something else, and not a simple thing to correct
the good news: it shouldn't be so obvious in pieces that are not as dark as my zombie flick (which -probably- is the reason I never noticed this before)

this is what my video looks like in the editor, and in the mkv file (scopes confirm that they're identical)
zombie_mkv.jpg

and this is what it looks like in vimeo
zombie_vimeo.jpg

check out the scopes:
zombie_scopes.jpg



I see added contrast and a color shift; it doesn't seem like an easy thing to counteract with a pre-emptive effect in the editor...
 
they are a bit different in the images and the scopes. not as severe as gamma shift or 16-235 though.

if you don't mind, can you test 10 sec exports and show us the scopes again with(always choose the highest profile, max bit depth, max render quality, (if you have to choose between pal and ntsc, choose pal and then adjust the fps), a high bit rate)

-h.264 (youtube, vimeo, apple tv presets, custom)
-h.264 blu-ray
-DPX(go from gamma 1 increase in 0.2 increments)
-F4V
-MPEG4(change the tv setting to pal to go into custom preset, adjust the fps, max bit depth,
-uncompressed AVI (v210)
-Quicktime(DNxHD, animation, prores LT)
-wmv
 
I already did something similar to that, that's how I ended up with my H.264 workflow - it seems I'll have to do it again, with one extra step: upload to vimeo and see if it stays the same or not - it may take me months, though: I'm pretty busy right now...
 
thanks for the great efforts.

can you add H.264(.mp4 container). <- i was looking for that .mp4 container, not that used to adobe export and media encoder.

i have high hopes for mp4 and f4v, unless you can add a MKV(x.264) to premiere or media encoder.

weird that you found .mp4(h.264) harder than mkv to playback, sometimes it's the h.264 flavor or rendering engine for playback chosen to decode/playback the files. i remember you have to install and choose the video decoder for it to play back smoothly on pcs.
 
my playback problem with mp4-h264 comes from the fact that mpc-hc can't handle it (gives an error, no idea why), and that's my only GPU-accelerated H.264 player

I can play it back with VLC, but then it's not hardware-accelerated and playback is not smooth

the h264 flavor that handbrake creates works perfectly with mpc-hc



I understand that on the mac world all this would be very different
 
You must log in or register to reply here.
Back
Top