32 floating bit
 

Can someone explain the pros and cons of rendering in 32 bit as oppsed to the default? Also, why does my video look jerky (in the preview pane) when panning in 32-bit, but not in 8 bit?

32 bit requires more processing power so the jerkiness is probably down to your computer under strain, try and render the footage out and im sure it will be fine. Glen Chand has some great info on the pros and cons of 32 bit, give him a search.

Thanks. I'll see what happens.

32 bit Floating point
 

I'm no expert but I do know that the color space is greatly increased. That makes the subtle transitions in colors smoother such as gradients and even in blown out images. I was at a seminar and they were explaining it much better that I can here but I wouldn't use it unless I have a project that really calls for it such as a well paying gig. If your PC is giving you jerky previews, it's the heavy load that is inherant with 32 bit, after all it's 4 times the color space. If I find the tutorial, I'll post a link

no, 4x the color space isn't right. 32 bit float allows one to bring about 8-10% of out of range highlight information back into legal color space. As for smoother transitions, yes, that's a subset of 32 bit float, but, it's somewhat non-intuitive to use.

Bill, my understanding of 32-bit color actually refers to 24-bit (Truecolor) with 8 additional bits, to represent an alpha channel or as headroom for future applications. I admit I'm not an expert but that seems to add loads to color space and in Highlight restoration. I'd like to know exactly so if you can explain it better please do, I'm a little hazy.

Sherman...

32 bit floating point math, I beleive, refers to the nature of the algorithmns to using 32 bit math, as opposed to 32 bits of data capture and storage. I may not have the jargon exactly correct, but, the principles are right. Basically, 32 bit FPM is decoded as the number of decimal places in the calculation. What this means is that data isn't rounded of to the nearest 8th bit, resulting in rounding errors, which appear as banding. Dithering is pretty important in 8 bit fixed point math to minimize banding. So, while 8 bit only allows 256 color steps, 32 bit math allows over 400 million steps, reducing banding. The vegas I/O processing engine is still 8 bit. Only the internal algorithms are 32 bit, which helps for CCing within the program, but, the results still have to be dithered back to 8-bit for output. Likewise, for input, it doesn't matter how many bits you're inputting, Vegas only used 8 bit input, so roundoff error is still an issue on input.

Thanks for clearing that up for me Bill.

The most obvious benefit for working in 32-bit is that it allows for linear light processing (though it's not necessarily enabled):
http://glennchan.info/articles/vegas...t/linlight.htm

Info on color space conversions with 32-bit in Vegas:
http://glennchan.info/articles/vegas...or/v8color.htm
You need to pay attention to that, because the 32-bit behaviour is different than 8-bit. It doesn't really have much to do with the math, but rather how the codecs work in Vegas / the design of Vegas / the implementation of Vegas.

--------------------------------------
Vegas can import / output 10-bit Y'CbCr over SDI. So in that case it's not limited to 8-bit.

And of course, as you mentioned, many of the algorithms can operate in 32-bit.

32-bit performs a lot slower than 8-bit.

Glenn sorry your the man of the hour when it comes
 

to 32bit questions, it must be doing your head in by now!

But I was reading through your site, and I'm not sure if you can render out to tape from 32bit, I imagine as it's recording to 8bit that the exercise may be futile?

thanks

Adam

Glenn...

If Vegas' internal algorithms aren't 32 bit floating point, I'd like to know how it is that the codecs work that isn't 32 bit floating point math. This isn't rocket science, nor is it hand waving, smoke and mirrors. Please be clearer. What exactly is 32 bit float, then?
Also, given that vegas hardly works with BMD or Aja cards, what consequence is it that it I/O's 10 bit in SDI? For all intents, SDI in Vegas is vaporware.

I'm not sure I follow. I never said that Vegas' internal algorithms aren't 32-bit floating point (or rather, I said that they are capable of using 32-bit float... which is true because you can either go 8-bit or 32-bit).

32-bit float refers to a type of number... on x86 systems it would refer to the format laid out by the IEEE standard (presumably Vegas uses this format... I'd be almost certain).

Similarly, 8-bit (unsigned) in Vegas is another type of number.

Filters can either receive+output unsigned 8-bit numbers or IEEE 32-bit floating point numbers. So depending on the whole signal chain you might accumulate unacceptable rounding error. There are also some conversions between gamma-corrected and linear light that can trip things up... in a 32-bit project, you can have terrible banding if there is an 8-bit-only transition (e.g. many 3rd party transitions); that might or might not be fixed now.

I don't have one so I can't comment on this, but presumably some people out there have working cards and don't have to lose precision in their SDI signals.

-----------------------------------------------------

The simple answer is to just look at your final video and see if it looks right.

I beleive that's what I said.Codecs are nothing more than (mathematical) algorithms. No magic, there. The mathematical precision in windows 32 is 8-bit, unless the algorithmns are re-written to process in 32 bit floating point. A wee bit more precision, but, not much without 64 bit math co-processors. In order to implement 32 bit precision on win32, extra memory registers need to be accessed, somewhat artificially. That's partly, why it takes more time to render. Not only more intense processing, but, more memory needs to be accessed.

Personally, I think Sony pulled kind of a fast one on consumers with their "32 bit float" sales pitch. It misled enough people into beleiving they were now capable of 32-bit depth data streams.
Caveat emptor....

Wow talking about increased render times
 

I expected it to be long, but I was surprised when I rendered 720 50p footage to PAL DVD Widescreen, to render about 1min 10secs of footage at 32bit took roughly 55 minutes.

I mean normally it's like 1 minute or so.

It would definitely be like a days rendering for anything serious, but do I love the extra colour information it brings out!

Maybe time for a eight core Mac :-(

All donations can be made to the 'Save Adams Rendering Time Fund' ;-P

I don't follow you. Windows 32-bit versus 64-bit doesn't affect the bit depth of the calculations or their precision. 32-bit and 64-bit in that context refers to the size of the instructions and memory addresses. The 64-bit instructions bring about a number of changes... but they don't affect the bit depth or precision of calculations.

I'd like to politely disagree here. Doing linear light processing (which requires 32-bit floating point; or similar) is a real improvement, regardless of the bit depth of the input. See the pictures in my article.

Perhaps I've misunderstood you. But the bottom line is that 32-bit float is an improvement in quality (though not necessarily rendering time)... it's visible if you do linear light processing in Vegas.

That doesn't seem right??

It might be some weird Vegas bug/deficiency/ code that's not optimized. Are you running the latest version of Vegas? (8.0b)