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

dcloud said:
theres a difference and you can see it.
Click to expand...

No, you cannot, as I've tried to say several times. If you can, your Premiere is not set up correctly.

here are 400% crops of a 1080p original mts, and then an uncompressed mov from 5dtorgb. Sequence settings set to maximum bit depth, and maximum render quality. As I stated before, this makes it convert from YUV to RGB in floating point space.

I have already done this test from Scratch and Fusion, no difference. What's interesting here with the premiere test is the original mts crop PNG actually has a larger filesize than the crop of the 5dtorgb conversion, so take that to mean what you want. For me, I don't know why you windows people are letting this thing touch your footage.

Good luck telling which is which:

http://img232.imageshack.us/img232/494/85430707.png

http://img546.imageshack.us/img546/4346/14789493.png


I'll say this for the last time, if you can see a difference in premiere, go into your sequence settings and tick "maximum bit depth", and "maximum render quality". This makes premiere, according to file size of the crops here atleast, actually do a better YUV to RGB conversion. The 5dtorgb conversion contains less data, that's factual, do these test crops yourself. The only way to get a smaller filesize out of a lossless compression algorithm such as PNG is to not have as much chroma or luma data, so this stengthens my theory 5dtorgb is literally just blurring the chroma subsampling to make it appear to have more information, and make it "appear" to key better.
 
Last edited:
If you keep an eye on the vertical white line to the right of the third knob from the left, while switching between images, you can see it literally disappear in the 5dtorgb crop. Yeah guys, totally squeezing every last drop out of your footage. I'm going to quietly leave this thread now, and leave you guys to use whatever tools work for you.
 
Well for one, compressing the frames to jpg in the end renders comparison totally useless, second, it seems you are telling 5dtorgb to change the gamma of the clip, which is not correct if you want to accurately reproduce the native rec.709 gamma of 2.2. You can also not compare filesizes of clips with different gamma, let alone whether they've been re-compressed to a lossy image format.

edit: http://imgur.com/ will let you upload png's and not touch them. But like I said, you're telling 5dtorgb to incorrectly change the gamma to 1.8 which is not rec.709 spec. If you want a flatter look, just drop a gamma effect on the clip in your editor and change it to 1.8 (or whatever you want), you'll get the exact same result.
 
Fohdeesha said:
Well for one, compressing the frames to jpg in the end renders comparison totally useless, second, it seems you are telling 5dtorgb to change the gamma of the clip, which is not correct if you want to accurately reproduce the native rec.709 gamma of 2.2. You can also not compare filesizes of clips with different gamma, let alone whether they've been re-compressed to a lossy image format.
Click to expand...
1st- well the point was it looked different from native and transcoded
2nd - well its a gamma flag. its not actually baked in. and i prefer this way so i dont have to pull it down in cs5.5. look, my point was, there wont be any difference as the data from native will still be there except in the transcoded video, i dont have to pull the highlights down. so yes its a waste of HD space, its another step, and it doesnt change any information.
3rd - i dont think it matters
 
Hi! This is gonna be a long one, so you might want to start that batch first. :tongue:

