The quickest and easiest way to gain an understanding of this may be to read the relevant parts of the book, "The DV Rebel's Guide," by Stu Maschwitz, available from bookstores or Amazon.com:

http://www.amazon.com/DV-Rebels-Guide-All-Digital-Approach/dp/0321413644/ref=pd_bbs_sr_1/002-4430320-3031238?ie=UTF8&s=books&qid=1188497125&sr=8-1

He uses After Effects as his tool, but since it is about using 32-bit RGB* to get better looking footage, this should translate very well to Vegas Pro 8.

Perhaps somebody here will even rewrite the scripts on the CD-ROM in the back of the book for Vegas 8...?

The scripts are not needed, but they make it very very quick and easy to go through his methodology to get the most out of footage.


*After Effects works in RGB, but most NLEs (other than Vegas) work in "YUV." Since Vegas 8 will also be able to process video in 32-bit RGB, it should be a good match.

Thanks, Spot, Course.

Off to the bookstore!

Simple question Spot.. ;-)

Does this feature apply as much to standard def miniDV as it does to HDV???

Cliff Etzel
bluprojekt

All definitions will benefit from this. Possibly less if the imagery is also being wrapped around a 3rd party filter or effect but let's not worry too much about that right now. Presumably the mode is either selected or automatically de-activated when a noncompliance crops up.

The idea of having more bits in the computer part of your workflow is that you have range to play in.

VegasPro becomes a mastering editor where, just as with a DAW, you have more dynamic range than you'll ever likely to bring in or take out of it. So you'll have less reason to blame the computer for overprocessing your material. You may even kick yourself less if you've done a poor job of white-balancing etc.

It is very much like breaking free of the 44.1kHz 16bit companded PCM of CDDA with the advent of 96kHz and 192kHz 24bit sampling in digital audio workstations. Even if your end product is CDDA, you can have more prestine material with the warmth you desire without knocking yourself stupid along the way.

32bit floating point is more than it first seems as well. Where the integer and mantissa split occurs has been the subject of great discussion in video engineering. I'd assume that this will be a IEEE standard split. Either way things are really heading in the right direction.

The good news is that modern CPUs can handle 32bit float very effectively. There has never been a better time to switch from linear 8bit per channel. Logarithmic import/export is likely to be a subsequent development (which will suit the RedOne camera if this function can be mapped into an import decompression "codec" effectively). Logarithmic digitization is about realising that video can, like audio, benefit from more sample bins at levels closer to the two extremes (zero and full-scale-deflection).

Quite exciting, - can't wait to download the demo and see what it brings me on my secondary display adapter preview. Especially with blur filters on SD material in an HD project. etc etc

This is great news - I do a lot of heavy tweaking and grading with HDV and the color banding is such a pain. It will be great to have Vegas be as clean a work flow as After Effects - I'm really looking forward to getting more sleep this year :)

Is Vegas 8 the only 32 bit NLE?

Question: Is this the end of Digital Intermediaries for HDV?
To qualify: I do a lot of compositing and a decent amount of colour correction.

As far as digital intermediates, well doubtfully they'll go anywhere as a result of there being 32bit floating point processing.If your machine struggles with HDV today, then it will likely struggle more in 32bit FP mode if this is a mode-selected feature. This is the best time to have floating point support because it is viable, not sensational.

Another example, if you were trying to process dark footage, you might be able to run a processing filter across it in 32bit FP space and draw out more detail without suffering from contrasty or over bright images. You might not like the results if the processing isn't doing what you need it to, but if you have a high gradient density you may be able to refine it. Conversely you may need more pixels to put this spread into, and Vegas7 is limited to 2000x2000 (excluding any pixel oversampling carried out in the 'calculation' pipeline). Yet prior to 32bit FP support, you may not have even undertaken such an adventure.

The significance is only offset by the fact that Sony/SoFo have been doing very well dealing with Y'CbCr sources in an RGB native pipeline. That was not without some good look-up-tables and/or math. So we needn't dismiss the past, but we ought to be ready to embrace the future.

HDI's still hold a significant place, particularly for compositing. Yes, it helps to have 32bit for native...but keying doesn't benefit as much as one would hope.

"Basically worthless to you", "don't believe a word Adobe is saying", "you don't need this", "Vegas is far better", "the noise will mask it anyway".

Oh sorry that was a week ago.

So now it would seem Vegas really wasn't good enough, sorry I'm confused. Either it was a professional application or it wasn't. As one infamous politician from down here liked to say, "Please explain".

Or does the answer really have nothing to do with much of what we think this is really about, is it all to do with something no one has mentioned in this discussion, "x.v.Color"?

Bottom line as I see it is the question really cannot be answered at this point. Does this processing apply to all input formats or just Y'UV (sorry Glenn, I know that's wrong) like formats, will 16bit tiffs now be handled through an end to end linear light pipeline? Can we grade BetacamSP correctly? Can we output better than 8 bit?
Guess we'll have to wait, pay our money and run some tests.

Bob.

Spot, I hear what you're saying, but color me doubtful until I can see a side-by-side comparison.

