5DtoRGB Color Tests

(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).


MPEG Streamclip:

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…

and QT10…

…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.


22 responses to “5DtoRGB Color Tests

  1. Excellent write up and analysis Jerome. Its very helpful. Have you tested the workflow it it involves Color? The output of Color is of course also rendered. And one of the reasons to use 5DtoRGB is to have the maximum info to slam around in a grading session. So it seems a likely workflow for many of us doing narative stuff.

    I’m curious why you state you don’t ever use h.264? Have you written about that in other blog entries?

    • Thanks Paul. I don’t really use Color, mostly because I learned how to color correct in After Effects and slowly brought those tools and techniques into Final Cut. The kind of color correction I do for corporate work is not as demanding as the kind of stuff you have to deal with on narrative projects; I end up mostly trying to make sure the exposure is correct and that the whites and blacks are safe. I have experimented with both Color and Magic Bullet Looks, which Philip Bloom is a strong advocate of, but usually I need to stay somewhat conservative with my colors. Regarding H.264, all I can say is that it always fails me completely with my 7D footage. You can have a look at my first post on color — https://motionlifemediablog.wordpress.com/2010/06/02/which-version-do-i-color-correct/ — but I can tell you briefly that exporting to H.264 from Quicktime will inevitably give me a result one or two stops brighter than my original. I used to get really annoyed about it, but now I’ve just stopped using it. I’ve had better luck with Streamclip MP4s and AVIs (with Photo JPEG encoding) for lower res encodings.

      • Hey Jerome, I have to echo everyone’s praise for your exhaustively thorough article. I mean that of course in a very appreciative and grateful way, explanations and demonstrations like yours here help over-active minds like mine sleep ocassionally. I also have to semi-echo Mr. Nordin’s question to an extent, and ask something I posed in the comments of NoFilmSchool’s most recent article on the Rarevision utility – given you don’t much use Apple Color, do you have any idea if the rendering / round-tripping process fills the apparent requirement for rendering before exporting a clean un-gamma-dirtied master? Any light you can shed on such a conundrum is, again, much appreciated!

      • Hi Davey. Honestly, I’m not sure yet. I could definitely test it pretty easily, given that FCP and Color are so closely integrated. I think one thing that’s been interesting about these tests is that they may only be helpful to folks who use the same kinds of workflow techniques that I use. If anything needs to be conformed for broadcast, for instance, or professionally color corrected using video cards and studio-grade calibrated monitors, then it’s possible none of this matters very much. For example, what I found in my own work about five years ago is that I suddenly stopped using decks. In the same way that there are (at least) two ways to be a graphic designer today — working with inks and printers on the one hand and working purely electronically on the other — I sort of have become a purely digital video producer. I can’t remember the last time I ever had to dump to tape, or check that my footage was broadcast safe. The 7D and cameras like it have made it possible for guys like me to sort of forgo a lot of those steps, in that I can shoot something cheaply, export it to DVD, or post it online for my clients. The people I work for don’t really want more than that, but sometimes I forget that there’s a whole other world out there of people who shoot and edit for broadcast and the like. On the other hand, I don’t think it’s asking too much of Final Cut to be able to roundtrip footage accurately. I want the footage I shoot on the 7D to look the way I shot it when I view it in FCP, and then I want to color correct in FCP and export it the way it looked in the timeline. But I understand that post-production is a much, much bigger universe than that, and there is obviously a whole lot more to it than simply importing and exporting. I hope that helps. Thanks for your comment!

  2. Pingback: Zach Wise » Daily Digest for September 8th·

  3. Very good post! I spent the better part of 2 weeks on this same issue and ended up just finding a middle ground of it looking bad in FCP, but looking good in Quicktime. And this was using Color to grade, so I would say that just using Color instead of the slug filter does not do anything for you. You’d prob have to apply the slug filter to the new sequence you get from color.

    Do you ever upload your video’s to a online service such as vimeo that suggests to use H.264? I suppose you could just use the FLV as the source for that.

    • Hi Ryan,

      Thanks for your comment. A couple of thoughts: if you like the way something looks in Color, or in the FCP timeline, try exporting it from FCP as an 8-bit RGB Sheer file. They have a free demo that works for a few weeks without restrictions. It’ll look slightly wrong in the Quicktime player, but you can make a Photo JPEG AVI from it in MPEG Streamclip that for some reason will look perfect in Quicktime. I use the AVI (at 1280×720, 100% quality) to make DVDs in Bitvice only. I guess I don’t really have any other use for the AVI, since they’re usually too large to upload to YouTube or give to a client. For the web, I’ve actually started using DivX! The file gets created as a .divx, which you’ll probably need to change to .mov for YouTube and Vimeo, but it should work. The colors should look the same in the DivX player as they do in FCP, at least that’s my experience. DivX files are not without problems. The decoder conflicts with the decoder that Streamclip uses for AVIs (Perian, I think), making it impossible watch AVIs made in Streamclip. So I usually end up removing the DivX decoder from my Quicktime codec folder until I need to play something back. Also, sometimes I can play back a DivX file in Quicktime, but most of the time it won’t open and I’ll need to use the DivX player instead (with the decoder put back in the Quicktime folder). It’s a pain, but it’s worked so far with WordPress video uploads and with YouTube. I haven’t tested it yet with Vimeo. Let me know if that helps.

  4. Pingback: More 5DtoRGB Tests « MotionLife Media Blog·

  5. Pingback: Batch Processing Script for 5DtoRGB « iowadslr·

  6. Pingback: Workflow: 5DtoRGB la solution ultime pour encoder les vidéos de votre DSLR ? | Christophe MILET Video & Multimedia producer / Rich Media Consultant / For Modern Interactive Content / Bordeaux - Aquitaine -·

  7. thanks for doing all of this work and research! It sounds like your work-arounds are pretty crazy (compared to what most people are doing… which is ignoring the color differences). I would love to be able to make sure the colors stay correct, but I usually end up figuring that everyone has un-calibrated monitors, so it doesn’t matter in the long run and it often takes longer to verify color anyway.

    Since time is money, how much more time do you think it takes to go through your entire process?

    • Thanks Eric. You’re giving me way too much credit, I’m afraid. There are some jobs that I’ll export to Sheer, but I won’t do it with every job. But if it’s only a few minutes long, and I’ve spent a lot of time color correcting, then, yes, I will export to Sheer. But what I’ve found is that as long as I stop worrying over how Final Cut handles the footage coming in, and just accept that it’s a little darker in the timeline than it’s supposed to be, I can compensate for that in Final Cut, do all my color work based on how it looks in FCP, and then simply export to Sheer. It sounds like a pain, but you’re going to have to export to something, and it might as well be accurate. What I find is that I can schedule these things around the day, and not necessarily babysit the process. I should also mention that I’ve become a huge fan of DivX. If you go from Sheer to DivX, all the color work is preserved, and then that’s the file that you can upload to YouTube (you just need to manually change it to a .mov file when it’s finished). Anyway, like I said, I won’t do this for every job, but there are some that are worth the fuss. Thanks!

  8. I’ll add my thanks to the others here: nice work!

    I will also say that using the Color workflow does seem to offer more latitude when using 5DtoRGB footage: you can elevate blacks with less noise and there does seem to be a bit more ability to shove colors around before they break up than with footage transcoded using the Canon plug-in. (Plus, having come from Color you know it’s all been rendered!)

    Lastly, an answer to the “no batch capability” that works even if it’s a bit of a kludge. Run the following shell script as a shell process in Apple’s QMaster with the “working directory” set to the folder where your footage and THM files are. CASE SENSITIVE here: be careful!

    # Make sure you put the path to your copy of 5DtoRGB in the main command line
    # Replace the #3 at the main line with the menu choice you want to use for quality setting. 3 is ProRes422
    # Output may appear at the source directory or at your root directory: check both
    for movies in $( ls *.MOV )
    ‘/Applications/5DtoRGB.app/Contents/MacOS/5DtoRGB’ $movies 3

    • Thanks for the input. Another reason to go with 5DtoRGB. I’ve been using it pretty regularly for the past few months, and I’ve definitely come to rely on it.

  9. Superb story! I had the same issues with somethings else. So I want to give you some additional intel. Are you aware of the gamma correction auto/none option in the prores codec settings. This also applies to the settings of your sequence in FCP. Set it to none and your good to go!

    • Cool. I’ve since updated to FCP 7, and have been experimenting with the new version of ProRes. I am aware of that setting, but I’ve also changed cameras to the GH2, so everything has changed a bit for me. I will look into it though. Thanks!

  10. Pingback: Which Version Do I Color Correct? « MotionLife Media Blog·

  11. Pingback: ColorChooser·

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s