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: