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

[Aki_Hartikainen]

Certain formats like AVCHD in Premiere CS5.5 get converted to 32bit float color space on the fly during editing and playback so no advantage there at all. In fact one may argue that converting to 32bit float color space will always be better then 10 bit color space.

That's possible but I do not trust Premiere's filters very much with ten year experience. In the earlier versions they tended to be a collection of bunch of filters that worked differently in various color spaces. It could have improved for 5.5 but I doubt it. Outside of After Effects clean color gradients come from transcoding to Cineform 10-bit and then using FirstLight primary corrector.

 

[M. Gilden]

Windows or not, if you're doing VFX work or grading, you don't sit on AVCHD and do it, you convert to DPX. That's enough reason to warrant using 5DtoRGB for any workflow.

Maybe I'm missing something, but I don't understand the logic there. What does converting add that After Effects doesn't do by itself behind the scenes? You are already working in higher color space, and it is oversampling the frames in RAM on the fly.

 

[Kholi]

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

 

[PaPa]

PaPa- are you using a Mac, by any chance?
I'm also under the impression that 5DtoRGB doesn't do anything on Windows boxes or NLEs that don't rely on Quicktime.
As I understand it, Quicktime has a gamma shift problem when using certain formats, and 5DtoRGB gets around that by converting to RGB space using its own decoder (not relying on quicktime).

There is no magic "quality enhancement" going on here, but rather it works around a bug when using Final Cut editors. As far as working in higher color space, modern NLEs work in the color space of the project, not the clip. If the project settings are 10-bit color, the color space is of an 8-bit clip is upconverted automatically. And editors like Premiere and Vegas don't rely on Quicktime for decoding anymore, so they don't suffer from the gamma shift bug.

The only advantage that I hear is the more editing-friendly format it converts to. If you find your computer is having trouble with native DSLR footage in the NLE, converting to an intermediate format is good advice. But there are plenty of options for that as well.

I am on windows, and all the advantages i've been posting are things i see. No more guessing boys. Facts are clear.

 

[M. Gilden]

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

No guessing going on here. Before I was into cameras, I was a digital animator (dating back nearly 15 years now). I've worked in a VFX environment almost exclusively until pretty recently, and what you are saying goes against everything I understand about workflows. I understand the advantage of working in higher color space when pulling a key, but again you are already working in higher color space just by importing your clip into AE. Converting your clip first into 4:4:4 does absolutely jack squat the way I see it, since it can't create new colors to fill the extra space (it just makes them up, same as would happen under the hood into your editor). Import a 4:2:0 clip into AE, smooth, pull a key = convert to 4:4:4 smooth, pull a key, only the latter requires more time and HD space.

 

[ErikTande]

No guessing going on here. Before I was into cameras, I was a digital animator (dating back nearly 15 years now). I've worked in a VFX environment almost exclusively until pretty recently, and what you are saying goes against everything I understand about workflows. I understand the advantage of working in higher color space when pulling a key, but again you are already working in higher color space just by importing your clip into AE. Converting your clip first into 4:4:4 does absolutely jack squat the way I see it, since it can't create new colors to fill the extra space (it just makes them up, same as would happen under the hood into your editor). Import a 4:2:0 clip into AE, smooth, pull a key = convert to 4:4:4 smooth, pull a key, only the latter requires more time and HD space.

Exactly. It seems to me 5dtorgb is an unneccessary step unless you're working in Final Cut. If you're working in Premiere or AE, skip it. I'm a VFX guy myself, the screenshot I posted on page 1 is a greenscreen shot. When dealing with VFX, one typically deals directly with source footage (or rather, uncompressed image sequences from the source).

 

[Kholi]

Live in the same space, and we never, ever, ever deal directly with source footage for various reasons, and when working with less than 4:4:4 in our environment (from testing ourselves, especially with DSLRS) we were able to pull cleaner keys from the same footage conformed to DPX sequences, in AE.