Okay, so 8 bits gets your 256 shades, which under normal circumstances is enough. Sure, I can see the value of going to 10-bit just to get 1,024 shades for those instances where vprocessing can have a multiplying effect. But 32 bit, with a gazillion shades? Just a touch of overkill?

I have the same issue with "64 bit" processing. Sure, I fully recognize that 32 bits limits memory addressing to 4GB, which was once a huge number but now not that uncommon to find in PCs. Okay, if we need more address space, let's raise it to 40 bits, which gives 1 Terabyte of address space, or possibly 48 bits, which gives--(gasp!) 256TB. Anyone here can tell me with a straight face that this is not enough addressable memory for any conceivable application? Then why the leap to 64 bit? Surely it can't be for address space reasons.

Brian, Please let me know if you find more the one copy of the book
in or around Madison.

Terry

This is where the 32bit processing is meaningless unless you include the fact that it is floating point derived.

Floating point is about carrying fractions of shades through the math. Whether the extremities of the figure to the left of the decimal point is 0-255, 0-65535 or whatever, the usefulness of floating point is fundamentally in the lack of rounding and accuracy in mixing and changing between different colorspaces.

xvcolor, if I'm up on the subject - which I'm probably not, is about making use of HDMI1.3 and having 30bit or gigacolor per channel. Again, this depends on whether the pixel packing format is Y'CbCr or RGB - and HDMI support either or both depending on the source/player.

8bit 4:2:2 is a 16bit packing format with chrominance info (sorry if this is chroma) split between pixels. 32bit fp isn't about cross conversion of this format or anything lesser in color info (like 4:1:1 or 4:2:0). It can be that too, but the fundamental benefit is to be able to handle fractions of color and the election to increase the dynamic range comes from the fact that FP is very efficient in providing both the fractional digital data and the whole number portion together.

Here is one version of 32bit FP, I can't speak for what VegasPro 8 will be using:

"Instead of using 32 bits to describe 4,294,967,296 integer numbers, 23 bits are allocated to a fraction, 8 bits to an exponent, and 1 bit to a sign, as follows:

V = (-1)^S * 1.F * 2 ^ (E-127), whereby:
S = Sign, uses 1 bit and can have 2 possible values
F = Fraction, uses 23 bits and can have 8,388,608 possible values
E = Exponent, uses 8 bits and can have 256 possible values"

Vegas may not waste a sign-bit and by design it might not want as many as 512 levels per channel RGB plane or Y'CbCr vector. However it won't waste a CPU register by stunting it as it can't put another part of the same pixel or another pixel into that same space anyway. If you are following my pixel real estate way of thinking?