Fohdeesha said:
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.
Click to expand...
There's nothing wrong with the QuickTime MOV container. The gamma shift problems are due to the QuickTime API, not the MOV container format. Of course, I (nor anyone else) can control what QuickTime does to the footage when it decompresses it, but it should be stated for the record that the problem is not the QuickTime MOV wrapper.

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".
Click to expand...
5DtoRGB doesn't use magic (well okay, maybe a little :D). It does, however, use the highest quality chroma interpolation available to reconstruct either 4:2:2 or RGB from a 4:2:0 source. And it gives the user the option to control this process directly, whereas most programs don't. Wouldn't you rather be in control instead of just hoping your NLE does the right thing?

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.
Click to expand...
Problems like these can be NLE-specific. For example, is Directshow or QuickTime used for the H.264 decode? Is the NLE or the video API is reassembling RGB from YCbCr? Or is the NLE doing both? The answer is: who knows? It all depends on how the software in question decompresses the input video and whether it uses system APIs in the process. This isn't an exact science because you can't be guaranteed that every NLE will stick to published matrices and/or luminance ranges (QuickTime is one example). Really, your best bet for ensuring your footage will match on every system is by outputting to an uncompressed RGB format (DPX), which 5DtoRGB does. However, 5DtoRGB users have been reporting good luck with ProRes footage on both Mac and Windows systems.

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.
Click to expand...
Of course! :) That's why it looks so good!

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.
Click to expand...
I'm not sure I'd blur the chroma channels as you suggest. This would almost certainly discard data in the process. 5DtoRGB doesn't "blur" the chroma, it reconstructs it right off the H.264 decoder as raw Cb and Cr components so no blurring is necessary. In fact, you can turn matrix decoding OFF altogether in 5DtoRGB and observe Y, Cb and Cr separately. Trying to blur chroma channels in an NLE/plugin requires yet another YCbCr matrix encode/decode step, reducing accuracy. Why do this when you can just do it right the first time with 5DtoRGB?

Nearest neighbor, lanczos, mitchell, sinc, etc, are spatial resolution scaling algorithms, and not applicable to color science methodology whatsoever.
Click to expand...
Scaling is mandatory for upsampling 4:2:0 color information to full raster. It's applicable in that you can't get a usable result from an H.264 decoder without scaling and matrix decoding. Both steps are required.

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.
Click to expand...
I couldn't agree more. That's the whole point of using 5DtoRGB -- to overcome these faults. :thumbsup:

Fohdeesha said:
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.
Click to expand...
From http://dictionary.reference.com/browse/interpolate:

in·ter·po·late
[in-tur-puh-leyt] Show IPA verb,in·ter·po·lat·ed, in·ter·po·lat·ing.
verb (used with object)
1.to introduce (something additional or extraneous) between other things or parts; interject; interpose; intercalate.
2.Mathematics . to insert, estimate, or find an intermediate term in (a sequence).
3.to alter (a text) by the insertion of new matter, especially deceptively or without authorization.
4.to insert (new or spurious matter) in this manner.

​
Based on this definition, it seems safe to assume "interpolation" implies "creating new data." And well, you actually have no choice but to create new data because H.264's Cb and Cr channels are not full raster (they're only 1/4 raster). Again, this isn't a problem when using 5DtoRGB because it employs the high quality chroma interpolation.

Fohdeesha said:
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.
Click to expand...
Again, I agree completely. As long as a piece of software (5DtoRGB, for example) knows the correct way to reconstruct either 4:2:2 or 4:4:4 from a 4:2:0 YCbCr source, then dealing with H.264 can be a pleasure. The real problem is other software that causes problems by either performing crappy chroma upsampling, using the wrong decoding matrix or using the wrong luminance range. 5DtoRGB gives the user complete control over all of this (along with a few extras), so these issues need not be of any concern to a 5DtoRGB user.

Actually Fohdeesha, I'm flattered that you've compared my $50 program to others costing many thousands of dollars and admitted that you're incapable of detecting any difference in quality. Now that's what I like to hear! Keep spreading the word!
 
I'm actually off to bed right this second - but it seems we are in agreement and thanks for taking the time to reply - In regards to no detectable difference in thousand dollar software - That is what I'm getting at, in regards to the CS Suite anyway. People have already purchased these pieces of software, and with the correct settings, there is no need to implement yet another piece of workflow. As you can see from the crops in my post above, Premiere does a fine job of YUV to RGB conversion, and in fact, if we take into account the seeming loss of spatial resolution (disappearing white line) due to your chroma smoothing, then premiere might just be doing a better job. As for gamma shifting, yes, it's the quicktime API itself. A bit hard to escape on OSX. Not an issue with the CS suite on windows. As for scaling - I was referring to scaling color spaces into YUV or RGB containers, not spatial chroma sampling.

