ProVideo Coalition.com: Stunning Good Looks by Art Adams

There’s nothing like waking up in the morning and realizing that your chief marketing tool is probably driving away more clients than it’s attracting.

I both love, and hate, Quicktime. Flash is the universally accepted method of viewing video on the web but it doesn’t seem to be an easy or cost-effective tool for those of us who want to manage our own showreel web sites. I own On2’s FlixPro, and while it seems to be one of the simpler solutions out there it is still horribly difficult to get the same quality out of Flash video that I can easily get out of Quicktime. Newer tools, such as Adobe’s Media Encoder, do a very nice job because of their recent addition of H.264 as an encoding option, but there’s still the issue of constructing or adding a player to the video file after the encoding process. Frankly I just can’t be bothered to learn how to do all that. Encoding video is not my primary career.

Quicktime has always been super easy to use. In the old days I spent $30 on Quicktime Pro and used that to compress my video to manageable sizes. Encoding with Quicktime 6 Pro was easy, and H.263 offered fairly good compression at fairly small file sizes.

And then the H.264 codec showed up. It compressed smaller, prettier and cleaner than anything that came before it. It completely changed the face of video on the web. But… there was one near fatal bug.

This article by PVC’s Chris Meyer explains the problems that a lot of us have suffered through for the last three years. While H.264 is about the best codec out there for compressing web video, and while it is super easy to use when outputting from Final Cut Pro via Compressor, the gamma is ALWAYS boosted, making clips look both milky and desaturated. And that doesn’t bode well for business, as almost nobody wants a physical showreel anymore. They want instant gratification via my web site.

The only reasonable explanation that I’ve heard for this boost in gamma is that Apple assumes that your display is set up for a gamma of 1.8 and is trying to help you out by encoding video with that gamma setting locked in. This website has an interesting explanation about why that is. The digital video and Windows worlds are both locked in to a gamma of 2.2, and that’s currently how the vast majority of computer displays are set up.

The culprit is a tag hidden inside Quicktime that tells Quicktime Player to display H.264 video with a gamma of 1.8. There is no known way to access and change this tag. There are a couple of applications that claim to be able to strip this tag from an existing Quicktime file, but none of them worked for me.

I asked a web-savvy friend if he had a solution and he suggested that I encode my video with a Compressor gamma filter setting of 1.22, with the intent of counteracting the gamma boost by making the video darker. This appeared to work, and I was quite happy for several months, until it was pointed out to me that my video clips looked way too dark when viewed in Firefox. Safari and Omniweb (my current browser of choice) see H.264 encoded video with the boosted gamma, so my Compressor-darkened material looks fine; Firefox somehow bypasses the gamma tag and sees the video clips as they really are: too dark. I’m told this is also the case when H.264 Quicktimes are viewed in Windows, a platform which (I’m told) has a quite a few customers.

The best solution I found was to use X.264, an open source version of H.264, although this solution also had its issues. We’ll cover those on the next page, but first, let’s take a closer look at the problem. The following image is from a spec spot I shot on the RED ONE for Nintendo’s Wii:

Here’s a dark frame that I’ve used as a reference for my encoding tests. This is how this image should look on the web. Watch what happens to the background detail in the next few images.

In the Compressor-exported version the gamma is lifted, desaturating the color and making everything a bit brighter. What’s interesting is that I had to capture this still via screen capture using Apple’s Grab utility, because when I exported the frame as a still from within Quicktime the gamma on the still was correct! Apparently the boosted gamma tag does not follow a still image the way it does a Quicktime movie.

This image was corrected using the gamma filter in Compressor, set at 1.22, darkening the gamma-boosted image to emulate a gamma of 2.2. It looks almost like the original (top) image, and certainly looks a little better than the image with the boosted 1.8 gamma.

Here’s the same darkened image viewed in Firefox. The background is almost completely gone. Crushing the blacks has over-saturated the colors. What looks fine in Safari and Omniweb looks awful in the world’s most popular browser.

