Tuesday, October 25, 2011

Caldera grading, Apple Color, and framerates

I'm very happy to report that we've begun color grading on the new short Caldera. It's a real treat to be finessing it at this level, as each shot is absolutely gorgeous. Let me share a still before I get to the geekier point of this post.

Now, Caldera is natively a 24fps production, however, when we dragged our Apple Prores 4444 QT clips into Color it locked the project framerate to 23.98 for no apparent reason. The number appears in what looks like an editable value box, but you just can't edit the value. Of course this throws a wrench into our pipeline, which involves grading and then reconnecting to the graded .mov files inside FCP. FCP doesn't like it (properly so) when the key properties of a .mov file (rate, duration, etc.) change after a reconnect, so it is very unhappy when I try to swap a 23.98 file for a clip it's expecting to be at 24.

What a pain. Luckily, some simple hackery seems to have fixed it. The actual Color project is itself a folder, and one of the items therein is an XML file (in our case, called "calderaGrade.pdl"). The top of the file looks something like this (note I had to paste an image because I can't figure out how to get the XML tags to pass through blogger... sorry!):

A screengrab showing the XML tags in one of Apple Color's pdl files. Note that the framerate in this image has already been changed from 23.98 to 24 fps.
As you might guess, changing the tag to 24 and restarting (AND rerendering) seems to make 24fps files just as we hoped. Phew. This narrowly averted my having to take the movies through an extra Compressor pass like I had to do on The Incident at Tower 37 (see here for some of the gory details of that conforming process).

More to come as we push the film through these last phases of production!

Sunday, September 18, 2011

Bit Films Fall 2011 internships announced!

Come one, come all - we've got some great positions to fill on Bassam Kurdali's open film TUBE, and applications are due in a week! We need animators, 3D generalists, and simulation/rigging experts.

Thanks in advance for sharing this with whoever you think might be interested.

Wednesday, August 24, 2011

Final Cut exports look different from the sources!

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.

Monday, March 21, 2011

The Incident at Tower 37: online!

Tower 37 is a ten-minute animated short film that was produced collaboratively at Hampshire College and has spent the past two years in film festivals worldwide.

We are releasing it online today, World Water Day, to bring even greater attention to humanity's role in creating and perpetuating this planet's critical water issues. Our film is allegorical, but the challenges we face are real.

Please enjoy, and share! Here are some links to more information and resources related to the film, its making, etc:


TakePart.com has a recent interview with me and suggests ways you can take action, like donating to Water.org and giving up bottled water (especially those single-use plastic nightmares).


Tower 37 was created within the unique undergraduate animation curriculum at Hampshire, which offers a mix of individualized and collaborative instruction. You can get a taste of animation at Hampshire from a recent demo reel, reading a bit about our program, and/or by following the video journey of a final-year interdisciplinary Hampshire animation student.

Bit Films offers spring, summer, and fall internships for current students and recent grads who want to work on films like Tower 37. Watch the Bit Films website for details. You can also peek at the two amazing projects we're working on at the moment, Caldera and Tube, at their respective sites.


If you're interested in the ins-and-outs of producing and/or distributing a project like this, There's a long history of Tower 37-related posts on this very blog.
Tower 37 was produced using the open source web-based production management and support system called HELGA. We're looking for developers!

Wednesday, March 2, 2011

Three weeks of trivia

I'm posting daily trivia questions about Tower 37 on Twitter as a way to keep myself busy before the upcoming release. There's a #tower37 hashtag you can search on if you want.

These include some never-before-seen treats, like deleted scenes, concept art, etc.

Tuesday, February 22, 2011

Tower 37 release - one month away!

I am happy to report that on World Water Day, March 22, 2011, we will be releasing The Incident at Tower 37 online for all to see. Watch this space, the Bit Films website, Facebook, and/or Twitter for details as that day approaches.

World Water Day is a wonderful opportunity to share the film globally given its commentary on the relationship between humanity, water, and the Earth's other inhabitants. Please help us build an audience and grow the conversation by sharing your ideas of people, organizations, websites, blogs, email lists, and more that should know about the film!

Tower 37 color script paintings circa 2006-2007

Friday, January 7, 2011

Bit Films Spring 2011 Internships

If you follow the Bit Films story, then you definitely know about our internship program. If not, it's a great way to participate actively on a high-end, independent animation production under the tutelage of experienced mentors and artists. We've just posted the call for applications for our Spring 2011 session:

** One project, Caldera, is nearing completion! This is your last chance to be involved with this film!

Applications due via email on January 31st, 2011.