I have been saying this whole time that for OSX or FCP workflows, your software makes perfect sense, and fills a gap. Maybe even for some software on windows too. (I have not ran into any software in windows that has these chroma upsampling issues, but admittedly I'm confined to a Scratch/Fusion/CS5.5 workflow). What I am addressing though, is the seemingly high number of windows CS Suite users here that are taking time to transcode, take up more hard drive space, and put yet another piece of software in their pipeline, in vein - When, as shown above with 400% crops, there is no need :)

Do you have any idea why your chroma smoothing would be making that white line fade away? It's white on a barely blue-tinted black, so I do not see how chroma sampling would effect this, but swapping back and forth in the premiere timeline, and in the exported PNG's, it's definitely happening. I would attribute it to an added step of more compression, but the 5dtorgb converted file was converted to uncompressed 10-bit 4:2:2, not prores.

I tried my best to duplicate the quality increase people are claiming to see in the CS suite, but with the ticking of two buttons in sequence settings, no matter what I do or what I transcode the footage to, I am seeing no positive difference
 
::takes a deep breath::

Look, until you try it in After Effects (which many of us include when we say "CS5.5"), you can't tell anyone here that what they witnessed with their own eyes was somehow "wrong". We aren't arguing about the same thing. I said pages ago that I didn't seem to notice a difference in quality when using Premiere or even Sony Vegas to my eyes. But I do seem to notice a difference when dealing with the ability to key in AE. It could very well be that AE is still relying on quicktime to decode or something (but I would think Adobe would keep their decoders consistent across platforms, but who knows), but it doesn't change the fact that many of the users here are seeing something.

Remember, I came into this thread arguing the same case you did (although with far less technical detail), and tried it myself after Kholi's suggestion that I see with my own eyes instead of arguing about it on a theoretical level. And it made a believer out of me. Clearly, some applications even on Windows are not decoding into RGB properly, and that is why 5DtoRGB can be useful part of the pipeline. I mean, its not like we have a definitive list of which applications will have decoding problems and which won't... if a Windows user wanted to ensure that the upsampling color quality remains consistent across a multi-step workflow, 5DtoRGB seems like a pretty good idea to start with.

That being said, I only use it specifically when I plan to key something out since it does appear to make a difference in AE (at least to me). Otherwise, I don't feel the need for it. But what irks me is how adamantly AGAINST it you are- almost like you refuse to accept that perhaps some Windows applications can exhibit the same decoding bug that Final Cut does. I'm pretty sure that until pretty recently, most Windows NLEs required quicktime being installed. Its not crazy to assume some third party apps or even someone with an older version of the software would need this.
 
It is difficult to say about Adobe software how they actually handle things (other than to be certain that not necessarily ideal methods are being used). A few years ago I was more actively involved in Adobe programs. I found out the developer groups for the video software were rather small, did not much care what the other groups were doing and generally just did not seem to be the best talent. I still use them but if better alternatives could be had, I would not hesitate to abandon the ship in a heartbeat.
 
Hey Fohdeesha, thanks for posting those two grabs. As far as conversion and color goes, I couldn't see a difference in that cropped area, aside from a very very very very slight "softness" in one, that is pretty much imperceptible. Personally, haven't disagreed about the lack of an advantage for windows users.

I think it's just down to how they want to work in that area.

My only involvement here was as far as keying an image goes. So beyond that, you guys hash it out (respectfully...) in the name o'the truth! xD I'mma sit back and just learn.
 
Thanks for Thomas Worth for participation and creating useful software. Would it be possible or practical to add feature in 5DtoRGB to export MTS files as a jpeg sequence? I am trying to find easier ways to import video image sequences into Silkypix RAW processor to take advantage of the Virtual RAW processing specially tailored for Lumix cameras.
 
Aki_Hartikainen said:
It is difficult to say about Adobe software how they actually handle things (other than to be certain that not necessarily ideal methods are being used). A few years ago I was more actively involved in Adobe programs. I found out the developer groups for the video software were rather small, did not much care what the other groups were doing and generally just did not seem to be the best talent. I still use them but if better alternatives could be had, I would not hesitate to abandon the ship in a heartbeat.
Click to expand...

Yes, its true that Adobe applications are infamous for being totally inconsistent from each other. I have a friend in Palo Alto who works for Adobe, and this is a pet peeve of mine (he's offered to give me a tour one day and let me meet some of the designers- I'd LOVE to have a word with them). Even things like shortcuts (why is Control + D the shortcut for duplicating a layer in After Effects, but not in Photoshop?!). But to be fair, After Effects wasn't originally created by Adobe (they bought it from Aldus who aqcuired it from CoSA), so just like Flash, Audition and some other key players in their lineup that were bought later on, the original UI wasn't designed by the same team of people. So, I guess it makes some sense that they are so disconnected.

There does appear to be a lot of common functionality being rolled out these days, however. The same footage codecs that are supported by PPro are supported by AE, so I would assume that the import code is relatively common between them. However, the processing routines is not. Yet. It would be nice if one day in the future Adobe made all of their video-related apps run common processing code- it would make everything run more efficiently and require less memory than the current model. Perhaps even allow more functionality of one application in the other. But this is clearly not anyone's priority at the moment.

Aki_Hartikainen said:
Thanks for Thomas Worth for participation and creating useful software. Would it be possible or practical to add feature in 5DtoRGB to export MTS files as a jpeg sequence? I am trying to find easier ways to import video image sequences into Silkypix RAW processor to take advantage of the Virtual RAW processing specially tailored for Lumix cameras.
Click to expand...

I don't understand the concept here- can silkypix really process images that are already compressed into JPEG? And reveal what, exactly? I feel like it makes sense to believe that the RAW image data still has processing being applied which Silkypix can remove, but once it is apparently "baked in" to the image, either by AVCHD or Jpeg (or worse, Jpeg extracted from AVCHD), is there anything close to the original raw image to extract anymore?
 
M. Gilden said:
I don't understand the concept here- can silkypix really process images that are already compressed into JPEG? And reveal what, exactly? I feel like it makes sense to believe that the RAW image data still has processing being applied which Silkypix can remove, but once it is apparently "baked in" to the image, either by AVCHD or Jpeg (or worse, Jpeg extracted from AVCHD), is there anything close to the original raw image to extract anymore?
Click to expand...

According to the Silkypix manual there should be advantage. However, the semi-direct quote from memory is "significant alteration of compressed images may lead to failure of the image" (have to love the Japanese English). And if you think about it, you can encode into jpeg and when you know the parameters that you started with, you should be able to un-jpeg as well. At least to some extent. I am getting good results starting with jpeg images in Silkypix, but I can not say at this point that they are better than processed by some other software or method.

It started with the magenta removal, which Silkypix was capable of doing very well for jpeg images as well. For RAW images it was simply setting a new White Balance for the image. Eventually I want to have that kind of freedom for video, but for now I only have compressed images for video to work with and want to have the best results for them as well.
 
Aki_Hartikainen said:
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.
Click to expand...

It's easy to import it into VirtualDub. Just write AviSynth script (e.g. yourfile.avs):

DirectShowSource("yourfile.mts")

and open it (yourfile.avs) inside VirtualDub. Then you can export jpeg sequence.

You can, also, open the mts file directly in VirtualDub by using "DirectShow input Driver" under "Files of type" load option. However, by using this "direct" way, you'll get chroma upsampling errors, explained here (it's very old problem):

