10bitYUV > 32bitFP > 10bitYUV.

farss wrote on 8/4/2008, 3:56 PM
Anyone know if this actually does what one would think it does or even how one would test this without a lot of expensive hard to come by hardware?
I ask because Vegas is being taken to task elsewhere over this. I also from time to time get DB camera tapes. I know Ppro has a 10bit YUV pipeline. I know a 32bit FP pipeline would be even better but not much point if Vegas is only reading 8bits from the 10bit source into a 32bit FP pipeline.

Bob.

Comments

GlennChan wrote on 8/4/2008, 6:53 PM
Vegas should be able to do this if you ingest and output via SDI / through the 10-bit sonyYUV codec.

One way to check would be a set of hardware scopes that reads out the Y' Cb Cr values to you and you could check that the values are what they are (*though it's possible you could get tricked by dynamic rounding; but I seriously doubt Vegas does that).

Another way would be to take the gradient generator (it makes a 8-bit gradient), divide all the values by 4 (e.g. via Levels), render to sonyYUV, bring them back in, multiply all the values by 4, and check that the gradient is the same as the original.

2- The trick I believe is to have the footage come in via SDI. Because most of the AVI and quicktime options are limited to 8-bit RGB.

Of course if you have the material come in via SDI, then the footage will take up a lot of space. And if you want to offline/online, hopefully Vegas will understand the EDL of the offline system (unless Vegas is the offline system; haven't tried that).

I don't have an Aja or blackmagic card so I can't test this stuff.

3- Honestly, I don't think this stuff makes a huge difference. There are more noticeable image quality problems.
Bill Ravens wrote on 8/4/2008, 6:58 PM
Hi Bob...

Sounds like a lot of mumbo jumbo to me.

To the best of my understanding, while Vegas can process in 10-bit and even output in 10-bit, it can't ingest in 10-bit. IOW, everything vegas ingests is 8-bit. The 32 bit floating point is a sales gimmick to make 8-bit processing sound attractive. It really can't compete with a true 10-bit pipeline.

In my opinion, FWIW, Vegas was designed for DV. In it's day DV was the cat's meow. But, time has moved on. Vegas can't handle HDV, much less HD pipelines. It has patched until we have the present incarnation. Without a complete rewrite of the core programming, vegas has reached the end of its useful lifetime. I hate to sound doom and gloom, but, I beleive this is reality.

I could be wrong. No arguement from me. But, Vegas is a DV program, not really made for 4:2:2 10 bit editing.
farss wrote on 8/4/2008, 8:50 PM
Unless I've really screwed up then you might need to eat a little humbe pie. I'm no expert so I could have gotten this slightly wrong.

I created a gradient from 16 to 235.
Applied Levels FX:
In Start 0.000
In End 1.000
Out start 0.063
Out End 0.301

Rendered to 10bit Sony YUV.

Bought back into Vegas
Applied Levels FX
In Start 0.063
In End 0.301
Out Start 0.000
Out End 1.000

The resultant waveforms on Vegas's scopes match within the resolution of the scopes. The displayed steps would indicate that no truncation occured.

Yes, I had to wrangle some maths and I might have gotten it slightly wrong but a calculator isn't that hard to learn to use.

Bob.
Bill Ravens wrote on 8/5/2008, 6:25 AM
don't really think this proves anything, bob. if the gradient was 8-bit to start with, even encoded in 10-bit is nothing more than an 8-bit image wrapped in a 10-bit package.

also, was it a color gradient or B&W? I don't think a luma only gradient will work for demonstrating 4:2:0 to 4:2:2.which brings up another question, does vegas work, natively in 4:4:4?
farss wrote on 8/5/2008, 6:45 AM
Did you notice I knocked the 8 bit gradient down 2 stops, rendered that out, bought it back into Vegas, bought it up two stops and lost NOTHING in the process. You cannot do that without a full 10bit or better pipeline or without correctly reading the 10bit values from the 10bit file.

I'd go so far as to say Vegas's 32bit FP pipeline is probably significantly better than the 10bit pipelines in all other NLEs. The only limitation I can see at the moment is Vegas can only read and write 10bit files.

Bob.

Bill Ravens wrote on 8/5/2008, 6:58 AM
humble pie in the oven...not ready to bite into it, just yet, but, i just might.
GlennChan wrote on 8/5/2008, 9:52 PM
The only limitation I can see at the moment is Vegas can only read and write 10bit files.
Shouldn't Vegas be able to send 10-bit Y'CbCr over SDI?
farss wrote on 8/6/2008, 12:47 AM
"Shouldn't Vegas be able to send 10-bit Y'CbCr over SDI? "

Yes, but I have no simple way of testing this at the moment.
That said I have no reason to assume it would truncate the 10bit data when it was capturing or printing to tape or for that matter when sending the data down SDI to an external monitor over SDI.

However my comment was more directed at checking what was happening through the 32bit FP pipeline. That was to counter someone else's argument that a 32bit FP pipeline isn't as good as a 10bit pipeline to which I'd say it's actually better!

I know that you think all of this doesn't matter much and I agree, if you're only shooting with a camera that records 8bit there's not much to nothing to be gained and there's some very expensive cameras that are only 8 bit.

Where I do believe it matters though is with analogue tape such as Betacam SP. I believe that processing that through an 8bit pipeline and then back to the same format does noticeable harm to the image especially if the image is graded in the process. This is of no direct interest to me as SP is pretty much a legacy format down here. However a few years back another Vegas user really put his best effort into using Vegas to edit SP and the results looked pretty bad from the screenshots he sent me. If this now all works as it should I can put that ghost to rest.

Bob.
DJPadre wrote on 8/6/2008, 1:11 AM
Glenn, SCS should buy your talents...
apit34356 wrote on 8/6/2008, 1:50 AM
nice work, Farss! But I think the SCS team should clearly stated the 10bit workflow exists and include examples for the non-believers. A 10 bit video handling pipeline in front of 32FP would explain some performance issues.
quoka wrote on 8/6/2008, 5:53 PM
Farss,
You've hit on a question which has been nagging us since V8 came out. We are in the same boat as you in that we have all the equipment other than expensive hardware scopes.

I have grabbed off 10bit Digibeta tapes (from 10bit telecined film) using Decklink(set to 10bit) within Vegas(set at 32bitFP), then re-output these files back to DB and it indeed looks like it is keeping the 10bit info.
BUT... what happens when I process the clip within Vegas ... does it actually use the full 10bit space and convert it over to 32FP???? .... (or does it drop it to 8bit...convert to 32bit.... ) and then if I output back to 10bit SDI out of the project, does it maintain a true 10bit-32bit-10bit pipeline??????

WHY IS IT SO HARD TO GET A SIMPLE ANSWER ON THIS FROM SCS.
It either DOES or it DOESN'T ......... ?????
(I do understand some 'event fx' are 8 bit processing)

We do masses of CG compositing and processing within Vegas at PAL SDI 16:9 for broadcast nationwide. Our TV stations all broadcast SD & HD, with a huge proportion of the population having HD LCD/plasmas. This means our SD material is being uprezzed to HD and output. This means we are forever fighting colour banding problems inherent in 8bit YUV, especially with CG images.
To say this is a minor problem really means that your not interested in the final quality of your product.

BTW - We used to composite in Flame, then we found we could do most in Combustion. Nowadays we composite most of our work in Vegas, and turn to After Effects when it is really complex. I think most peoples eyes would pop out of their head if they saw the layers and levels of complexity we are able to get Vegas to do.


farss wrote on 8/6/2008, 7:31 PM
I couldn't agree with you more. I don't get a lot of DB camera tapes to work with but when I do for some odd reason throwing away those 2 extra bits makes me shudder.
That said I'm regularly amazed at how many people shoot DB and then ingest it as DV25 via firewire. Some will take it to a post house for an online, many feel near enough is good enough.
As I hope you can see from my tests it does appear that Vegas is reading all 10bits into 32bit FP values and processing according although I cannot vouch for all the FXs. One problem you may see from the values I had to use with the Levels FX is that Vegas assumes Computer RGB and after a bit of peering at the scopes and the odd cathartic profanity I realised what was going on and adjusted the numbers accordingly.
Also agree the lack of documentation is beyond the pale. The two big bullet points for V8 are undocumented (ProType and 32bit) and as I used to get told regularly if it ain't documented it don't exist.
I've yet to find a compositing task too complex for Vegas either. I've only recently gotten around to playing around with AE, first thing I tried was Keylight and that just blew me away compared to the CK FX in Vegas. I could probably get the same results with Vegas but what a nightmare that'd be. I didn't even read the documentation for Keylight , I just remembered something from a video I watched months ago, "Start from the top control and work down them, you may only need to adjust the first or second control". That's what I did and as I could see what each control was doing in real time it was fun to play with.
On the other hand while Vegas gets the compositing job done the time to rerender the output as you make adjustments can make it painful. It doesn't faze me too much as I'll resort to a calculator rather than eyeball it but it's hardly a creative process.

Bob.
GlennChan wrote on 8/6/2008, 11:47 PM
Also agree the lack of documentation is beyond the pale. The two big bullet points for V8 are undocumented (ProType and 32bit) and as I used to get told regularly if it ain't documented it don't exist.
The manual, IMO, is pretty good for the older features.

Though I think the problem with manuals in general is that people try to avoid reading them. Even if the manual is good (e.g. I like Shake's manual). It requires a big time investment to sift through the manual and you might not find what you're looking for. I think that's why I rarely look at manuals for programs.
Infinite5ths wrote on 8/7/2008, 12:07 AM
GlennChan,

Are you trying to tell us that you hate 'manual labor'? ;-)
farss wrote on 8/7/2008, 2:55 AM
Agree about manuals.
Documentation and manuals though aren't the same thing. Some of the best Vegas documentation is to be found in the Knowledgebase and white papers. I think that's all that's being asked for here. Not 500 pages on how to use something, just a few pages that define what it does.

Bob.