GH2 5DtoRGB no matter what?

Sttratos

Veteran
I have never used 5DtoRGB but have always heard great things about it. But should I use 5DtoRGB on GH2 footage no matter what? I use Flowmotion V2.02.
Since I also usually shoot with the AF100 recording DNxHD, 5DtoRGB's ability to convert GH2 files to DNxHD looks interesting for me. Does 5DtoRGB apply any LUTs or does anything to change your image or it only converts to another format? Because I'm going through a lot of work to match the AF100 and GH2 and would hate if 5DtoRGB would mess this match up. I don't think I should run the AF100 footage through 5DtoRGB since it's already 10 bit 4:2:2 DNxHD.

Another thing I couldn't find in rarevision's site is if 5DtoRGB does pulldown removal? Thank you.
 
I have never used 5DtoRGB but have always heard great things about it. But should I use 5DtoRGB on GH2 footage no matter what? I use Flowmotion V2.02.
Since I also usually shoot with the AF100 recording DNxHD, 5DtoRGB's ability to convert GH2 files to DNxHD looks interesting for me. Does 5DtoRGB apply any LUTs or does anything to change your image or it only converts to another format? Because I'm going through a lot of work to match the AF100 and GH2 and would hate if 5DtoRGB would mess this match up. I don't think I should run the AF100 footage through 5DtoRGB since it's already 10 bit 4:2:2 DNxHD.

Another thing I couldn't find in rarevision's site is if 5DtoRGB does pulldown removal? Thank you.

5DtoRGB has options to apply some limited filters (like a gamma correction, if I recall), or you can just leave it as a direct conversion. Whether or not it is necessary or makes any difference at all ultimately depends on your NLE setup.

On Mac-based systems in particular, running editing software that rely heavily on Quicktime (such as FCP), it will give a cleaner and more accurate picture. This has less to do with any kind of "magic" from 5DtoRGB, and much more to do with some buggy decoding on behalf of Quicktime.
There is a well documented gamma shifting bug that will crush your blacks and clip highlights earlier than it should when directly importing footage (see the saxophone player in the field example here) and it has been shown that in some cases, the color translation from yCbCr to RGB that Quicktime uses creates jagged artifacts (in particular, the red channel from Canon cameras).
5DtoRGB does not rely on quicktime to do its conversion, rather it uses its own algorithm that avoids all these problems and produces almost universally-accepted footage that your NLE can import without problems.

But here's the kicker- not every system relies on quicktime, and therefore would not necessarily benefit from 5DtoRGB's "fix". Someone using Premiere on a PC-based system, for example, may not find any noticeable difference.


Short answer: Its complicated.
 
Short answer: Its complicated.

Have to agree. I tried out a few conversions a few months back and I could see a difference between Log and Transfer in FCP. The best transcodes I was getting though were going through Blenders Compositor as a sort of primary grade and going out to image sequences from there. Huge amount of work though.

For me it came down to either working fast ( FCP ) or getting the best quality, which equals a lot of time ( Blender ).

It seems a lot of people use 5DtoRGB and evidently get good results, so I guess it comes down to what platform and editing workflow you're already using, whether this will work for you.
 
Not sure why this is but when I used 5DtoRGB the material did not perform as well as ProRes converted inside of FCPX. And yes both were normal ProRes and not HQ or 444. Both running off the same media drive. I think perhaps it was a fluke but just something I observed once.

I typically use CS6 and it already unpconverts AVCHD material to 32bit float and 4:4:4 color on the fly while editing so there is very little reason for me to use 5DtoRGB outside of perhaps scrubbing performance. Although ProRes never worked as slick in CS6 as I would have expected.

In FCPX it has been a different story for me. As annoying as it is to still convert to ProRes I find it a night and day difference in performance with the ProRes skimming like butter. For my FX heavy project I am currently working on chances are I will use CS6 due to the dynamic linking with After Effects. If I were to use FCPX and Motion however I think I would use 5DtoRGB to convert to 4:4:4 because it does make a difference.
 
I'm on Windows, not Mac.
I only asked because I need a way to convert all my video to DNxHD for editing anyway, and since 5DtoRGB does that and I have always heard so much buzz about how good it is I thought I might as well use it. But I want to know if it will just convert the file to DNxHD or if it does anything to it. I'm thinking it probably does something to it, otherwise why would people rave about the files looking better after? If it does something to the files, I wonder if I would have to run my AF100 files through 5DtoRGB too to match?
 
I'm on Windows, not Mac.
I only asked because I need a way to convert all my video to DNxHD for editing anyway, and since 5DtoRGB does that and I have always heard so much buzz about how good it is I thought I might as well use it. But I want to know if it will just convert the file to DNxHD or if it does anything to it. I'm thinking it probably does something to it, otherwise why would people rave about the files looking better after? If it does something to the files, I wonder if I would have to run my AF100 files through 5DtoRGB too to match?
Its not as much that it "does something" as it is that it works around some known bugs NLEs have converting color space. To get technical, quicktime has a gamma shift bug, and I believe uses a fast nearest-neighbor algorithm to convert to RGB. That saves CPU time, but pixel peepers will notice a difference versus a more complicated algorithm. 5DtoRGB uses lanczos to convert color space, which is slower but ulrimarely won't exhibit the same issues. Technically, people use it as a fix for a problem they may or may not have.

It has been argued that NLEs such as Premiere Pro already use similar algorithms to 5DtoRGB, and therefore will not benefit from it as much. I say try it and see if you notice a difference.
 
I've been burned by FCP7 introducing encoding errors into the footage, requiring a re-transcode of some clips. Never had this happen with 5DtoRGB or Magic Bullet Grinder, the two apps I commonly use to transcode.
 
Is there any point me using 5DtoRGB instead of importing direct to Prem?

No. Premiere will decode the .MTS file internally and won't encounter any QuickTime gamma bugs or the like. Plus, it'll upconvert the colorspace. Best bet is to use Premiere with native .MTS files.
 
Its not as much that it "does something" as it is that it works around some known bugs NLEs have converting color space. To get technical, quicktime has a gamma shift bug, and I believe uses a fast nearest-neighbor algorithm to convert to RGB. That saves CPU time, but pixel peepers will notice a difference versus a more complicated algorithm. 5DtoRGB uses lanczos to convert color space, which is slower but ulrimarely won't exhibit the same issues. Technically, people use it as a fix for a problem they may or may not have.

It has been argued that NLEs such as Premiere Pro already use similar algorithms to 5DtoRGB, and therefore will not benefit from it as much. I say try it and see if you notice a difference.


I'm actually editing on avid media composer, so I need avid codec.
 
I'm actually editing on avid media composer, so I need avid codec.

Gotcha.
So, I guess it depends on how Avid is handling the conversion of those files internally. Final Cut is notoriously bad at their own encoding to ProRes, hence the original inspiration for the app. DNxHD was added as another option since it is free and cross platform, for folks who aren't using FCP and therefore would rather NOT use prores. It is arguable as to whether or not it makes enough of a noticeable difference (or any difference at all) in other situations.

I'm not familiar with how Avid handles this, so maybe you should do a little pixel-peeping experimentation of your own?
 
Back
Top