http://www.hometheaterhifi.com/the-...or-and-the-420-interlaced-chroma-problem.html
 
crunchy said:
It's easy to import it into VirtualDub. Just write AviSynth script (e.g. yourfile.avs):

DirectShowSource("yourfile.mts")

and open it (yourfile.avs) inside VirtualDub. Then you can export jpeg sequence.

You can, also, open the mts file directly in VirtualDub by using "DirectShow input Driver" under "Files of type" load option. However, by using this "direct" way, you'll get chroma upsampling errors, explained here (it's very old problem):

http://www.hometheaterhifi.com/the-...or-and-the-420-interlaced-chroma-problem.html
Click to expand...

Excellent info. Thank You!
 
because you all keep mentioning after effects, I just did the test in AE....literally the exact same results, no difference. The filesizes are even the exact same as the crops from Premiere, which would make sense as they are both using the same API for h264 decode. I've done everything I can to reproduce this wonderful improvement you all claim to be seeing, but it's simply not there.

I'm on my way out the door right now but tonight I'll export these crops from AE so you can see the lack of difference for yourself. If you would all like, I'll also set up a little scene with a green background with hard chroma edges on top of it such as a red blanket, a blue book, etc, and do the same crop test again

But I'm staring at it now, 800% zoom in ae, switching layers...zero difference :thumbsup:
 
