GH2 Is there a reason to use 5DtoRGb on Windows?

[M. Gilden]

I don't know which one 5DtoRGB uses, but it's clearly not "nearest neighbor". Most likely it's bicubic, it seems some of the software - like the prores conversion - is based on ffmpeg code. You can ask or PM Thomas Worth if you want details. But maybe sometimes you want nearest neighbor, or mitchell, x,y,z algorithm (they all have pros/cons - for example lanczos4 can produce aliasing and oversharpening) - but the point is you have no control over that in AE, and it defaults to (probably) the worst algorithm. Even photoshop will use bicubic as default for resizing.




Yes, but see the previous comment on "in practice" and actual usable information. But the facts are clear on the science side - all values of RGB are represented by Y'CbCr color model, but the reverse is not true.

Cool. This is worth experimenting with. So essentially, Y'CbCr has a wider range of values than RGB, and if AE worked in that color space, it would technically be preferable to keep that during our effects layering, right? So, its not the conversion to RGB that makes 5DtoRGB fans prefer it, but rather a problem with the way AE handles y'CbCr color on its own?

Additionally, are we sure this is still true with their Mercury engine? Since they are sort of catering more towards DSLR users, perhaps they tweaked how color is converted as well. Although I admit that's a longshot.

Fascinating stuff, learning a lot right now.

 

[Kholi]

And I did say a few times that we saw a slight (define that for oneself) difference, enough for us to stick to our normal workflow of DPX conversion.

But now that the conversion topic's been expanded on... makes me think that you'd get better results if Resolve worked with AVCHD footage natively.

 

[PDR]

Cool. This is worth experimenting with. So essentially, Y'CbCr has a wider range of values than RGB, and if AE worked in that color space, it would technically be preferable to keep that during our effects layering, right? So, its not the conversion to RGB that makes 5DtoRGB fans prefer it, but rather a problem with the way AE handles y'CbCr color on its own?

Yes, Y'CbCr has wider range of values than RGB .

If you're a "math" guy and like equations and models, scroll down to the middle of this page, and look at how the RGB "cube" is fully contained within the Y'CbCr "cube"
http://software.intel.com/sites/products/documentation/hpc/ipp/ippi/ippi_ch6/ch6_color_models.html

But it's the choice of method of RGB conversion (not just the upsampling algorithm) that can cause differences, and the associated actual math equations defining those models that limit Y'CbCr=> RGB conversions. For example a Rec709 conversion will be different than a Rec601 or Rec1361 conversion to RGB.

But the fact is just about everything else works in RGB - compositing programs, our displays and monitors, equipment , still photos, etc... We live in a RGB world. (yes, LAB and CMYK, but RGB is predominant by far)

Additionally, are we sure this is still true with their Mercury engine? Since they are sort of catering more towards DSLR users, perhaps they tweaked how color is converted as well. Although I admit that's a longshot.

MPE doesn't affect AE.

