[Matt Lyon]

Dustin, there are other software encoders that people have reported getting good results with, like “Episode” and “CompressHD” … try searching the forum.

I have found x264 to be a little kludgy, but once I found the right settings, I am getting consistent results as far as gamma is concerned.

But why are you encoding ProRes movies from your x264 quicktimes? You are just creating pointless generation loss. You should export ProRes quicktimes directly from your original timeline, or from a native, self-contained or reference quicktime, using Compressor.

And I don’t have much experience with FLV, but my understanding was you don’t need to use that format if you are delivering h264 compliant streams (they work natively in Flash).

Matt Lyon
Editor
Toronto

[Matt Lyon]

Did you “select all” in the browser, then export the xml?

I just did a quick test in FCP 6.0.6 and all the bins showed up when I re-imported into FCP. I don’t have Premiere or FCP 7 to test with though…

Matt Lyon
Editor
Toronto

[Matt Lyon]

Thanks for the follow up Dustin. I’m glad it is working for you! I wouldn’t be surprised if workflows like yours are the fastest growing segment of the market. Let’s hope Apple takes some steps to address these issues in the next release of FCP.
You might also want to consider getting a cheap windows/Linux dual boot box for checking your movies on other OS’s, player software and browsers (similar to what web developers do for checking their sites)

Matt Lyon
Editor
Toronto

[Matt Lyon]

I also noticed this problem as far back as FCP 4.

IIRC, another workaround is to “force render” the sections of your timeline that contain text. Now those pixels will be “baked in,” so Compressor can’t screw things up when it renders.

I’m not sure if the problem is limited to text generators. I seem to remember “shape generators” had problems too, but I’m not positive. This issue always makes me think twice about using the “send to compressor” option. It’s definitely a good idea to spot check your quicktime after compressing this way!

Matt Lyon
Editor
Toronto

[Matt Lyon]

Hey Dustin,

I’ll try to answer both your posts in one:

Everything I’ve said only applies to H264 outputs! It really isn’t a big deal … FCP just puts the wrong gamma flag in the stream (actually, the culprit is more likely the Quicktime libraries, but that’s another story). There really aren’t that many hoops to jump through, just install x264 and you’re good to go. Make some new compressor presets and you don’t have to think about it again.

x264 outputs standard h264 compliant video streams, so any app that plays h264 should have no problem playing back these movies (unless maybe you do something really crazy in the settings). x264 is just an open source set of software libraries for encoding H.264 video (kinda confusing, I know).

And yes, I recommend leaving the “FCP color compatibility” option OFF, so you are seeing something closer to what “the client” is probably seeing. (Remember this in itself is a big fat moving target). Remember to set your monitor to 2.2 gamma, because this is how most PCs are set.

FCP was, and still is, designed to work with a broadcast monitor. If you are ingesting DVCPro HD footage and outputting DVCPro HD master tapes, rest assured the “gamma” is not being touched. And you shouldn’t be judging your footage by the FCP viewers; get a broadcast monitor (this comes up a lot on the forum!)

Forgive me as I lapse into “lecture” mode for a second, but working in this business is all about “jumping through hoops” for your clients. Don’t shy away from doing a bit of legwork. Spend an afternoon with FCP, Compressor and a bunch of test patterns and develop a workflow for grading and outputting quicktimes that satisfies your quality requirements.

Matt Lyon
Editor
Toronto

[Matt Lyon]

Hi Alec,

I mentioned this is the other thread I linked to, but I think you should leave the color compatibility option turned OFF in QT player.

All it does is change the way your video is displayed. It doesn’t change anything under the hood, so to speak. So if you want to see how your video will appear on most end users’ computers, leave the option off.

Have you tried setting the “2.2 gamma” flag using x264? I would also check your movie on a windows box, if you can, before upload.

Matt Lyon
Editor
Toronto

[Matt Lyon]

Thanks Walter, I definitely agree with what you are saying. It is a shame that FCP has not kept up with the times in terms of color management. At least there are some workarounds for the time being.
The more I think about it, the more it seems to make sense to me to leave the \”enable FCS compatibility\” option DISABLED in QT player. At least this way you are viewing your output the way it will appear to most end users.

Matt Lyon
Editor
Toronto

[Matt Lyon]

I just posted about this on another thread, but have you tried the x264 plug-in, and using it to set the gamma flag properly?

