Also now added Sony 10-bit YUV to the results, and Sony XAVC Intra, which is amazing. I'd like to see it compared to Cineform.

All of the codecs in that first round of tests were lossless RGB.

The YUV codecs are all lossy in the context that they use 420 or 422 chroma subsampling, the effects of which clearly show in the color chart tests.

UT, Lagarith, Huffy, Debugmode, etc. all have selectable YUV modes, which give different results than their RGB 24/32 counterparts.

When using YUV codecs for digital intermediates from RGB, CG, or graded source, it is technically better to use 10 bit for the reasons Laurence and I discussed some time back.

Also best to compare the codecs within their own groups, and avoid apples/oranges comparisons.

This is where I start to struggle.

My understanding is that Vegas Pro decodes everything internally to RGB and processes FX etc. on that. So if a YUV lossless codec such as 8-bit MagicYUV or Sony 10-bit YUV decodes a multi-coloured scene perfectly losslessly to RGB in Vegas, as verified by zero movement of pixels in the video scopes compared to the Vegas-decoded original, does it matter whether it's an RGB or YUV codec if the rendered file is only for later use in Vegas?

Should I be comparing by looking at more than just movement of pixels on the scopes? Can you describe your colour chart tests?

Something else worth pointing out is that MagicYUV, while only being 8-bit, does encode footage in Vegas as YUV 444. Sony 10-bit YUV on the other hand is only encoding YUV 422.

With video source it would only seem to matter if it is rgb. Decoding yuv source to rgb doesn't put the toothpaste back in the tube, so to speak.

With cg source, effects, grading, which begin life as rgb, it is probably always better to create your yuv intermediate in 10 bit 422, even though the destination will be vanilla 8 bit 420.

Or even better, use an rgb intermediate such as UT.

With rgb renders of the Belle-Nuit, which is designed to detect chroma subsampling, the results are perfect 444 with either Uncompressed or UT RGB, (as well as the rest of the codecs from the first round of tests).



The Magic render is very typical of 8 bit 422; not unlike Sony YUV or UT YUV 422. Even more chart degradation is to be seen with 420.
MagicYUV is a good 8 bit 422 codec at this time.

Thanks Musicvid.

So I put the 1920x1080 Belle Nuit chart into an 8-bit HD project and rendered to MagicYUV at its default settings. The result was perfectly lossless. Not a single pixel moved in the scopes between the TIFF file in Vegas and the AVI file.

Then I realised that actually it must have compressed in RGB, not YUV. Take a look at the color space priority order in this explanatory tooltip I'm getting, and at http://magicyuv.com/index.php/features/13-colorspace-support. Seems like mine is choosing RGB (or perhaps YUV 4:4:4). It seems like your renders are somehow choosing a color space further down that order. Did you change the default settings? Do you have the latest version of the codec?

Nick, the 32 bit version of the codec does not appear to be fully functional.
None of those controls appear to make a difference, and the output seems typical of 422

I'll have a chance over the holidays to play with 64 bit.

Ah OK. That might explain it.

I hope to download GoPro Studio Premium for a trial some time and compare the codecs with Sony XAVC Intra etc., if someone doesn't do it first. Probably won't be for a couple of months though.

Wrong thread John.

I was having trouble rendering to the 10-bit version of UT Video Codec from Vegas or from Frameserver so I made a post about it on Doom9.org.

Ignus2, the author of MagicYUV, replied here.

What he's saying is that Vegas won't support any 10-bit VFW codecs except Sony YUV. This is bad news :(

SCS, if you're reading, please support 3rd-party 10-bit VFW codecs.

Does anyone know if Cineform's 10-bit VFW codec (in GoPro Studio Premium) can be rendered to in Vegas? I don't own it but I could download the trial to test.

@Nick Hope - this is yet another glaring issue I've come to learn about Vegas Pro. Combined with other issues I've withheld posting about has more or less sealed my decision to stay with Adobe CS6. Cineform just works, any codec... Just works. No issues with third party 10 bit codecs not rendering accurately.

And what does that say about 4K footage shot on Red, and other 4K footage acquired in 10 bit color? I've more or less thrown my hands up in the air with Vegas - yet again! This is one of the primary reasons I moved to PPro CS5 2+ years ago and even with it's more traditional workflow which isn't as intuitive as Vegas Pro, it does EXACTLY what it's suppose to do - get the job done without having to resort to outside applications. Between frameserving, not being able to properly utilize CUDA technology, weird built in codec options, and other things I've tried to wrap my head around, I'm better off just sticking with Adobe's CS6 offerings until I can no longer utilize them.

I'm just shaking my head in disbelief that in all this time, Vegas is still stuck and hasn't moved forward.

I get now why so many have made the decision to move to PPro or FCPX.

The legacy codec for Cineform has and always was AFAIK promoted as a 10bit resolution codec. I have no idea what GoPro corporate has done to it.

Now as far as legacy use inside of Vegas8.0b plus versions, most forum members with great research have concluded that usage of the Cineform even when applied in 32bit video mode and then passed out of Vegas is not going to add anything to the 8bit pipeline. And of course that makes perfect sense. Then consider that without hardware assist - you cannot monitor Vegas Versions in more than 8bit anyway.

In my testing MagicYUV in the 64bit app version with Vegas13 build prior to 428 on Win7 64bit OS - I get better results than when in a direct comparison with legacy Cineform first gen. Hence my claim that MagicYuv does serve a true purpose as a digital intermediate in the current VegasPro.

How do you get the MagicYUV codec into Vegas Pro 13?
I downloaded and installed it but it doesn't appear under any rendering options in Vegas. Do I need to have VLC and Quicktime installed?
Thanks for any help.

MagicYUV will be under the Windows avi templates I beleive where you can choose the codec; it does not appear sa a separate render template. Be aware that it will create rather large files.

It will be inside an .avi container - as always people confuse codecs with containers.

File size will be larger than highly compressed codecs, but entirely lossless, and quite speedy to render. You will not need raid harddrives if you use 7200 rpm or ssd.

It's not there.
I installed it and re-started VP13 but it doesn't appear under any of the rendering options.
I am using Windows 8 and there are 2 programs installed. 1 is a "MagicYUV Quicktime configuration" and the other a "MagicYUV VFW codec configuration". I opened the latter but I don't have a clue what it is for.
I will install Quicktime and VLC today to see if that helps.
I do have SSDs btw.
Cheers

When you choose a template under " Video for Windows ( .avi ), " then select " Customize Template " , and then look at the ' Video Format ' options, do you see MagicYUV on the list?

Release 1.1 of 2015.02.25 added a few things including a QuickTime encoder/decoder component and VLC 2.1.x decoder plugin. In theory the AVI codec ought to still work as before, but if you're having trouble you could try the older release 1.0. It's been working a treat for me with everything at default settings. I love this codec.

No, it's not there.
There must be a problem as it also tells me that Quicktime is not installed when I try to configure it in MagicYUV. Quicktime is definitely installed and it appears in Vegas as a render option.
I'll try and go back to the version you suggested.
Thanks

Keep in mind that there were several bugs in the recent release - that are well documented on the site - and it sounds like you have tried to install on an already equipped VLC enabled PC running 32 bit OS. Read carefully.

I'm certainly impressed with the performance of the MagicYUV codec, however, I'm going to stick with the UT Video codec for now since Handbrake will load UT Video files directly.