So
"Caldera" is nearing completion, and it's looking terrific. Gorgeous, in fact. But it's not done yet, which means that life should be returning to this blog. Because in the final weeks of production come the nasty little problems that make directors and editors wonder why the hell they got into this business in the first place...
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.