https://byteful.com/blog/2010/07/how-to-fix-the-h264-gamma-brightness-bug-in-quicktime/

You could also try my colorsync filter idea I posted about here:

https://forums.creativecow.net/readpost/8/1115178

I haven’t tested it too much, so I kinda consider it to be “beta” advice.

Hope this helps,

Matt Lyon
Editor
Toronto

[Matt Lyon]

[Rafael Amador] “This shouldn’t be there anymore. With a native 2.2 Gamma this option only miss leads people.”

[Walter Soyka] That’s what I thought, too — but it still affects the image! I’m running Snow Leopard 10.6.5, FCP 7.0.3, and QuickTime 7.6.6, and the standard “Cinema HD” profile for a 30″ Apple monitor, and unless that box is ticked, clips look different in QT and FCP.

I’m kinda late to the thread here … but this issue has been bugging me and I had some thoughts:

What is important to remember is that while Snow Leopard changes the colorsync behaviour on an OS level, the “guts” of FCP and quicktime player 7 haven’t changed significantly in a long time, at least when it comes to the display engine.

Someone can correct me if I’m wrong, but FCP was initially coded with the assumption that every mac would use a 1.8 gamma. That’s why the FCP viewer would “darken” the image … it was trying to fake an “TV” like gamma (2.2) on the computer monitor (I’m talking FCP v1 here, using the DV codec).

If you select the “Enable FCS color compatibility” option in QT player, it is mimicking the way the FCP viewer works. Read the fine print underneath the option; it DOES NOT use colorsync, instead doing a straight display of the 2.2 gamma color in a 1.8 gamma colorspace (Truth be told, I find the wording of this to be totally confusing and open to so many different interpretations so as to be meaningless). But the important point is that it makes QT player behave like the FCP viewer.

BUT, this is just changing the way the player INTERPRETS the pixels in your video. It is not solving the underlying problem. You can still send your video to another machine and it won’t look right.

So I don’t think the move to Snow Leopard has solved any of these issues at all. If anything, it is even more confusing.

But I’m also a little put off by people’s expectations that one should be able to magically export a quicktime that somehow matches perfectly what you see in FCP.

I’m probably gonna sound like an old curmudgeon here, but I still remember when you had to manually remap your 16-232 8 bit video space to 0-255 RGB computer color space to get web videos to look right. So I guess I’m just used to doing some extra tweaking to match my exported quicktimes to what I see on the broadcast monitor.

But having said all this, having to remap colors is a thing of the past and the h264 codec supports proper gamma flags. The issue seems to be the inability of FCP to properly set that flag. Have you tried using the x264 plugin? Here’s an interesting article:

https://byteful.com/blog/2010/07/how-to-fix-the-h264-gamma-brightness-bug-in-quicktime/

I’ve also had some success using the “filters” setting in the QT export options:

Select “adjustmenst>colorsync.” The next part is a little tricky and I haven’t gotten consistent results. You need to pick an input and an output colorsync profile that bakes the proper gamma curve into your video. Try using “Adobe RGB” as your input and “Adobe sRGB” as your output. I’ve had some luck in the past getting it to work with these settings, but YMMV.

But at the end of the day, we still have no control over how the end user’s computer display is calibrated! No matter how perfect we refine our output, we’ll still get calls from directors/producers/parents/bail bondsmans saying their video is too bright/dark/saturated/washed out, etc. (not much different then broadcast television, eh?)

Hope these ramblings are somewhat helpful!

Matt Lyon
Editor
Toronto

[Matt Lyon]

Rafael,

I hate to say this after you have digitized everything, but is there a really good reason you needed to upconvert ALL your footage?

In this situation I would have used an offline/online workflow:

Edit your show with all your material captured in their native frame rate/resolutions, with burn in timecode (to ease the conform).

Lock your picture, then recapture/upconvert/standards convert, JUST the program content. Recapture using handles, to allow for massaging of the edits.

Budget permitting, I would even take this job to a proper online facility, where they can do proper hardware based frame rate conversions.

Since you’ve already captured all your footage, you can still edit in a mixed frame rate timeline, then convert your PROGRAM footage (with handles) AFTER locking picture, to spare yourself the CPU cycles. Allow yourself a couple days to do the conform.

Matt Lyon
Editor
Toronto