Thomas Worth from Rarevision has been kind enough to send me updated versions of the 5DtoRGB transcoder program to test. He continues to work on this program, and the latest version he sent me is not quite ready for release. The updates address important issues such as batch functionality and gamma flagging (he’s also included a “Bake Gamma Correction” option that will be of use to some users).
Additionally, I’ve finally installed the new ProRes Quicktime component, the one from 2009’s Final Cut Pro 7 upgrade, simply called: “AppleProResCodec.component.” The old component, called “AppleProRes422.component” dates from 2007 and came installed with Final Cut Pro 6.
I’ll keep this short (hurray!):
Something is going on with the ProRes components, even when choosing the same codec — in my case, ProRes HQ. As in previous tests, I’m always interested in seeing how the footage will look in Quicktime 7 with FCP compatibility selected, how it will look in Quicktime 10, how it will look in the Final Cut timeline, and, finally, how it will look in QT 7 and QT 10 once it’s been exported from FCP.
The footage I used this time was interesting because it was an interview shot on a white background, allowing me to focus entirely on variations in flesh tone. As has been the case everytime I’ve done these tests, I always find myself preferring how the original Canon H.264 footage looks in Quicktime 7:
Here’s the same clip in Quicktime 10:
As usual, the Quicktime 10 version is slightly brighter and desaturated.
Moving on, here’s the new interface Thomas has been working on for 5DtoRGB:
You’ll notice the new batch capture capability (drag and drop!) as well as the Bake Gamma and Add Gamma Flag options.
For the first pass, I used the old ProRes component, called “AppleProRes422.component,” the one that came installed with FCP 6. I chose not to add a Gamma Flag or to Bake Gamma Correction. Here’s Quicktime 7:
And Final Cut:
So, as I’ve discovered the last few times I’ve done this test, the 5DtoRGB footage, once imported into the Final Cut timeline, actually retains the color values of the original Canon H.264 footage as it appeared in Quicktime 7 (with FCP compatibility checked). It doesn’t look right in Quicktime 7 (brighter and desaturated) or Quicktime 10 (it’s close, but slightly darker and desaturated), but I don’t care, because it looks perfect in FCP, and that’s where I’ll be doing my editing and color correction.
Problem solved, right? Not exactly. Here’s the same test, with the newer ProRes component in my Library/Quicktime folder, the one called “AppleProResCodec.component” that came installed with FCP 7. Remember, I’m choosing the ProRes HQ codec for all these tests.
Final Cut timeline:
Everything’s different now — the footage is darker in all the versions. My settings in 5DtoRGB remained constant for this test: no gamma flagging. The only variable in the test was the newer version of ProRes.
Keep in mind, I’m still running Final Cut Pro 6. However, I have a hard time believing that this issue simply disappears with FCP 7. Whatever is happening to the footage is happening in the Quicktime file itself, and is not effected, I believe, by how Final Cut is interpreting the footage.
There was one setting that I needed to test in Final Cut though, just to be sure I wasn’t missing something. In Sequence Settings, you now have the option with the latest version of ProRes to automatically correct for gamma or to leave it as is (“None”).
I tried both settings in Final Cut, and it made no difference to how the footage appeared in the timeline, leading me to believe that whatever happened to the ProRes footage already happened before it was imported into FCP.
Thomas asked me to test out various combinations of gamma settings in 5DtoRGB, and I did. You can add a Gamma 1.8 flag or a 2.2 flag. You can Bake Gamma into either option. Trust me, I tried them all. “Baked Gamma” made the guy in my footage look like he had just spent a week in a tanning booth:
I even tried ProRes LT, a codec that Philip Bloom recommended using in his workshop.
Not only did it not make a difference (the footage was still too dark), but the file size ended up larger than the ProRes HQ version, which I thought was extremely strange, given that the LT version is supposedly smaller without any noticeable quality loss.
Come to think of it, the file sizes of my clips varied wildly depending on whether or not I attached a gamma flag or “baked” any gamma into the footage. My advice: best to keep the 5DtoRGB gamma setting at “None.”
What about using MPEG Streamclip with the newer version of ProRes, you ask? It looked exactly the same — darker and warmer, what I’ve been trying to avoid all along — in the Final Cut timeline regardless of whether I used the older version of ProRes or the newer version:
So, it’s not precisely true that the issue is only traceable to a variable in the ProRes codecs; 5DtoRGB is also reacting differently to the two versions of ProRes, whereas Streamclip simply ignored the differences. Thomas is looking into this development, but he’s not sure he’ll be able to find a workaround.
Bottom line: the new 5DtoRGB updates, especially the batch function, will make for a better transcoder. But I am having a problem with the newer ProRes codec that came installed with FCP 7. My solution, while definitely not ideal, will be to do all my transcoding with 5DtoRGB going forward, but to keep the old ProRes codec (“AppleProRes422.component”) installed in my Library/Quicktime folder.
Want more good news? Whatever updates Thomas has made to the program has fixed the export issue I was having. Whether you send your footage out to Sheer 8-bit RGB (my favorite export codec) with a “slug filter” or whether you send it out with no render at all, the footage (once it’s been converted to a Photo JPEG AVI at 100% quality in Streamclip) ends up matching the original Canon H.264 footage whether it’s viewed in Quicktime 7…
…or Quicktime 10:
Here’s the original Canon H.264 footage in Quicktime 7, just for reference:
It may not be a very elegant solution, but it’s the only 100% accurate roundtrip solution I’ve been able to find, and it does work!