|
|||||||||
|
Thread Tools | Search this Thread |
January 19th, 2008, 05:55 PM | #1 |
Major Player
Join Date: Nov 2002
Posts: 408
|
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?
Last edited by Stephen Sobel; January 19th, 2008 at 06:50 PM. Reason: added a question |
January 19th, 2008, 10:26 PM | #2 |
Major Player
Join Date: Jul 2007
Location: West Midlands, UK
Posts: 320
|
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.
|
January 20th, 2008, 08:28 AM | #3 |
Major Player
Join Date: Nov 2002
Posts: 408
|
Thanks. I'll see what happens.
|
January 20th, 2008, 08:56 AM | #4 |
Regular Crew
Join Date: Jan 2008
Location: Teaneck, NJ
Posts: 30
|
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
|
January 20th, 2008, 09:08 AM | #5 |
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.
|
|
January 20th, 2008, 07:02 PM | #6 |
Regular Crew
Join Date: Jan 2008
Location: Teaneck, NJ
Posts: 30
|
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.
|
January 20th, 2008, 07:40 PM | #7 |
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. |
|
January 21st, 2008, 05:54 PM | #8 |
Regular Crew
Join Date: Jan 2008
Location: Teaneck, NJ
Posts: 30
|
Thanks for clearing that up for me Bill.
|
January 22nd, 2008, 01:27 AM | #9 | ||
Inner Circle
Join Date: Jun 2003
Location: Toronto, Canada
Posts: 4,750
|
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. -------------------------------------- Quote:
And of course, as you mentioned, many of the algorithms can operate in 32-bit. Quote:
|
||
January 22nd, 2008, 01:56 AM | #10 |
Major Player
Join Date: Feb 2006
Location: Perth, Western Australia
Posts: 414
|
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 |
January 22nd, 2008, 09:04 AM | #11 |
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. |
|
January 22nd, 2008, 09:58 AM | #12 | |||
Inner Circle
Join Date: Jun 2003
Location: Toronto, Canada
Posts: 4,750
|
Quote:
Quote:
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. Quote:
----------------------------------------------------- The simple answer is to just look at your final video and see if it looks right. |
|||
January 22nd, 2008, 10:28 AM | #13 | |
Quote:
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.... |
||
January 22nd, 2008, 06:06 PM | #14 |
Major Player
Join Date: Feb 2006
Location: Perth, Western Australia
Posts: 414
|
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 |
January 22nd, 2008, 09:08 PM | #15 | |||
Inner Circle
Join Date: Jun 2003
Location: Toronto, Canada
Posts: 4,750
|
Quote:
Quote:
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. Quote:
It might be some weird Vegas bug/deficiency/ code that's not optimized. Are you running the latest version of Vegas? (8.0b) |
|||
| ||||||
|
|