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

[M. Gilden]

See- I sort of had the same argument a while back in this very thread, I didn't see any "problem" with my MTS footage natively in CS5, Vegas, or any other Windows-based NLE... and this seemed like basically a fix for the well documented gamma shift that occurs on Apple-based editing systems and Quicktime.

But... that was before PDR explain some things about color spaces that I was not aware of. For Windows users, its not about the gamma shift (as fohdeesha mentioned, one of the advantages of going PC is avoiding QT), however the advantage is about how our editors convert Y'CbCr to RGB (since almost all NLEs and compositing software work with RGB internally).

Y'CbCr holds more values than RGB, supposedly. So, your software is essentially going to down sample to the nearest RGB value that it can, and try to do this in relative real-time (which usually means using the fastest, but not necessarily highest quality conversion, nearest-neighbor).

More on that in this post:
http://www.dvxuser.com/V6/showthrea...b-on-Windows&p=2521418&viewfull=1#post2521418
and his follow up two posts down from it.

If you've ever tried resizing video from HD to SD in your editor and have been disappointed with the way it looks afterwards, you've likely noticed the effects of nearest-neighbor high speed resampling. It doesn't create the smoothest detail. That's why a quick search around here will show you that many folks use an external converter like virtualdub or something that offers a higher quality (albeit far more CPU intensive) resampling method, such as lanczos. I've seen Premiere advertise that with 5.5's CUDA support, the default resampling algorithm is actually lanczos, so I'm not 100% sure how much of this effects strictly editing in Premiere. However, After Effects and other PC applications (even photoshop) are still relying on speedy but crummy looking resampling algorithms, and that appears to be why 5DtoRGB makes a difference.

5DtoRGB supposedly uses lanczos or bicubic, or something much more CPU intensive however of much higher resampling quality than nearest neighbor. That is why the red channel doesn't exhibit the jaggies, and why pulling a key seems so much cleaner. It is possible that blurring the red channel would achieve a similar result, but that doesn't make it the same thing.

I do agree with the baked-in gamma shift, however. I don't think there is much benefit for doing that, unless it is just something that helps with your workflow once you are already using 5DtoRGB for other reasons.

That's why my current opinion of 5DtoRGB on Windows is that it seems to only be beneficial for keying. But I do think that it is doing something.

 

[Kholi]

Like I said, long ago... haha... try keying something with a decent amount of detail (hair etc), smooth the AVC-HD in After Effects and then try keying the DPX. Let me know what you get.

It may be an arguably minor amount, but that tiny bit is enough to warrant itfor me. Others mileage may vary.

Agreeing with Gilden, though. Gamma shift, yeah I dunno anything about that on Windows. I find it very helpful in conjunction with GH2 footage in that space, but no sure about anything else.

 

[Fohdeesha]

Y'CbCr holds more values than RGB, supposedly. So, your software is essentially going to down sample to the nearest RGB value that it can, and try to do this in relative real-time (which usually means using the fastest, but not necessarily highest quality conversion, nearest-neighbor).

In a theoretical very large (gigantic) colorspace, such as something more expansive than LAB, yes, you can have more expansive colorimetry data stored in a ycbcr encode, if the given YUV and RGB bit depths are equal. Currently there is no sensor technology that allows you to capture this wide of a range of colorimetry, I've only seen colors that reach beyond LAB space originate out of computer generated material. But you need to see just how absolutely abysmal rec.709 is on a LAB plot. It's a very small colorspace, and you are not "downsampling" (not whatsoever) when converting to 8-bit RGB. If you were converting to an RGB space that only had 6 bits per channel to store this data, then yes, but let alone floating point within Adobe's software (when you tell it to). AdobeRGB is a much larger colorspace and is not downsampled during rgb conversion for display, and P3 is absolutely gigantic comparatively, and I work with P3 material in rgb space almost once a week. That latest film you saw in theaters? The DI scan for it (or the camera original, if digital) is in P3 space, and was color graded using software that works with RGB internally (Scratch, Pablo, Lustre, etc). It was then converted once again back to P3 in an XYZ space for the DCP package. Claiming that you have to "downsample" rec.709 ycbcr information into RGB because an infinitely high bit depth ycbcr space can store more data than an RGB space is exactly like claiming that you have to downsample your engine power in your 100HP civic because your tires are rated for a top speed of 250mph. It makes zero sense, and does not apply to this color model.

So, your software is essentially going to down sample to the nearest RGB value that it can, and try to do this in relative real-time (which usually means using the fastest, but not necessarily highest quality conversion, nearest-neighbor)