So in this example 0-255 of some kind of source (Y'CbCr or RGB, again - not sure if that is pre-determined) remains 0-255 in 32bit FP as well. The exponent would be used for rounding and to aid going back to the native-preview/rendering colorspace

"32bit floating point (IEEE 754 single precision)

* sign:1bit, exponent:8bits, mantissa:23bits"

The more likely representation for VegasPro 8 is 0-255 with 23bits of mantissa. Possibly using the sign bit as a carry flag for a pseudo 9th bit.

As I mentioned earlier, some processing schemes have upset the traditional split for how many bits are used for the decimal and how many for the fraction. There is a tradeoff and usually when you want to beat that you head towards 64bit floating point. Again not so that you get gazillion levels but that the math you do on your pixels between layers, against filters and between color spaces - remains accurate and with latitude/dynamic-range. Going back to my earlier words, a mastering pipeline even though the formats in and out are likely to be 8bit Y'CbCr and constrained by sub-sampling. And yes, it doesn't matter to have all this fine technology if you didn't setup your camcorder right or if the story you tell is duff.

Floating point could be regarded as a compression format. Where instead of having two memory reads, one for the 8bit value (0-255) and another for the fractional and the indicator of how this should be scaled up by factors (actually the word is exponents) of 10 (a 23bit notional memory read) - the two are combined into a single address in memory of 32bits in width. Fortunately the maths chip in the CPU (the FPU or floating-point-unit) is already wired to extract this compressed information so that it can lay the figures out on it's internal squared paper! ;)

1.23232323E02 = 123.232323

This is what is going on with the 32bit FP number. The limit for what goes to the left of the decimal point is up to Sony, but it may well be 0-255 when you give it an 8bit source. If Sony accept a 10bit RGB format, then they might scale that by normalization down to a 0-255 range but they'll lose next to nothing of the additional resolution provided in the 10bit source as this will be carried on after the decimal point. Am I making a point yet or is my attempt to speak with plain english about math becoming too dry?

If you think my attempt is difficult to keep track of, have a spy at the decimal and hexidecimal hodge-podge of lingo in this link:
http://steve.hollasch.net/cgindex/coding/ieeefloat.html

So if you read that link and comprehend it - you may see why I'm suggesting that Vegas may still use 0-255 for the internal RGB figures but the fractions will be on there as well, making the dynamic range at least the equal of an editor, paint package or 3D app that can handle 9,10,11,12, 15 or 16bits of linear or logarithmic representation.

The price is that you can't have your cake and eat it. You cannot read in 4 pixels worth of 4:2:2 per 64bit access into your 64bit memory controller. (this has nothing to do with whether your CPU or Windows is 64bit or not - that is an entirely different discussion to have). In fact notionally, you'll have to hit your RAM 1.5 times to get a single RGB pixel into your CPU (or one day, perhaps also your GPU) from the Vegas pipeline. So practically you want to keep everything in memory and on your hard disk in 8bit Y'CbCr space and sit back and enjoy the fruits of the internal operations in the higher precision.

So the good news is that Vegas is smarter and won't bloat your hard disk or memory requirements. It wasn't so bad before this came along, but if you have aspirations to handle 10bit YUV or RGB sources, this might now be a time where Vegas is heading towards being more capable of handling such a format. Perhaps even 30bit per channel from an HDMI capture card able to handle the data at the higher rate. (not sure if BMD's Intensity can do this or not).

So we've got smart pixel accuracy, probably with some hidden magic for what normalization criterion Sony use internally. Also we've got smart MPEG-2 rendering. We can almost say that HDV is a native format (able to passthrough) like DV has been for as long as I can think back on this product. That is very fitting and those two items together make VegasPro worthy of that name. (but I'll be delighted to see it for myself on a downloadable demo)

"Anyone here can tell me with a straight face that this is not enough addressable memory for any conceivable application? Then why the leap to 64 bit?"

Back in the 80s when PerCom came out with the first 5 Meg hard drive for the TRS-80, a frend and I were stunned. How could anyone
ever use all that much disk space?

In another 10 years 64 bit may not be enought, only time will tell.

If I remember correctly that 5 Megs went for $2500.

Terry

Yo,

PPro was 32-bit in version2, but a comment was made that this was in YUV space. I gather that doing it in RGB is a bit better.

Rob

Does this processing apply to all input formats or just Y'UV (sorry Glenn, I know that's wrong)
Yes, yes it is. :D Is it that hard to say Y'CbCr, or YCC? Where YCC is the abbreviation if you're being lazy. People mostly know what you mean, unless you need to refer to different flavours of Y'CbCr (Rec. 601 or Rec. 709 luma coefficients, different transfer functions, full scale or studio range). But let's not go there.

Is it that hard to say Y'CbCr

It's not hard to type it, it's hard to say it and it's hard to remember it :)
I think what this biz needs is some better nomenclature.
Whenever I try to be correct in conversations I typically get called words that I shouldn't repeat in a public forum. I'd really love to be able to record some of the conversations I've had, some of the ones that go:
"You got a VCR with analogue output?"
"Which kind, component or just composite?"
Pregnant pause.
"The one with a round connector".

Bob.

Well the common words that are 'munged' are:

"Linear" - Does that video gamma or linear to light?
Digital Intermediate - this should really refer to timing a film digitally instead of doing it photochemically. It should not be used as an umbrella term for (non-linear) color grading.
Luma / luminance - Luminance being used to refer to luma, when they aren't the same thing. See the wikipedia article.
30fps - usually refers to 29.97
24- usually refers to 23.98 (or 23.976 or 24 * 1000 / 1001)

30.00 and 24.00 - if you actually mean these frame rates (and not the 1000 / 1001 stuff), stick the zeroes in please.
HD DV - It's HDV dammit! ;)

And... we've officially gone off topic.

Is Vegas 8 the only 32 bit NLE?

No, it's the last pro NLE to get it.

No, it's the last pro NLE to get it.

Than why does Sony say that VP8 will lead the industry in this regard?

Thanks for posting the WMV file.

I just played it on my large Samsung LCD, and yes there is quite a bit of difference. Apologies for the non-math appreciation of this, but it is as if more microphones were placed in the hall to gather more audio. Can only assist when I would come to colour grading and FX-ing.

I can see the skin tones popping out - the 8-bit is ashen and grey-ish by comparison. The shadows of the T-shirt are more depth-ful as are the shadows under the bench. I can see the colour IN the actual shadows. I can see the colour layers going back to the back wall better.

I definitely do not understand the maths, but put me in front of 32-bit floating point and I can see the difference and, here's the thing, the potential.

Very exciting indeed!!

Grazie

Than why does Sony say that VP8 will lead the industry in this regard?

They mean that because it's 32-bit RGB, which may very well be the wave of the future.

Other than that, do ya'll understand now why so many people here have been fighting for Vegas to get out out of its 8-bit shackles?

Many people used other NLEs (or After Effects Pro) and saw that there was a large difference to be had in many cases.

Then they were all poopooed by those who "knew" that "8 bits are enough," "nobody shoots more than 8 bits," "your screen probably can't show more than 6 bits," and "the human eye can only see 8 bits at a time."

I'm really glad for Vegas, because I think that just the high bit support + a decent titler alone will make it possible to win a lot of converts from other NLEs.

Especially if we can get Stu Maschwitz to write a revised "DV Rebel's Guide" where one doesn't need to go from the NLE to After Effects and back, just staying in Vegas 8. I think that would appeal to him immensely.

Or Spot could write the book, "Post It Right With V-8 Speed!"

:O)

Does FCP do 32 bit?