To wit: recently, director Evan discovered that the QuickTimes we are exporting from Final Cut Pro have a slight color shift compared to the QuickTimes we are cutting together.
Note that we're attempting to do a full online edit, here. Apple ProRes 4444 on input and Apple ProRes 4444 on output. So there shouldn't be anything happening on export. FCP is certainly not rendering, we would know that because it would take forever. It doesn't. The exports are fast. Also, we're not using any filters on these clips. This problem shows itself with a single QT movie dropped into a new sequence then exported using the same codec. What gives?
FCP is doing *something*, though. Check out this split-screen:
On the left is the original QT, on the right is the one exported from FCP.
The answer lies below, if you want to jump past the gory details.
I have toured through all of the little hidden FCP switches I could find, and though I tried them all (especially those related to gamma), I got the same results. I also threw the little secret QT player preference switch that says "Enable Final Cut Studio color compatibility" but that only adds some warmth to the files. And, I will note, it changes the look of both the original and the exported QT movie, so it can't be the culprit.
My theory is that although FCP is not re-rendering these movies, it must be adding some flag which tells QT player to display the same data differently. I'd like to figure out what that flag is and strip it, somehow.
This is when it's good to have a bunch of movie viewers around. If it's some weird little QT flag, some older viewers may not recognize it.
First thing to try is Shake. And in Shake, both the original and the exported movie look the same (good!) and they both look the same as the original looks in QT player! Which is good, because the director is approving shots based on how they look in QT player.
The Shake example still doesn't tell me what the flag is, how to stop it from happening, etc.
It gets weirder. If I load both clips into Compressor, and view them through the Preview window, they both look darker and they both look the same but neither looks like the bad FCP exported version in QT player. If I apply a gamma correction of .8197 in Compressor (the inverse of 1.22, which is the gamma 1.8 to 2.2 conversion factor), then they both look like what we want them to look like.
Gotta love this business to be in it. Because if two Apple apps display the same movie differently, then you're kind of hating life.
Some web searching led me to this thread on the Apple support forum. A lively discussion of FCP adding QuickTime "atoms" when it exports movies. This looks like what I'm grappling with. I downloaded the amazing tool JES Extensifier, and yes, I can see that the atoms are set differently between my imported movie and what FCP exported. Here's what JES EX says about each:
Above: The JES Extensifier Inspector screen for the FCP exported movie
Above: The JES Extensifier Inspector screen for the original movie
FCP has written values for the colr and tapt atoms but the input movies don't have them. Note that the tapt atom has something to do with frame size so I'm ignoring it.
So what is the colr atom? Some light reading says it's essentially a required color space identifier for QuickTime movies. The two choices for the colr atom are nclc and prof, and the one FCP added to our movie was nclc (short for "nonconstant luminance coding").
Required? But the ProRes 4444 movies we make with Shake don't have the colr atom and they look perfect. Hmm.
Anyway, if I use Extensifier to remove the colr atom from the FCP export, the movie looks the way I want it to in QT player. Hurray! But the story continues, because the movie doesn't look right in Compressor. So I must dig deeper...
FCP is setting the colr atom to nclc with HD as the default. It is apparently assuming that we're making HDTV material.
There are other arguments to the colr atom (primaries, transfer function, and matrix) which are indices used to identify a linear color transfer function. Further reading shows that the index settings of 1, 1, 1 -- which is what FCP gives us -- are for 1920x1080 HDTV (SMPTE 274M-1995). If I change them to 2, 2, 2 (all unknown) using JES Extensifier, that's probably "better" than just removing them entirely. Luckily, QT player makes the movie look right both with 2, 2, 2 and without the colr atom entirely. But Compressor needs more.
The gama atom also needs to be set to 1.8 for Compressor to also show the movie properly. What the hell, Apple? Why aren't QT player and Compressor returning identical results for identical atom settings?
Anyway, I've got the movie looking right in QT player and Compressor now. While it's not entirely an intellectually satisfying result, I'm going to run with it for now. It looks right. We can finish this movie. Thank you to Jan E. Schotsman for Extensifier tool!
Summary and conclusions:
- FCP is adding the colr atom to our ProRes 4444 movie on output, and I see no way of telling it not to (nor do I see a way of configuring it). FCP seems to assume that we are doing an HDTV project and is "helping" us by identifying such via the colr nclc atom.
- Apple apps do not seem to respect these atoms consistently. QT player does listen to colr. But the same movie in Compressor looks darker. Setting the gama atom to 1.8 in Extensifier and keeping the colr atom to nclc 2, 2, 2 makes the movie look the same (and correct) in Compressor and in QT player.
- If these atoms are NOT present and if you're using an app that expects them, the app will have to guess what you want.
- Older apps, like shake, seem to ignore these atoms entirely.
5 comments:
I've read people complaining about these bugs and trying to find where the bugs are coming from for YEARS now, and you are the first to run a real comprehensive analysis and provide a solution. THANKS sir, you are a genius.
Also it might be important to keep in mind that those guesses that FCP makes when tagging the color space according to frame size and other factors might frequently be wrong depending on the camera used.
This article is going to become very popular as the first true fix to the color/gamma shift problem in Quicktimes.
We think alike. As soon as I found the problem was with the atoms I began down the same road as you, crawling dev docs and whitepapers... but then I came upon your post! Wonderfully researched, with links to sources. The JES tool is amazing and the procedure for short-circuiting Apple's braindead processing of quicktime color is genius in its simplicity - just tell quicktime that the color is unknown so that it doesn't F**k with it.
I was worried 2-2-2 was some made up value set, but I see from your source documents that its actually a defined value in the spec for saying "anything else", which hopefully ensures that it won't become some other meaning in the future.
Thanks for the GREAT post!
Finally after so much waiting someone manages to do away with these bugs and I hope forever! Already had become annoying, and the fact that nobody does anything to stop it was something even more annoying. Thanks for this personal discovery!
Well done and thanks for doing a "Sherlock Holmes" job on FCP & Quicktime and illuminating somewhat this murky little den of ill repute. However, from my perspective as operational head of a high-end DI facility (still heavily DPX-reliant) I'd like to add my 2 cents worth which is that I more-or-less forbid FCP & quicktime to be in the "signal-path" at any point in the preparation & conforming processes for exactly the reasons raised in the blog. For me FCP is just too mendacious and secretive when dealing with (not just) colour issues. Lately I have been impressed with Resolve as a central conforming & rendering engine and distribution hub.
As soon as I found the problem was with the atoms I began down the same road as you, crawling dev docs and whitepapers.
Post a Comment