Nearest neighbor, lanczos, mitchell, sinc, etc, are spatial resolution scaling algorithms, and not applicable to color science methodology whatsoever. Like I said, the math for inverting matrices back and forth from YUV to RGB back to YUV is standardized, and is actually accounted for ahead of time when encoding to YUV adhering to the rec.709 standard. When a rec.709 device encodes to YUV, the main chromacity coordinates K[SUB]B[/SUB] and K[SUB]R, [/SUB]are actually derived from the primary chromacity coordinates in an RGB space, to make the conversion to rec.709 within RGB a hassle-free process. The same thing is also going on for the luma (Y) channel, it is stored within YUV so that is corresponds to a gamma adjusted luminance plot in an RGB encoded rec.709 plot. If you search around enough you'll find the actual math being used, and it will make a lot more sense then how I'm trying to explain it, but here's your primary chromacity coordinates of YUV in an RGB encode:

I've seen Premiere advertise that with 5.5's CUDA support, the default resampling algorithm is actually lanczos, so I'm not 100% sure how much of this effects strictly editing in Premiere. However, After Effects and other PC applications (even photoshop) are still relying on speedy but crummy looking resampling algorithms, and that appears to be why 5DtoRGB makes a difference.

With CUDA enabled, your real-time editing and timeline preview in premiere are scaled via a lanczos algorithm. When you export from Premiere, regardless if you have CUDA enabled or not, as long as you check "high quality", a lanczos algorithm is used during export. On top of that, in your export settings, if you also check "maximum bit depth", premiere converts your YUV footage to a completely floating point RGB space, then back to YUV again, it is a completely lossless process, colorspace wise. AE uses nearest neighbor for realtime preview unless you have "highest color accuracy" preference set under preview settings, which will then have it use lanczos. It always uses lanczos for render exports regardless of what you have set. Within photoshop, you can choose from a nice list of scaling algorithms used for your real time working window.

Like I said, long ago... haha... try keying something with a decent amount of detail (hair etc), smooth the AVC-HD in After Effects and then try keying the DPX.

I've keyed non-transcoded footage probably a couple hundred times, long before the gh2 existed, long before 5dtorgb existed. Nothing going on here is new, and like I said, if you're seeing a difference from keying natively and keying a transcoded copy, it is your softwares fault. I don't use AE to key, but last night I swapped a transcode for a dpx, and at 400%, like I already stated, no difference. I would suggest taking a look at your AE render and preview settings (notably color accuracy preferences under the preview tab), and keep in mind the difference you may or may not be seeing in AE's preview window due to it's chroma sampling, will simply not exist when you do an actual render out, as it switches to lanczos spatially and floating point YUV-RGB-YUV conversion.


Anything else?

 

[Kholi]

I don't use AE to key, but last night I swapped a transcode for a dpx, and at 400%, like I already stated, no difference. I would suggest taking a look at your AE render and preview settings (notably color accuracy preferences under the preview tab), and keep in mind the difference you may or may not be seeing in AE's preview window due to it's chroma sampling, will simply not exist when you do an actual render out, as it switches to lanczos spatially and floating point YUV-RGB-YUV conversion.


Anything else?

It's on render out as well. There'd be no point in me saying something if I didn't see it repeatedly (long before Gh2 lol).

But, you also don't use AE to key and that's what we use, so maybe it is the software, maybe it isn't. I'd be down to check out some heavy keying from ya, through your keying methods, that looks the exact same with both methods. Especially off of GH2 material.

I'm sure it would end the thread much faster than us going back and forth on it! xD

 

[M. Gilden]

In a theoretical very large (gigantic) colorspace, such as something more expansive than LAB, yes, you can have more expansive colorimetry data stored in a ycbcr encode, if the given YUV and RGB bit depths are equal
...
Anything else?

::blink blink:: (rubs eyes)

I... I clearly need to study color space a lot more to continue this conversation with you. I'm not an expert in this, and I don't claim to be. However, after hearing what appeared to be a perfectly rational explanation of the theory behind why it makes a difference, I tried it and have had the same experience as Kholi and many others on the board.
I didn't believe at first either. If the explanation I was given (and blindly repeated to the best of my ability here) doesn't make sense, then there must some other reason we are seeing what we are. I think I'd be able to tell if it were a placebo effect. There is definitely a difference.

If it were simply blurring the red channel, wouldn't it degrade the footage? I feel like Kholi would pick up on that with his peeping.

 

[Fohdeesha]

It's not just blurring it, it's breaking the 4:2:0 subsampling down to a 4:4:4 interpolation based on the luma channel and sampling it that way to get a "smoother" look. It's not creating new data. I mentioned you can get a similar effect by blurring that chroma channel; These are things a decent NLE will do for you automatically, on the fly

 

[Kholi]

The knowledge, not even gonna pretend like I understand it. That stuff went right over my head for the most part. I can only look at results and say "hey, this is what works out so I'm gonna use it."