Premiere is a different story. It has "YUV" labelled filters that can access YUV (YUV is analogous term to Y'CbCr), but internally it still works in RGB (actually BGRA)

 

[Kholi]

Meanwhile, yeah, if you don't have the latest CS or latest Sony Vegas (also now uses their own engine for DSLR footage), than a workflow that includes 5DtoRGB makes a lot of sense. Also, if your current workflow is working for you, there's really no reason to change anything. But be aware of why it makes a difference for you, and might not for someone else before you go recommending it all over town.

Or people should try it themselves to find out what works for them? Instead of discounting someone's personal experience as placebo effect?

 

[ErikTande]

Here's some GH1 source greenscreen footage for you guys to test. Shot with the 40 mb hack with the 14-42 lumix lens, auto focus is on. Lighting is ok, the screen is see-through and she's wearing a green tie. Enjoy > I'll leave the link up for about a week. *edit*link down.

 

[M. Gilden]

Or people should try it themselves to find out what works for them? Instead of discounting someone's personal experience as placebo effect?

Hey now. No reason to get like that.

 

[maarek]

You're still trying to pull a key from 4:2:0 versus converting color to 4:4:4, then smoothing, then keying. If you work in a VFX environment, that's just a given.

Dont' see why people can't just do it instead of guessing...

Converting the files to dpx doesn't help there. You still need to do the 4:4:4 conversion, smoothing and keying. It makes no difference to AE does it come from the original AVCHD or converted DPX.

It seems like you are implying that DPX conversion suddenly smoothes out the original 4:2:0? It doesn't. People convert to dpx because it fits their workflow (for example Scratch) not any perceived increase in quality. We usually convert everything we do vfx wise to the DPX format. Even RED material. But just because it fits our image sequence based workflow. And dpx is basically the standard.

But we can also just import a 4:2:0 file to AE, smooth out the kinks and do a key. No difference in quality, conversion or not.

 

[Isaac_Brody]

Hey now. No reason to get like that.

Seems funny that in a thread specifically asking about what effect 5DtoRGB has on GH2 footage that you would discount the experiences of people using it. The original poster asked for feedback, and he's gotten it. Why you would post contrary to that experience when you haven't used the software isn't entirely constructive, especially to discount something as a placebo effect. Not knocking you, just saying that your phrasing and choice of words seemed a little dismissive and I think people were responding to that.

I myself use 5DtoRGB on Windows. It works and it works really well. You do gain a quality bump whether you're using it on Canon footage, and especially GH2 footage. The biggest gain I've gotten besides a more linear flatenning of the color curve is that it gives me consistency between moving between programs, and it cures that horrible crunched AVCHD gamma curve that you get from programs improperly handling AVCHD material.

 

[PaPa]

Seems funny that in a thread specifically asking about what effect 5DtoRGB has on GH2 footage that you would discount the experiences of people using it. The original poster asked for feedback, and he's gotten it. Why you would post contrary to that experience when you haven't used the software isn't entirely constructive, especially to discount something as a placebo effect. Not knocking you, just saying that your phrasing and choice of words seemed a little dismissive and I think people were responding to that.

I myself use 5DtoRGB on Windows. It works and it works really well. You do gain a quality bump whether you're using it on Canon footage, and especially GH2 footage. The biggest gain I've gotten besides a more linear flatenning of the color curve is that it gives me consistency between moving between programs, and it cures that horrible crunched AVCHD gamma curve that you get from programs improperly handling AVCHD material.

It also works wonders on AF100 footage too! Really smooths out those higlights. Seems to be a big of a quick magic fix before editing.

af100 with and without 5DtoRGB

http://img717.imageshack.us/img717/1665/fullpl.jpg

http://img535.imageshack.us/img535/561/af1005dtorgb.jpg

 

[Kholi]

But we can also just import a 4:2:0 file to AE, smooth out the kinks and do a key. No difference in quality, conversion or not.

Did you just not read the rest of the thread?

 

[leteeci]

Does the latest PC version of 5DtoRGB have option for flatter image??

 

[M. Gilden]

Seems funny that in a thread specifically asking about what effect 5DtoRGB has on GH2 footage that you would discount the experiences of people using it. The original poster asked for feedback, and he's gotten it. Why you would post contrary to that experience when you haven't used the software isn't entirely constructive, especially to discount something as a placebo effect.

Actually, the OP asked if there was a reason to use it on Windows. Technically, if the purpose of the application is to convert to a more editing friendly format in more compatible color space, the point seems moot on modern editors like Adobe Premiere with the mercury engine. Converting into color space is handled on the fly and in real time.

So, that being the case, 5DtoRGB *shouldn't* be necessary. Perhaps I should have phrased it more like a question than a challenge, but it seemed like a lot of people are praising it without understanding why or how it makes a difference, and if that situation would be true of all. Just blindly accepting what works for someone else's workflow will not necessarily help everyone else with theirs. Imagine if RED users came in here and starting asking how they could get the flat Technicolor Picture Profile to work with their cameras. You would know right away that such a workflow (if it were even possible) would be nonsense because RED shoots RAW. However, in this case, in some situations 5DtoRGB definitely is useful (Final Cut based workflow, older Adobe suite, etc). So, I wasn't surprised that people benefit from it, but the benefits seem less so when not using a Final-Cut based workflow. I would think that my original input is very valid from a scientific perspective. I have heard far too many workflow tips that appeared to be placebo effects or actually harmed the footage in other ways (like the arguable benefits of the technicolor profile on Canon). However, that was before PDR came along and actually explained the science behind it by pointing out that Adobe's conversion to RGB creates unwanted artifacts.

You are correct that I hadn't tried using 5DtoRGB, but I must admit that I find it silly to discount my comment based on that considering the information presented here- Going back to my RED example above, if someone had theoretically found a way to apply the flat technicolor profile to their workflow, would you need to try it because voicing your opinion that this might just be a placebo effect?
The same would be true here. I never tried it because from a technical perspective (assuming I didn't know about the bicubic vs nearest neighbor vs etc transcoding), it shouldn't make a difference.
There is no such thing as a "magic fix", and understanding how and why this stuff works can only help your skill. So you'll have to excuse me if people throw around tips that they can't explain, and are met with a bit of cynicism. I am happily eating my words now that someone has pointed out the science behind it, and I think many of us can thank the fact that this discussion exists for the education.

I myself use 5DtoRGB on Windows. It works and it works really well. You do gain a quality bump whether you're using it on Canon footage, and especially GH2 footage. The biggest gain I've gotten besides a more linear flatenning of the color curve is that it gives me consistency between moving between programs, and it cures that horrible crunched AVCHD gamma curve that you get from programs improperly handling AVCHD material.

Right, but the latest suite of tools from Adobe and others shouldn't have that problem anymore. I'm sorry if my placebo suggestion offended anyone- I was searching for a logical explanation since it went against anything I understood. Transcoding footage shouldn't be a necessary step, but if you are converting color spaces, working on an old non-DSLR friendly NLE, or a system that relies on Quicktime, it *can* help. But it shouldn't be necessary in an ideal world, and there is no magic going on to fix footage in the background.

 

[dcloud]

It still is a problem in adobe. You have to adjust the gamma on the editing. Its just more convenient to not have to like 5d torgb

 

[M. Gilden]

It still is a problem in adobe. You have to adjust the gamma on the editing. Its just more convenient to not have to like 5d torgb

Do you? From the tests that I've seen (and my own brief personal experimentation), the latest versions of Premiere and Sony Vegas don't seem to have this problem. Perhaps AE still does?

Its got nothing to do with convenience. I'm a technical person, and have trouble accepting something that can't be explained. Lucky for you, someone already explained why it is preferable, and I now understand its use for a workflow that involves Adobe After Effects (maybe you missed that part?).

Ideally, if we had an editor that worked in Y'CbCr space, it shouldn't be needed. But most things seem to be RGB for now.

 

[maarek]

Did you just not read the rest of the thread?

I read what you wrote and tried to correct the issues I saw. Instead of answering you come up with this?

Do I have to post an image showing that there is no difference? If I do that what will you say?

 

[Kholi]

I read what you wrote and tried to correct the issues I saw. Instead of answering you come up with this?

Do I have to post an image showing that there is no difference? If I do that what will you say?

Okay, so you didn't read the rest of the thread; got it.

Here you go, so you don't have to go back to read:

That's the theory. In practice , it's not a big difference (you're not leaving that much on the table)

The reason is most AV hardware do not take full advantage of what Y'CbCr can store by the time it gets recorded to card , either the sensor , or internal processing (and not just the GH2). Most of the time a full range conversion to RGB will contain the majority of the usable data under normal controlled shooting conditions. But under abnormal conditions, maybe colored lighting, overexposure - there can be usable values lost because of converting to RGB

Similarly, the method of pre and post treatment for keying 4:2:0 footage directly can deliver similar results if done correctly. The difference might be minimal with a skilled VFX artist. People have to ask themselves if it's worth it for their purposes and goals

Now that you can read that...



I said, several pages back, to just do your own test and see what you find. I wouldn't tell you I saw anything different if I did not. It may be negligible to YOU but that's you.

 

[PaPa]

Okay, so you didn't read the rest of the thread; got it.

Here you go, so you don't have to go back to read:



Now that you can read that...



I said, several pages back, to just do your own test and see what you find. I wouldn't tell you I saw anything different if I did not. It may be negligible to YOU but that's you.

I thought i posted stills of zoomed crops with and without 5DtoRGB and clearly showed that there was a difference, minimal or not. These were all taken as print screens from premiere. Are we talking more specifically about AE and the way it handles it?

 

[crunchy]

Could you be so kind and leave the original mts video clip somewhere in order to check it? I would like to try another approach.

 

[Fohdeesha]

There are no gamma problems in the GH2's AVCHD encoding matrix, it encodes to the standard Rec.709 color space which means Rec.709 primaries, and a standard scene-referred gamma of 2.2. The MTS files directly out of camera are perfectly fine, and adherent to this specification. They do not need "correcting" to a 1.8 gamma, 1.8 gamma is not what the Rec.709 standard dictates on a scene-referred basis, and using 5DtoRGB to "correct" the gamma to 1.8 is the exact same as dropping an MTS file in your editor, and applying a gamma effect with a setting of 1.8. If you don't believe me, do it yourself.

If you're having AVCHD gamma problems, it's an issue with your software interpreting the source gamma incorrectly, and has nothing to do with the MTS file itself. I'm on windows, and have not experienced any gamma shifting issues with MTS files (or any files for that matter) in Premiere CS5.5, After Effects CS5.5, or Assimilate Scratch. For kicks I downloaded 5DtoRGB and converted some MTS files to DPX sequences, as well as ProRes HQ, and dropped them in Scratch. With 5DtoRGB set to either legal, or extended, there is absolutely no difference whatsoever from the original MTS directly off camera. (your GH1/2 encodes YCbCr adhering to broadcast legal specifications by the way, any software such as 5DtoRGB claiming to retrieve "extended information" is simply stretching the 16-235 data to 0-255). I'm not eyeballing and using a subjective "trained eye", I'm measuring objectively with a waveform and vectorscope, and a color analyzer within Scratch.

The only thing you're doing when converting your MTS files to ProRes with 5DtoRGB on windows is getting all of your lovely footage into the god awful gamma shift prone quicktime MOV container, which is what half of us are on windows systems to avoid in the first place.

I work in a Scratch suite most days of the week, and deal with things like this all the time. If you don't buy anything I'm saying, and still want to claim that 5DtoRGB is magically massaging your footage, I would love to export some tiffs, put them in a zip, and paypal some money to whoever can figure out which tiff is the original and which has been "enhanced".

To sum this up, I'm sure there are some users out there gaining something from implementing 5dtoRGB into their pipeline, but it's not because the program is doing anything magical, or "correcting" any inherent flaws in gh2 footage. You're gaining something because it's offloading the colorspace (and therefore gamma) interpretation, so your erroneous NLE doesn't have a chance to interpret your footage incorrectly. Like I said, the CS suite on windows does not suffer from this what so ever, but I can't speak for other systems. I don't touch OSX, so god knows what's going on with quicktime gamma shifts in FCP and what have you, I probably don't blame you OSX users for just running everything through 5DtoRGB just to be safe.

This program was designed to overcome the ridiculous ycbcr to rgb and gamma interpretation issues deeply embedded in the quicktime implementation on OSX, these problems simply do not exist in windows.


(And please do not get me started on claims of retrieving "lost" YCbCr information by using this program to convert to RGB. (by the way, rgb isn't a colorspace, it's a methodology of storing various colorspace adherent information). All modern NLE's (outside of quicktimes implementation of faux-dithering) use the same, standardized math to convert YCbCr data to RGB (floating point in the case of CS5 (if you tell it to). It's the same standardized math your display uses when you feed it a YCbCr signal over sdi or hdmi, to convert to RGB to feed the panel driver. I've looked at the chroma differences in 5dtorgb converted footage that you are all claiming makes keying so much easier, and it's literally just smoothing chroma information during the rgb conversion. There's plugins for that if you really want it, or you can simply use the chroma channel preblur setting in your keyer if it has one, but I prefer the original, unaltered data. If you have a compositor like Nuke or Fusion, drop in some gh2 footage, pipe the red channel to a separate node, blur (gaussian) it, and matte it back with the original node. You will see the exact same "improvements" you are all posting comparison screenshots of)



:bath:

 

[DPStewart]

There are no gamma problems in the GH2's AVCHD encoding matrix, it encodes to the standard Rec.709 color space which means Rec.709 primaries, and a standard scene-referred gamma of 2.2. The MTS files directly out of camera are perfectly fine, and adherent to this specification. They do not need "correcting" to a 1.8 gamma, 1.8 gamma is not what the Rec.709 standard dictates on a scene-referred basis, and using 5DtoRGB to "correct" the gamma to 1.8 is the exact same as dropping an MTS file in your editor, and applying a gamma effect with a setting of 1.8. If you don't believe me, do it yourself.

If you're having AVCHD gamma problems, it's an issue with your software interpreting the source gamma incorrectly, and has nothing to do with the MTS file itself. I'm on windows, and have not experienced any gamma shifting issues with MTS files (or any files for that matter) in Premiere CS5.5, After Effects CS5.5, or Assimilate Scratch. For kicks I downloaded 5DtoRGB and converted some MTS files to DPX sequences, as well as ProRes HQ, and dropped them in Scratch. With 5DtoRGB set to either legal, or extended, there is absolutely no difference whatsoever from the original MTS directly off camera. (your GH1/2 encodes YCbCr adhering to broadcast legal specifications by the way, any software such as 5DtoRGB claiming to retrieve "extended information" is simply stretching the 16-235 data to 0-255). I'm not eyeballing and using a subjective "trained eye", I'm measuring objectively with a waveform and vectorscope, and a color analyzer within Scratch.

The only thing you're doing when converting your MTS files to ProRes with 5DtoRGB on windows is getting all of your lovely footage into the god awful gamma shift prone quicktime MOV container, which is what half of us are on windows systems to avoid in the first place.

I work in a Scratch suite most days of the week, and deal with things like this all the time. If you don't buy anything I'm saying, and still want to claim that 5DtoRGB is magically massaging your footage, I would love to export some tiffs, put them in a zip, and paypal some money to whoever can figure out which tiff is the original and which has been "enhanced".

To sum this up, I'm sure there are some users out there gaining something from implementing 5dtoRGB into their pipeline, but it's not because the program is doing anything magical, or "correcting" any inherent flaws in gh2 footage. You're gaining something because it's offloading the colorspace (and therefore gamma) interpretation, so your erroneous NLE doesn't have a chance to interpret your footage incorrectly. Like I said, the CS suite on windows does not suffer from this what so ever, but I can't speak for other systems. I don't touch OSX, so god knows what's going on with quicktime gamma shifts in FCP and what have you, I probably don't blame you OSX users for just running everything through 5DtoRGB just to be safe.

This program was designed to overcome the ridiculous ycbcr to rgb and gamma interpretation issues deeply embedded in the quicktime implementation on OSX, these problems simply do not exist in windows.


(And please do not get me started on claims of retrieving "lost" YCbCr information by using this program to convert to RGB. (by the way, rgb isn't a colorspace, it's a methodology of storing various colorspace adherent information). All modern NLE's (outside of quicktimes implementation of faux-dithering) use the same, standardized math to convert YCbCr data to RGB (floating point in the case of CS5 (if you tell it to). It's the same standardized math your display uses when you feed it a YCbCr signal over sdi or hdmi, to convert to RGB to feed the panel driver. I've looked at the chroma differences in 5dtorgb converted footage that you are all claiming makes keying so much easier, and it's literally just smoothing chroma information during the rgb conversion. There's plugins for that if you really want it, or you can simply use the chroma channel preblur setting in your keyer if it has one, but I prefer the original, unaltered data. If you have a compositor like Nuke or Fusion, drop in some gh2 footage, pipe the red channel to a separate node, blur (gaussian) it, and matte it back with the original node. You will see the exact same "improvements" you are all posting comparison screenshots of)



:bath:

Now, see? That's exactly what I was going to say!

No...it's not....he's a pro.
I'm "Joe User"....
But this helped clear up the differences I encountered when I used a Mac and FCP on a few pieces last month...
Normally I'm Win-CS5.5