5dvspremierepro-224x126Months ago here on No Film School I tried to call attention to a little-known DSLR plugin in development known as 5DtoRGB. 5DtoRGB is a software plugin from Rarevision similar to Canon E1, MPEG Streamclip, and Magic Bullet Grinder in that it is designed to transcode your DSLR footage into something that's eminently more editable. 5DtoRGB claims to offer the highest quality output of all of these options, but despite my posting about the plugin repeatedly, I could do no actual tests with it since my lowly laptop was restricted to 32-bit processing (5DtoRGB requires a 64-bit processor). Now that I've successfully built a 64-bit hackintosh, however (the how-to article is coming soon!), I was looking forward to putting the plugin to work. But I was beat to the punch by No Film School regular Robin Schmidt, who has done some great tests of his own, and as a result the word is out; now even 24 DP Rodney Charters is tweeting about 5DtoRGB. So now that we have our hands on the plugin, what's the verdict?

For Final Cut-based editors, I'll defer to Robin, given I'm transitioning to Premiere Pro CS5 because of its ability to edit DSLR footage without transcoding. From two great comparisons, the first entitled 5D To RGB – New Transcoding App Tested and the second 5D To RGB The Follow Up: Bigger Comparison, Robin draws the following conclusion:

It’s an epiphany… Holy crap, this thing is unbelievable! The first thing you notice is just how insanely smooth the footage is, it looks alive, preserved and ready to grade. In other words it is in a completely different league to the footage from MPEG streamclip. First, it’s lifted the gamma and given me a flatter image and more dynamic range. Compare the grabs below. It’s also had the unexpected benefit of fixing some (not all) of the moiré issues.

He's not overselling it; you can clearly see the differences he speaks of in his example clip:

To my eye, he's exactly right: the 5DtoRGB clip solves the Quicktime gamma issues I've harped on in the past, and does indeed also seem to offer a bit of moiré correction thanks to its chroma smoothing. It looks so much better than the native file that I found myself thinking, "they're going to sell a boatload of copies of 5DtoRGB." But then Robin's second test came along, and the results are much less clear cut. I'd recommend heading over to read his full post, but when converting to ProRes 422 (a lossy codec that yields smaller files than the lossless 4444), Robin reacts:

To be honest with you, I don’t really know what I’m looking at here. Everything looks pretty much the same as everything else although I’d have to say there’s a marginal preference for the 5DtoRGB result. This is not what I expected. I fully expected the 5DtoRGB to wipe the floor with everything else. So what conclusions can we draw from this?... I have no idea but what I do know is that I will certainly be putting the time in to test a clip from my future projects through 5DtoRGB at 4444 to see whether it improves them for final mastering (I suspect it probably will).

Indeed, the workflow I had in mind before I actually had a chance to use 5DtoRGB was to edit the camera originals natively in Premiere Pro, and then, once picture is locked, go in with 5DtoRGB and only transcode the files that are actually being used in the edit. Sort of an online/offline workflow. I was planning on putting this to work next week, as we're shooting a bit of a teaser in preparation for our participation in Independent Film Week's Project Forum. But once I saw Robin's dramatic results I decided to quickly hop outside and shoot a brief clip of some horizontal lines to see if 5DtoRGB offered any real moiré correction. What I found was surprising: compared to Robin's stellar results in Final Cut, I can see very little difference whatsoever in Premiere Pro. Granted, this is not a staged or lit shot -- I intentionally picked some vinyl siding to film handheld because the strong horizontal lines and texture of the wall would wreak havoc with the aliasing issues inherent to my 5D Mark II. The handheld shot ensures that the ugliness will stand out, and as you'll see, it does. But the colors, gamma, and moiré are virtually identical in the two clips, to my eye. Be sure to click the full screen button, and watch the window air conditioner on the right; you'll see it seems equally jagged in both versions:

Looks exactly the same, right? If you have a Vimeo account you can click through to the video and download a Quicktime for a better look. And despite the fact that this is re-encoded to h.264 web video, I did export the clip to ProRes 4444 and view it at 1:1 pixels -- and I still couldn't tell the difference. Still, while this is very obviously the quickest-possible preliminary test and I don't want to draw any conclusions, it does beg the question: Is editing natively in Premiere Pro CS5 better than "up-transcoding?" Are there any advantages to transcoding, either before editing or as part of a finishing process? According to Adobe's own Karl Soulé:

Inside Premiere Pro, the images will stay exactly as they were recorded in-camera for cuts-only edits. If there’s no color work going on, the 4:2:0 values remain untouched. If I need to do some color grading, Premiere Pro will, on-the-fly, upsample the footage to 4:4:4, and it does this very well, and in a lot of cases, in real-time. Going to a 4:4:4 intermediate codec does have some benefits – in the transcode process, upsampling every frame to 4:4:4 means that your CPU doesn’t have as much work to do, and may give you better performance on older systems, but there’s a huge time penalty in transcoding. And, it doesn’t get you any “better color” than going native. Whether you upsample prior to editing or do it on-the-fly in Premiere Pro, the color info was already lost in the camera.

At this point I'm thinking, "I'm convinced. Native editing in Premiere Pro offers the best quality, without transcoding through 5DtoRGB." But taking a trick from Rarevision's book, where they zoom in at 800% on their web site to illustrate the difference, lo and behold: there is a difference. Here I've zoomed into the red bike (red is a notoriously difficult color for video compression) at 500%. This image should animate between the two, watch the center of the image:


The smoother image is 5DtoRGB, and the blockier one is Premiere Pro (both were exported from Premiere Pro as uncompressed images). Given the color and gamma seem identical, I get the impression that Premiere Pro doesn't exhibit some of the color inconsistencies that Final Cut does. In fact, the only advantage I can see is likely due to 5DtoRGB's chroma smoothing. Will you ever notice this difference for web video? No. Would you notice it in a theater? Probably. More on this as I do more shooting and editing.

One final note on 5DtoRGB, and this is mostly for Rarevision, since the plugin is still in beta. Here is my CPU utilization while using the plugin to transcode a clip (listed to the right of the username, i.e. "Koo"):


The plugin didn't use multiple cores, and it seemed to max out at 75% CPU utilization. By my rough calculations, with a quad-core processor, this means it used just 20% of the total CPU power available. I realize that it's rare in practice that any application uses every processor core to its fullest -- but as a point of comparison, exporting the clips via Premiere Pro to h.264 utilized 450% of my CPU. So whereas many folks are noting the relative slowness of 5DtoRGB compared to other transcoding solutions, I imagine there's a lot of room for improvement.

If you're a Final Cut-based editor and you need to use a transcoding application from the get-go, 5DtoRGB is a strong contender -- especially once Rarevision gets batch processing working. For Premiere-based editors, it looks like the workflow I'd imagined before even trying 5DtoRGB will indeed be the best. Which is to edit natively in Premiere Pro -- save the hard drive space and time you would've spent transcoding -- and then if you're concerned with the absolute best quality output, transcode with 5DtoRGB as part of the finishing process.