The only footage I'd be comfortable working with directly would be RAW RED, and even then I don't think I'd work with REDCODE versus kicking out a 4/5K DPX sequence.

 

[M. Gilden]

Exactly. It seems to me 5dtorgb is an unneccessary step unless you're working in Final Cut. If you're working in Premiere or AE, skip it. I'm a VFX guy myself, the screenshot I posted on page 1 is a greenscreen shot. When dealing with VFX, one typically deals directly with source footage (or rather, uncompressed image sequences from the source).

Exactly- back when I was into this stuff, the ideal way to work was considered to always work with the source or as close to it as possible. Any kind of transcoding was avoided whenever possible.

Live in the same space, and we never, ever, ever deal directly with source footage for various reasons, and when working with less than 4:4:4 in our environment (from testing ourselves, especially with DSLRS) we were able to pull cleaner keys from the same footage conformed to DPX sequences, in AE.

The only footage I'd be comfortable working with directly would be RAW RED, and even then I don't think I'd work with REDCODE versus kicking out a 4/5K DPX sequence.

I dunno- Not trying to argue with you, man (you know I respect your work and your opinion around here) but you've mentioned this before, and it always sounded kind of backwards to me. ::shrug::.
Would you care to elaborate as to why you feel this way? Unless something has drastically changed, it really goes against anything I was ever taught about editing work spaces.
But to be fair, you're using a Mac-based system with DSLR footage. Perhaps the quicktime dependency and its documented bug with DSLR footage has something to do with it in your situation?

 

[Kholi]

Exactly- back when I was into this stuff, the ideal way to work was considered to always work with the source or as close to it as possible. Any kind of transcoding was avoided whenever possible.