Just kidding, I'll post them now.

800% crop this time, pixels as big as your face. Stare in awe at the.....similarity


original mts dropped right into AE - http://i.imgur.com/7hAmA.png

uncompressed convert from 5DtoRGB - http://i.imgur.com/zDeGp.png

If you guys want I'll do this comparison with something that has more chroma on chroma contrast, and provide the original mts file for you to do the tests with yourself.

Like I said before, If you're seeing a difference, in your AE options set preview quality to "color accuracy"
 
Fohdeesha said:
Just kidding, I'll post them now.

800% crop this time, pixels as big as your face. Stare in awe at the.....similarity


original mts dropped right into AE - http://i.imgur.com/7hAmA.png

uncompressed convert from 5DtoRGB - http://i.imgur.com/zDeGp.png

If you guys want I'll do this comparison with something that has more chroma on chroma contrast, and provide the original mts file for you to do the tests with yourself.

Like I said before, If you're seeing a difference, in your AE options set preview quality to "color accuracy"
Click to expand...

They are pretty similar.
However 7hAmA.png has less intensity of the red dot on the bottom left. If you watch the right hand border of that array of red pixels, you'll see the right-most line disappear in 7hAmA.png and reappear when you switch back to zDeGp.png. Its subtle, but its there. The fact that this is a blurry example actually makes the difference less noticeable. If that were a straight edge or fine text, you'd likely see much more of a difference. But even with this, you can still see the last column of pixels change.

Then there's the ever-so-slight color shift of the blue semi-circles (again, hard to tell because of the focus)- or are those knobs? If you look closely at the top where the light is strongest (peak of the gradient, if you will), you will see that zDeGp.png seems to have a bit more color bleeding around it (maybe one extra row or column) versus the other.

I'm assuming that these are taken from the exact same frame on both videos, otherwise you could attribute these subtle differences to camera noise.
I agree that like this, the very slight differences (and believe me, I had to WORK to spot them) are negligible and hardly worth the conversation we're having. But, when it comes to pulling a key, where less accentuated edges can actually leave a noticeable artifacts, the differences become much more apparent. Also, try shooting a chart or fine details in focus (hair, letters, etc).
 
Fohdeesha said:
People have already purchased these pieces of software, and with the correct settings, there is no need to implement yet another piece of workflow.
Click to expand...
There may not be a need to transcode for your workflow. However, transcoding is entirely appropriate when working in a collaborative environment, say when different editors have different systems and/or different NLEs. Not everyone is using Premiere. In addition, some may want to transcode for the speed benefit. Editing with ProRes is going to be faster than editing with native H.264. Some may prefer this route, and using 5DtoRGB in this type of workflow is a great solution.

What I am addressing though, is the seemingly high number of windows CS Suite users here that are taking time to transcode, take up more hard drive space, and put yet another piece of software in their pipeline, in vein - When, as shown above with 400% crops, there is no need
Click to expand...
Again, this depends on the user's needs. Don't assume that just because Premiere will edit H.264 natively that this solves all of the world's problems. For the home user or the wedding videographer, the Adobe suite may very well be a fine solution on its own. For feature film editing in a collaborative environment with multiple layers of editors, VFX people, colorists, etc. it may not. That's why 5DtoRGB exists. It eliminates any ambiguity about whether the footage will look right at any random point in the post process -- it just looks right, all the time.
 
You must log in or register to reply here.
Back
Top