If something else is happening and there's a better way, or I'm doing unnecessary things for zero gain (to me, two percent is a gain that I'll take) then I'd like to know so that I can investigate and change some things up. That's why I ask for examples to see what I'm doing wrong. No shame in BEING wrong, either. Just means a potentially greater understanding of the topics that I'm interested in.

xDD So if there are any examples, let us peep them to hades and back.

 

[Fohdeesha]

I can only look at results and say "hey, this is what works out so I'm gonna use it."

And that's the way to operate. I just wanted to clarify a seemingly large misconception that there is something inherently wrong with the avchd footage, or that this transcoding adds information that wasn't there to begin with. When in reality, it's totally up to your editing software to dictate if you see these changes or not. I have already done tiff comparisons out of Scratch, and they are bit-identical, same with exports out of Fusion. In premiere with sequence settings set to maximum quality and maximum bit depth, I can see no visual differences at 400%, but I have not yet done a bit comparison between exports. If you're interested I can probably do that in the next day or two

 

[Kholi]

Always interested in learning more. One less step in the chain would be nice. I wouldn't know how to implement it with a larger project, because if we're doing VFX then we're going to go to DPX to do everything, anyway, but I'll darn sure explore it, and the next time it comes up I'll be able to say "don't bother unless DPX is the way you like to work."

 

[M. Gilden]

It's not just blurring it, it's breaking the 4:2:0 subsampling down to a 4:4:4 interpolation based on the luma channel and sampling it that way to get a "smoother" look. It's not creating new data. I mentioned you can get a similar effect by blurring that chroma channel; These are things a decent NLE will do for you automatically, on the fly

Granted, so for the most part we all agree that 5DtoRGB does not magically pull extra information from thin air (if you scroll back to earlier in this conversation, that was my initial argument- the information has to come from somewhere, and if it wasn't in the original recording it must be bogus). So you can stop saying "its not creating new data". We know.
My belief, however, is that a "decent NLE" might not be doing what you describe above, and that 5DtoRGB is a workaround for a specific problem.

Its not that 5DtoRGB somehow unlocks a better picture, rather it appears to avoid a problem that some of us are seeing, especially in Adobe After Effects compared to the native footage. It could only be AE, for all I know. Premiere and Sony Vegas seem to work fine with it out of the camera, I only notice a difference when pulling a key. And there is clearly a difference to me.

I'm a logical person, most of what you are saying makes sense to me. But tell that to our eyes, and that various others who are CLEARLY SEEING A DIFFERENCE despite that it doesn't make sense according to your explanation. ::shrug::

 

[Aki_Hartikainen]

Will 5DtoRGB export jpeg image sequence? That would be handy for the Silkypix Virtual RAW work flow.

 

[Kholi]

Also, Fohdeesha, it's kinda like... does it even matter? At the end of the day, we either add a step to someone's process or reduce a step, but if neither are actually destructive then we're debating over things that really don't matter beyond what people are comfortable with.

You are WAY... WAY more knowledgeable than I am on the subject, clearly. And I'm not saying that you're wrong at all, just what experiences drove me to stay within a certain workflow for now. So if it's not in your schedule, don't even worry about it man. I think there's enough here for people to decide whether they want to test it for themselves or not, then choose for themselves.

There're a lot more important things to be concerned with... like... xD which patch to use for shooting birds and spiders.

 

[Kholi]

Will 5DtoRGB export jpeg image sequence? That would be handy for the Silkypix Virtual RAW work flow.

Not that I know of.

 

[Aki_Hartikainen]

Not that I know of.

Okay, thanks. Do you happen to know any software that you could feed with camera .MTS files and get a jpeg sequence out? Ideally the software could batch process .MTS files and output jpeg sequences in folders. Then it would be easy task to import a folder in Silkypix.

 

[Kholi]

Premiere is the only thing I can think of.

But, I thought you could view MTS in Photoshop?

 

[Aki_Hartikainen]

Premiere is the only thing I can think of.

But, I thought you could view MTS in Photoshop?

I believe that's possible, perhaps Lightroom as well. I am just not at that advanced level in software versions yet. Virtual Dub also exports the needed image sequence, it just does not do that for MTS files, so another step is needed in conversion. But it's a small problem if the work flow otherwise shows benefits.

 

[Kholi]

Check MPEGStreamclip as well, that might be able to do it. It's also free and easy to use.

 

[Aki_Hartikainen]

Check MPEGStreamclip as well, that might be able to do it. It's also free and easy to use.

Thanks a lot for the tip. Will check that next.

 

[dcloud]

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.




:bath:

I agree that its just offloading colorspace

Im in windows and you should Try this
Download the 32bit version of 5dtorgb 1.5.4
Not the 64bit version.

In this version theres no prores, only uncompressed and dnxhd.

Now render something there and compare it with native mts by cs5.5
theres a difference and you can see it. Specially on highlights but its not magic. Its just information being properly offloaded. The info is still there in native mts but you have to pull it out

 

[roei z]

does anyone know if AVID DNxHD import workflow is also "safe" ?
thanks.