For one, DPX is lossless, you aren't doing any damage by converting lowly AVCHD or H264 footage for a DPX workflow. Even IF you didn't gain any visual advantage (which from my experience you absolutely do, even if it's very slight) you would gain a workflow advantage.

AE + AVCHD for compositing is inefficient.

Up until Resolve COULD handle native RED footage we were pushing 4K through DPX pipelines, and IMO that's valid because you want to be able to manipulate metadata in R3D (especially for HDR-X) and it means shorter conform times from projects to finishing @ 2K or 4K.

Still, probably would not work with native R3D for vfx.

I dunno, man. You've mentioned this before, but it always sounded kind of backwards to me. ::shrug::
Would you care to elaborate as to why you feel this way? Unless something has drastically changed, it really goes against anything I was ever taught about editing work spaces.

Because I've paced it with my own footage and seen the results with my own eyes? Again, if you disagree then that's fine. Or, you could actually go shoot a greenscreen sample and try it for yourself????? I dunno what else to tell you.

But to be fair, you're using a Mac-based system with DSLR footage. Perhaps the quicktime dependency and its documented bug with DSLR footage has something to do with it in your situation?

I'm not one hundred percent certain but I'm pretty sure that doesn't have anything to do with my experience with DPX vs straight-up H264 or AVCHD footage in AE CS5.

Like I said, try it yourself, otherwise I've no idea what else to tell you.

 

[M. Gilden]

For one, DPX is lossless, you aren't doing any damage by converting lowly AVCHD or H264 footage for a DPX workflow.

Oh, I wasn't the one who said it was damaging anything. I know DPX is lossless, which is why it is relatively safe to use in this situation. Best case scenario, according to logic and just knowing how this stuff is supposed to work, you are ending up exactly the same as maarek's proposed workflow here.
That is, as long as you are importing into AE 5.5 (not pre 5.x because until the recent version AE relied on quicktime for DSLR footage I believe).

I suppose I could try some tests when I get back from my trip (in California for the week). But it really sounds like a lot of placebo, especially since no one can explain the science behind it.

 

[Kholi]

Placebo amongst pixel-peeping people pulling green screen keys?

...okay...

It's not very hard to look at your matte and blow it up to see the difference.

 

[M. Gilden]

Haha.
Listen- you know I respect you and your opinion. If I were anywhere near LA right now, I'd knock on your door and tell you we should take this outside.

I've got CS5.5 on my PC laptop, and we could do some real controlled testing once and for all.

But I'm up north in Silicon Valley this time around (actually meeting with a buddy of mine from Adobe tomorrow night, and will probably mention this discussion to see if he has any input).

When I get back to my studio in NY, I'll try to make some time to experiment with pulling a key. If there is something here that I'm missing, someone had better have a darned good explanation for how this works, because the science and theory behind the workflow doesn't make sense to me.

 

[Disastronaut]

Must...defend and justify...workflow at all costs...

I like this back and forth, I'm actually learning a lot. Thanks guys.

 

[Kholi]

That is, as long as you are importing into AE 5.5 (not pre 5.x because until the recent version AE relied on quicktime for DSLR footage I believe).

This COULD be the reason why. Haven't tried it since like 2009, and wouldn't have had a reason to since DPX is an easier workflow for our pipeline (most pipes around here, anyway).

I know for a fact, however, it definitely made a slight enough difference to warrant sticking to the DPX workflow. Even if, at this point, AVCHD keyed the exact same as DPX, you'd probably need a serious workstation for AE to keep up with the workload of on the fly conversion etc.

 

[M. Gilden]

This COULD be the reason why. Haven't tried it since like 2009, and wouldn't have had a reason to since DPX is an easier workflow for our pipeline (most pipes around here, anyway).

I know for a fact, however, it definitely made a slight enough difference to warrant sticking to the DPX workflow. Even if, at this point, AVCHD keyed the exact same as DPX, you'd probably need a serious workstation for AE to keep up with the workload of on the fly conversion etc.

Ah hah! Now we're getting to the bottom of all this!

From Adobe's own marketing for CS5.5:
"Native support for DSLR cameras in Adobe Premiere® Pro lets you begin editing HD video immediately, with no need for file format conversions or long render times. You can drop clips from your memory card directly into the Adobe Premiere Pro timeline — there's no waiting to import — and the Adobe Mercury Playback Engine lets you mix footage, file formats, and frame rates on multiple tracks with real-time playback performance."

Rough translation: "You don't need a transcoding step in your workflow for speed anymore!"

A couple of years ago, when folks first started dropping DSLR footage into NLE timelines, it was painfully obvious that these formats were not designed to be edited in. The new "Mercury engine" was their alternative to using Quicktime, which is supposed to speed up performance to edit natively without transcoding first.
The whole gamma shift / quicktime bug was a perk that I don't think anyone was aware of at the time. It just happens to have fixed that as well for those who noticed.

That being said, I don't know if the Mercury Engine will speed up the processing enough to compare with transcoded DPX footage as I haven't compared the two. But I can tell you that it seems to be acceptable speed on my i5 box. I suppose if I were doing a lot of heavy effects layering and the machine felt bogged down, perhaps transcoding first would help. Its something to consider.

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.

 

[PDR]

Oh, I wasn't the one who said it was damaging anything. I know DPX is lossless, which is why it is relatively safe to use in this situation. Best case scenario, according to logic and just knowing how this stuff is supposed to work, you are ending up exactly the same as maarek's proposed workflow here.
That is, as long as you are importing into AE 5.5 (not pre 5.x because until the recent version AE relied on quicktime for DSLR footage I believe).

I suppose I could try some tests when I get back from my trip (in California for the week). But it really sounds like a lot of placebo, especially since no one can explain the science behind it.

Minor clarification: DPX=> DPX is lossless, but AVCHD => DPX actually isn't lossless. Y'CbCr and RGB are non-overlapping color models, and there are out of gamut colors when converting to RGB. Even a "full range" conversion done in 5DtoRGB or other programs isn't lossless, there are out of range values not mapped to RGB color model. But the point is moot if you are using AE, because AE converts to , and works in, RGB internally anyway (or rather BGRA). Even a wide gamut RGB workspace cannot contain all potential values of Y'CbCr.

The "science and theory" is the difference in the chroma upsampling algorithm used in other programs. AE uses a nearest neighbor algorithm, leading to "blockier" colors. Well some people say: just blur the chroma before you key - It won't produce the same results, because the chroma isn't blurred in the first place when using the other methods. On the contrary - it's actually sharpened when using something like a lanczos or spline36 algorithm.

To understand what's going on, look at comparisons of various upsampling algorithms eg. spline, lanczos, bicubic , mitchell, etc.... In a 4:2:0 1920x1080 video , CbCr are actually 960x540 resolution, but Y' has 1920x1080 resolution. Try upscaling any RGB image to a larger dimension using one of the algorithms and you will see the difference - this is analogous to what is happening to the color information in CbCr upscaling during the RGB conversion.

 

[Kholi]

Minor clarification: DPX=> DPX is lossless, but AVCHD => DPX actually isn't lossless. Y'CbCr and RGB are non-overlapping color models, and there are out of gamut colors when converting to RGB. Even a "full range" conversion done in 5DtoRGB or other programs isn't lossless, there are out of range values not mapped to RGB color model. But the point is moot if you are using AE, because AE converts to , and works in, RGB internally anyway (or rather BGRA). Even a wide gamut RGB workspace cannot contain all potential values of Y'CbCr.

Oops. Sorry. My bad. I actually did not know that. Thanks.

 

[M. Gilden]

Minor clarification: DPX=> DPX is lossless, but AVCHD => DPX actually isn't lossless. Y'CbCr and RGB are non-overlapping color models, and there are out of gamut colors when converting to RGB. Even a "full range" conversion done in 5DtoRGB or other programs isn't lossless, there are out of range values not mapped to RGB color model. But the point is moot if you are using AE, because AE converts to , and works in, RGB internally anyway (or rather BGRA). Even a wide gamut RGB workspace cannot contain all potential values of Y'CbCr.

The "science and theory" is the difference in the chroma upsampling algorithm used in other programs. AE uses a nearest neighbor algorithm, leading to "blockier" colors. Well some people say: just blur the chroma before you key - It won't produce the same results, because the chroma isn't blurred in the first place when using the other methods. On the contrary - it's actually sharpened when using something like a lanczos or spline36 algorithm.

To understand what's going on, look at comparisons of various upsampling algorithms eg. spline, lanczos, bicubic , mitchell, etc.... In a 4:2:0 1920x1080 video , CbCr are actually 960x540 resolution, but Y' has 1920x1080 resolution. Try upscaling any RGB image to a larger dimension using one of the algorithms and you will see the difference - this is analogous to what is happening to the color information in CbCr upscaling during the RGB conversion.

That is some really informative stuff right there. Nice!

But I'm kind of unclear as to how this leaves our discussion- One the one hand, you are saying that perhaps 5DtoRGB uses a better sampling algorithm than AE does internally (as in, not nearest neighbor). Actually, on that topic, what DOES 5DtoRGB use? I've heard lanczos is the preferred one for downscaling HD to SD- would the same theory be true of converting color space? And is that an option that 5DtoRGB has?
But on the flipside, you are saying that some color information is actually lost in the conversion process! Would that happen in AE regardless because we are working in RGB either way? So is 5DtoRGB beneficial in this scenario?

 

[PDR]

Oops. Sorry. My bad. I actually did not know that. Thanks.

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

 

[PDR]

But I'm kind of unclear as to how this leaves our discussion- One the one hand, you are saying that perhaps 5DtoRGB uses a better sampling algorithm than AE does internally (as in, not nearest neighbor). Actually, on that topic, what DOES 5DtoRGB use? I've heard lanczos is the preferred one for downscaling HD to SD- would the same theory be true of converting color space? And is that an option that 5DtoRGB has?

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.

But on the flipside, you are saying that some color information is actually lost in the conversion process! Would that happen in AE regardless because we are working in RGB either way? So is 5DtoRGB beneficial in this scenario?

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.