This is the X.264 encoded image, viewed in Firefox. It’s a considerable improvement.

So, for several months now, my web site has looked appallingly dark to anyone who viewed it using either Quicktime for Windows or Firefox, a browser that recently overtook Internet Explorer for world market share.

Needless to say I spent a lot of time over the last few days frantically trying to find a solution. Chris Meyer’s article held part of the answer and the rest I had to find out for myself. Read on, that you might spare yourself the pain that I experienced…

The Editing of “Courageous” Part One

Steve Hullfish | 10/14

The off-line edit of a RED feature film

Last October, I had the rare opportunity to edit a feature film called “Courageous,” which is in theaters now. “Courageous” was the number one new movie the weekend it opened (September…

Q and A with Bunim/Murray’s Mark Raudonis about their recent Avid switch

Scott Simmons | 02/07

If you haven’t heard they have moved from FCP7 to Media Composer

Back in January news broke that reality television producers Bunim/Murray were switching their post-production facilities from Final Cut Pro to Avid Media Composer. This probably didn’t come as a great shock to anyone who follows post-production as the release of Final Cut Pro X had left many people (especially those…

Full Compass Systems Appoints Jim Ripp as Assistant Sales Manager

PVC News Staff | 02/06

Big News for the national leader in professional audio, video, lighting, A/V and musical instrument sales

Full Compass Systems, a national leader in professional audio, video, lighting, A/V and musical instrument sales, has selected Jim Ripp as its new Assistant Sales Manager. Ripp has a wide range…

You must be registered to comment. This is an effort to reduce spam. Please REGISTER HERE.

Good stuff! This answers my question about why my H.264 looks fine after coloring, but then looks different in QT. I use Adobe regularly so I’ll check out X.264.

Posted by Jay Friesen on 03/12 at 09:31 AM

Encoders using X.264 can be strict about the height and with dimensions of files pushed through it. Many H.264 encoders require the height and width to be a multiple of 4 or 8, some are strict enough to require it be a multiple of 16 (Apple’s H.264 QuickTime encoder doesn’t have this restrict, but you may sometimes get stray green lines on the sides of your video if one of your dimensions isn’t a multiple of 4, 8, or 16).

This may be what was causing the crashing. X.264 encoders will take videos encoded in pretty much any aspect ratio, so long as the height and width dimensions are divisible by 16 (or 4 or 8, in the case of some of the less strict ones).

You may want to try 720x400 as dimensions for X.264-encoded 16:9 videos (you can either crop slightly to the exact 1.8 aspect ratio of those dimensions, or allow the video to be ever so slightly stretched in, depending upon your preference).

As for the deinterlacing issue, you were right not to trust the X.264 deinterlacing option. I use the MyCometG3 X.264 encoder, which is great except for the poor deinterlacing quality. If you export a Final Cut movie to a reference movie file, and use that in Compressor to export to a QT movie encoded in Animation or Photo-JPEG, is the gamma shift still there? If not, Compressor could still be used for the deinterlacing process, with X.264 encoding as the final step in the post process (i’ve used a workflow similar to this in the past, and I don’t recall any gamma shift issues, although I didn’t test my results in any Windows browsers as the final video was for local use rather than the web.)

Hope this helps!

Posted by Brandon Cordy on 03/12 at 11:23 AM

Okay, now THAT actually works. I exported a Quicktime Reference movie in the Animation codec and fed that into Compressor. The gamma held! I’m totally gobsmacked. Here I thought Compressor was the problem but apparently the issue starts farther up the food chain.

I think I’m going to have to add on to this article…

Posted by Art Adams on 03/12 at 12:35 PM

Regarding making Flash video file using H.264 codec, using Compressor is pretty simple. Just use the same settings than you use to make your Quicktime H.264 (or x264 by the way) movie and then modify the three letter extension of your movie from .mov to .flv. Et voilà ! Note: H.264 flash file can only be played from Flash player version 9 update 3 and above.

HTH,

David

Posted by .(JavaScript must be enabled to view this email address) on 03/12 at 12:39 PM

Constructing or adding a player is not nearly as difficult as it used to be with Adobe CS3 or CS4 because you can export a Flash package complete with player, HTML and XML code, from Encore after or as if you author your DVD.

Posted by DanConklin on 03/13 at 07:49 AM

Sorry, that was some bad writing on my part. That last post should read “...as it used to be. With Adobe CS3 or CS4 you can…”

Posted by DanConklin on 03/13 at 01:30 PM

Has there been any updates on how FCP7 handles gamma? I’m tearing my hair out at the moment because I do not know if what i am seeing is the true gamma of my picture or not!

I graded an XDCAM EX 35Mb/s timeline in Color. I viewed the footage using an MXO. So far so good. The grade looked really nice. So I exported from Color in Prores HQ and took that timeline back into FCP6.

Now, I needed to do some work with Motion on one of the graded clips, so I opened that clip up on Motion and went to work. I noticed that for some reason this clip, unlike all the others had been flagged as being interlaced. So I went to the media properties in Motion and changed it to the correct setting of Progressive scan.

So far so good. But then I noticed another option in the properties for my clip in Motion. Gamma. It was set to 1.8. But when I output from Motion via the MXO the picture looked the same as it did when I graded it in Color.

Now the obvious thing to think is that the MXO is correctly showing the clip as 2.2 gamma. But the clip also looked very similar in the main Motion editing window as it did on the MXO output.

So, is a 2.2 correction being applied to the Motion editing window as FCP does in the Canvas and viewer windows while the actual Prores file is still in that infernal 1.8 gamma?

Pretty much what I want to know for my own reaassurance is whether the output from Color to the MXO is 2.2 gamma? After all I don’t want to grade in Color only to find that it is outputting in 1.8 gamma and then find out that when a file is output in a codec that natively uses the correct gamma that everything ends up looking far too dark!

Really I’m confused by this whole issue, as you can probably tell!

Posted by Simon Wyndham on 12/06 at 04:55 AM

Hi Simon-

I don’t know what’s going on at the moment. I got so frustrated that I took the time and energy to switch my web site over to Flash.

I’d heard that Quicktime Player X displays proper gamma while the Quicktime browser plugin doesn’t, but last week I saw an example with a spot that I was color grading where the gamma on the client’s review copy, exported in H.264 via Compressor, looked better in Safari than it did in Quicktime Player X. I honestly don’t know what the heck is going on.

I’ll see if I can take a look in the near future. I’m working on a couple of behind-the-scenes articles now, and I have a big job coming up, but I’ll try to delve into this and see if I can figure out what’s going on.

So far X.264 still seems to be the best option for encoding H.264 gamma-correct web video.

Posted by Art Adams on 12/06 at 12:37 PM

That’s interesting about your client example. It would be interesting to find out what’s going on there.

Looks like for the most part we need both the Mac Quicktime browser plugins and the PC Quicktime software and plugins to display at 2.2 and we’ll be set.

However it seems clear from when I used Prores in Motion that the default gamma for that codec is 1.8. When I set it to 2.2 everything went a lot darker. Too dark in fact. So what does appear to be happening is that the Prores codec is stored at 1.8 gamma, but the Motion canvas window and MXO output are actually compensating and displaying at 2.2.

Utterly absurd for a codec that is supposed to be for video!

I might try a test actually, and import an FCP Prores sequence into Motion, but change all the clip gamma properties to 2.2 gamma and export from there and then go into H264 from Compressor to see what happens. With all these hard drives I really can’t be doing with outputting timelines in the Animation codec. It would actually be quicker to do this extra step to Motion assuming it works.

Posted by Simon Wyndham on 12/06 at 03:50 PM

Incidentally I am trying X264 via Handbrake. But for some reason Handbrake doesn’t like Prores footage.

Posted by Simon Wyndham on 12/06 at 03:51 PM

Name:

Email:

Location:

URL:

Smileys

Remember my personal information

Notify me of follow-up comments?

Submit the word you see below:

The Quicktime Conundrum