(Please read an update to this post from September 28th regarding additional tests)
I was preparing to write a new post revisiting color correction issues in Final Cut Pro when news of Rarevision’s 5DtoRGB HDSLR transcoder broke on the internet. If you haven’t heard about 5DtoRGB yet, an excellent place to start would be Matt Jeppsen’s article on Provideo Coalition. I’ve downloaded the program, and have done my best to test it over the past few days. The tremendous interest this software has engendered in less than a week’s time speaks to the enormous demand in the video community for a tool that may finally, among other benefits, lock in accurate color space information throughout the entire post-production workflow.
Before we look at how the 5DtoRGB transcoder handles color, it’s important to keep in mind that Rarevision is mostly claiming that its software will improve overall picture quality, restoring some of the detail lost to artifacting and noise in Canon’s H.264 compression. As they write on their website:
[5DtoRGB] also recognizes Canon’s full range 8 bit YCbCr values (0-255), avoiding clipping and the resulting loss of picture information. The resulting files are the absolute highest quality you’ll ever get out of the camera. In fact, you could argue that they’re even better than the camera originals since they’ve undergone high quality chroma smoothing (which you can disable if you want, but you shouldn’t).
Rarevision does make claims to more accurate color, but first and foremost it’s being marketed as a way to squeeze every last possible drop of detail and sharpness out of Canon’s H.264 footage. For the purposes of this post, however, I’ll be focusing on how the software handles color. I will say this about the claims of improved detail though: in my limited tests thus far, there does seem to be slightly less noise in a 5DtoRGB ProRes HQ frame grab viewed at 400% in Photoshop than there is in the MPEG Streamclip ProRes HQ version (there is also a color and brightness shift, but we’ll deal with that momentarily).
You can click on both images to see them in close up. On Rarevision’s site, they specifically address the issue of noise, writing:
To add insult to injury, QuickTime adds noise to its H.264 output (and so does any program that uses QuickTime to decompress H.264) in what looks like an attempt to cover up H.264 compression artifacts. And guess what? There’s no way to disable this.
What they don’t say is that removing this noise actually reveals artifacts that went unnoticed before, so I’m not sure whether it’s a huge improvement.
But, like I said, for this post I’ll be concerning myself with color. A few months ago, I wrote a post called “Which Version Do I Color Correct,” and in it I discussed the various ways that colors in HDSLR footage can shift depending on whether the clips are being viewed in Quicktime 7 with Final Cut compatibility selected (the last preference on the bottom),
in Quicktime 10, or in the Final Cut Pro timeline. The biggest problem this presents editors is trying to determine which version of your footage is the master from which to base all color correction. Before I really spent time investigating this, I had never realized, for instance, that ProRes footage looked different in Quicktime 7 with FCP compatibility selected than it looked in Final Cut itself. I had always assumed that the footage would look the same in both programs. This is obviously a huge problem: if you’re trying to color correct based on how your footage appears in Final Cut, when you export out to Quicktime you’re not going to get the same colors.
So the biggest question I had when I heard about the Rarevision transcoder was how the footage would appear in the Final Cut Pro timeline.
Whenever discussing color shifts, in my experience it’s best to look at skin tones. Without having flesh tones to compare from version to version, it’s almost impossible to make an objective decision about whether or not you’re experiencing unacceptable color shifts. With that in mind, here are three screen shots from recent interviews I shot on the 7D. All three screen shots were taken directly from the unaltered H.264 original footage, but it’s important to view them in both Quicktime 7 with Final Cut Pro compatibility selected as well as in Quicktime 10 (there’s no point viewing them in Final Cut; we’re never going to edit any Canon footage without converting it to ProRes first).
Looks good in QT7 with FCP compatibility:
Looks washed out in QT10:
None of this is news to me at this point. In fact, it’s all familiar territory. Now here’s the ProRes HQ footage encoded in MPEG Streamclip. For these examples, we’ll definitely need to see how it will look in Final Cut.
Darker than QT7 but not as dark as QT10. As I mentioned in my post from this past June, I had never really paid much attention to the differences between the QT7 footage and the Final Cut footage, but once I started noticing, it drove me nuts. I wanted to work with the footage as it appeared in QT7, not Final Cut.
Moving right along, let’s have a look at the 5DtoRGB footage. The first thing I noticed is a separate application called dMatrix, which seems to be Rarevision’s answer to the RAW adjustments available to RED users. dMatrix literally let’s you tweak the red/green/blue values of your footage and save those adjustments as an exportable profile. Very cool. It also displays your footage in two RGB color spaces: BT.601 and BT.709.
You’ll notice that in BT.601, the footage looks identical to both the original H.264 frame in Quicktime 7 as well as the MPEG Streamclip frame in Quicktime 7.
The BT.709 footage is interesting and rather pleasing to the eye — bumping up the brightness of the reds in particular — but for the purposes of these comparisons, I’ll export all my footage from 5DtoRGB in BT.601 only.
Okay, that’s dMatrix. I won’t be creating any profiles right now because I want to see exactly what the footage will look like in Final Cut without any color correction whatsoever. Here’s the 5DtoRGB interface:
Once you select a color space — in this case BT.601 — your next decision is whether or not to encode in Gamma 1.8 or 2.2. Let’s look at both. As before, let’s also make sure to view the screen grabs in Quicktime 7, Quicktime 10, and Final Cut Pro.
By the way, there’s no batch processing option for converting all the footage from your compact flash card! I assume this will be addressed in updates to the beta.
QT7, Gamma 1.8:
Washed out, with a color shift, and maybe a stop brighter. Interesting. Also, am I seeing more imperfections in the subjects’ faces? Of the two Quicktime players, this is the one that’s supposed to best approximate Final Cut Pro’s color space, so we’ve already got a problem.
QT7, Gamma 2.2:
I can’t see any difference between 1.8 and 2.2 in QT7.
Now Gamma 1.8 in QT10:
The Gamma 1.8 grabs are identical to what I was seeing in QT7 — washed out with a color shift and a stop brighter. But the fact that these clips look identical in both Quicktime players is a bit of a red flag. Where is the Final Cut compatibility compensation in Quicktime 7?
Now, Gamma 2.2, in QT10:
The brightness issue is fixed, but the image has still color shifted compared to what I liked in the original H.264 and Streamclip ProRes versions when viewed in QT7. Here is the original H.264 of clip 3 in QT7 again, just as a reminder:
Anyway, before we get too hung up on these various brightness and color shifts, let’s bring the 5DtoRGB clips into Final Cut. That’s the test I really want to see.
FCP, Gamma 1.8:
Holy cow! Eureka! Mr. Watson, come here! I need you! Is this the holy grail of color accuracy within Final Cut? Apparently so — the footage in Final Cut Pro looks exactly the same as the original H.264 footage looked in Quicktime 7.
That’s big news.
The Gamma 2.2 frame grabs give you exactly the same result. Perfection. Going forward, because my Mac is calibrated for Gamma 2.2, I’m going to go ahead and choose Gamma 2.2 as an option in 5DtoRGB instead of Gamma 1.8. But let’s reiterate: Rarevision has solved a HUGE issue — getting the original H.264 footage to look exactly the same in the Final Cut Pro timeline!
The final piece of the puzzle is exporting the Gamma 2.2 timeline from Final Cut Pro back into Quicktime. Because we’ve seen what Rarevision footage looks like in QT7…
…we already know this isn’t going to work without re-encoding the timeline somehow.
The first export I attempted was the solution I recommended in my older post: exporting to Bitjazz Sheer’s 8-bit RGB codec.
Except this time it didn’t work. There’s no brightness shift, but, just as we saw when we exported 5DtoRGB footage from the timeline and viewed it in QT10, we’ve lost some color in the flesh tones. His skin is definitely redder now.
I tried exporting in all sorts of codecs, including Animation, None, and 8-bit Uncompressed — and they all looked the same, i.e., redder flesh tones (except in the 8-bit Uncompressed version, which had redder flesh tones and a brightness shift).
So something else must be going on. And that’s when I noticed that the same color shift was actually occurring within Final Cut, as soon as you enter into Quicktime Conversion mode:
You can actually see the color shift happening within Final Cut each time you choose Quicktime Conversion.
Needless to say, there’s no point using a specialized transcoder if your colors look perfect in your Final Cut timeline but can’t retain color consistency when exported. If that were the case, all your work in Final Cut would be for naught.
Luckily, that isn’t the case. I added a random filter — any filter will do the trick, as long as it requires a render — and set its strength to zero. Call it a slug filter, if you will. The next time I exported to Sheer 8-bit RGB…
…I was back in business. Is this a problem? Sure it’s a problem. While many clips in your timeline will certainly get filters applied, some won’t, and if you export footage that hasn’t gone through a render step within Final Cut, you’ll get a color shift no matter how you export it. Essentially, in order to get accurate colors from your Final Cut exports, you’ll need to render all your timelines with what are essentially slug filters.
That’s the bad news. The good news is this is probably fixable in future versions, and, more importantly, it works! Kudos to Rarevision.
From this point on I’ll just do what I wrote about previously:
— use Quicktime Conversion within Final Cut to export a Sheer 8-bit RGB codec version of my project (remember, if you simply export a ProRes file, you’ll get a color shift!)
— use the Sheer version to create a AVI file at 100% quality within MPEG Streamclip
— use the AVI to create a DVD using Bitvice, not Compressor
— use the Sheer version to create an FLV using Adobe’s FLV encoder
That just leaves one file type that I haven’t been able to create without color shifts: the low res version for client approvals. Unfortunately, I don’t have a solution for that one yet. In general, I try to avoid H.264 exports at all costs, and these days I’ve been using the MP4 export option within Streamclip. But the results have not been satisfactory. Every once in a while I’ll even give Windows Media a try. DivX too. With low res files, the best approach seems to be trial and error (speaking of DivX, by the way, it’s not bad. I’m going to test it in the future on some YouTube uploads).
So, in summary, congratulations are in order to Rarevision for creating a transcoder that will protect the colors of the original Canon H.264 footage (and supposedly decrease the noise and improve the quality of the footage to boot). Unfortunately, there’s no batch processing function — not yet, anyway — the encoding times are much longer than Streamclip’s (and without a batch function, you can’t convert your footage overnight), and unrendered footage inside the Final Cut timeline exports with a color shift — a quirk that can only be corrected by applying a filter to the timeline that requires a render.
But assuming that Rarevision adds a batch function and addresses some of the minor color shifting issues, I will definitely be buying this software once the beta period expires.