32-Bit floating point being 4x the data of 8 bit seems like a waste of data and processing power in some instances

That reflects only a lack of understanding of the basics. Float math has no endpoints, so it has no predefined range. Not 32 bits, not 2 bits, not nuthin'. Nor is there any waste of data, which may be far less than 8 bits per pixel in the uncompressed pipeline.

Would thinking of it as "up to" 32 bits of data help?

Exactly, it also refers to floating point precision, not the number of bits defining each pixel's color. I've been editing 10 bit in Vegas 16 for weeks now, it works great. The scopes are very helpful, just be sure to set your view transform to something that closest matches your TV. I also use full range when working with 10 bit (for HDR), as suggested by Magix.

I agree, " precision" may be a better word.

Thanks for your input gentlemen, looks like I might have a bit of light reading to do ;-)

Most of us may have 10bit footage at the best, in some cases 12bit maybe. The 32bit floating point mode is fine for that. For HDR I will be happy when we may have a waveform diagram with a nit scale. And beloved ACES should become better in terms of performance.

"Exactly, it also refers to floating point precision, not the number of bits defining each pixel's color."

I think it does describe the number of bits (per channel) defining each pixel's color, and I think the question in the original post comes down to this: "Is 32-bit float overkill for video representation, given the disadvantages of slower calculations and using more memory?"

I'm not going to second-guess Sony's decision to go to 32-bit float, and I don't have any real insight into the inner workings of Vegas, but I'll add some "light reading" to the discussion.

A good visualization of "floating point" is a digital multi-meter: you have 4 digits to display -- i.e. 4 decimal digits of precision -- but you can select different ranges: Ohms, Kilohms, Megohms, etc.  Or the meter might autorange and just move the decimal point left and right as needed, but you still have only 4 digits of precision -- i.e. levels of detail -- regardless of the selected range.

A 32-bit floating point number essentially has a 24-bit significand (mantissa), coupled with a binary exponent from -126 to +127.  So the effective precision is the same as a 24 bit integer: 1 part in ~16.8 million of whatever range (exponent) you are on. So if you decide, arbitrarily, that 0.00000000 is pure black and 1.00000000 is pure white, you can represent about 16.8 million shades of gray in between (for each channel).

• An 8-bit unsigned integer occupies 1 byte and can range from 0 to 255, so it has a precision of 1/256 of full scale, essentially a "level of detail" of representing some value to the nearest 0.4% of the maximum possible value.
• A 16-bit unsigned integer occupies 2 bytes and can range from 0 to 65535, so it has a precision of 1/65536 of full scale, or a detail level of 0.0015% of the maximum possible value.
• A 32-bit float occupies 4 bytes and has a precision of 1/16777267, or 0.000000059% of the established maximum working value (whatever you decide that to be).

I think AV's comment about "waste" is that Vegas' 32-bit float uses 4 bytes per channel per pixel, which is double what a 16-bit integer would use.  A 1920x1080 RGBA 32-bit "canvas" requires 33.2 MB, compared to 16.6 MB for the same in 16-bit format.  That's a lot of data to move around, and float calculations are generally slower than integer calculations.  But I don't know the inner workings of Vegas, and it could be that the 32-bit float advantages outweigh the disadvantages. Again, I'm not trying to second guess their decision.
 

Well, given the pace of Vegas' development vs new hardware, video formats, etc. Seems like 32bit float is a good choice. Resolve & Premiere are 32 bit internally.

 

I think AV's comment about "waste" is that Vegas' 32-bit float uses 4 bytes per channel per pixel, which is double what a 16-bit integer would use.  
 

Well I guess if that was true it was exactly what I was worried about..data rate to chew through. And a move from 8 Bit to 10 Bit offering significant improvements without the bottlenecks. A little like 2.5K being a viable acquisition format if you want to deliver 1080 without the 4K problems. I would love to see a fast, agile Vegas kick ass to some of the big NLEs in terms of performance. But I'm not yet seeing the future proof vision for the product just yet

Well, given the pace of Vegas' development vs new hardware, video formats, etc. Seems like 32bit float is a good choice. Resolve & Premiere are 32 bit internally.

Premiere Pro CC and Resolve have proper (and extensive, esp. w/ Resolve) GPGPU support. They are handing off a ton of stuff to GPU Compute Units for computation, which do those types of computations faster and more efficiently than a CPU - it's called Hardware Acceleration for a reason.

Remember when PC microprocessors had an FPU as an add-on? Well, we're back to those days. The GPU is the new FPU for computationally-intensive applications.

Vegas is like a spreadsheet that doesn't support the FPU in a computer. They need the next release to re-introduce proper GPGPU support in the NLE - and, for more than just encoding footage. Not having this puts all of their users behind the 8 Ball.

 

I think AV's comment about "waste" is that Vegas' 32-bit float uses 4 bytes per channel per pixel, which is double what a 16-bit integer would use.  
 

Well I guess if that was true it was exactly what I was worried about..data rate to chew through. And a move from 8 Bit to 10 Bit offering significant improvements without the bottlenecks. A little like 2.5K being a viable acquisition format if you want to deliver 1080 without the 4K problems. I would love to see a fast, agile Vegas kick ass to some of the big NLEs in terms of performance. But I'm not yet seeing the future proof vision for the product just yet

That exists already. You have two choices: Edius Pro or Resolve.

It's really about what you need. If you need better performance and support for these workflows, you will get it. Otherwise, it's really nothing more than a consideration.

There can be no future proof vision for a product that is years behind the competition due to slow/laggard development. VEGAS isn't setting the standard, the competition is. It has yet to catch up, so how can it present a vision that is future-proof. They're scrambling to maintain any semblance of competitiveness that remains - and frankly, it isn't competitive with what's out there, yet.

You simply have to give them a couple more years and see what they can deliver. 2020, IMO, is the year to look out for.

Until then, I'm enjoying Premiere Pro CC and Resolve, whilst using my Version of VEGAS just to render ProRes out on Windows.

Trensharo is writing here again and again wrong points. There IS a GPU acceleration in Vegas and that works.

I think Trensharo is correct, and Magix, the new "rich uncle" had better step up its game here. Vegas still is a monster program waiting to be unleashed, but they don't seem to even get it's potential, they keep nickle and diming this, or IF they do (let's give them one more year) like Sony did, and it really will be over. And I am the Vegas fan of Vegas fans, but it's just too glitchy (and I normally cheerlead here, as some know, too well) and it really should work on streamlining some of its slick compositing potential, some routines and quick scripting or key commands, because what it does it does well, when it's not glitching and tripping over itself with its' wonky GUI routines (I could help you guys, seriously, I KNOW what to do).... which is WAY TOO OFTEN...sorry Gary and Co.....maybe they need to let some other people have a crack at it, after years they have become a bit to myopic, and don't really see objectively their own masterwork....sadly.

Do I understand this right when I gather that 10bit 4.2.2. footage can't be properly edited in Vegas?

Also,

32-Bit floating point being 4x the data of 8 bit seems like a waste of data and processing power in some instances (since GPU performance for contemporary cards is not yet fully optimized), and sometimes 10-Bit (being only 25% more) could well be enough yet yield much better outcomes and provide more meaningful capabilities at a better speed/performance balance.

My understanding was that 8bit-Video = 256x256x256 =16.7 million colors, and 10bit-Video = 1024x1024x1024 =1.07 billion colors.

So it's not a mere 25% more information. Or did I misunderstand your post?

Do I understand this right when I gather that 10bit 4.2.2. footage can't be properly edited in Vegas?

That is very much depending on your hardware.

OK, I think I understand that I can only work with 10 bit footage when in Vegas' 32bit mode. Which indeed makes my PC / preview choke.

I guess I could edit in the 8 bit mode and switch to 32 just for the final grading / export?

I edit UHD 10bit footage in the 32bit floating point mode. 8 cores and a R9 390X card. So yes, that is possible. However, ACES for HDR is a tough exercise.

(I could help you guys, seriously, I KNOW what to do).... which is WAY TOO OFTEN...sorry Gary and Co.....maybe they need to let some other people have a crack at it, after years they have become a bit to myopic, and don't really see objectively their own masterwork....sadly.

Without knowing the source code and the issues they may be faced by, it is very unserious to state that you can do it better.

There IS a GPU acceleration in Vegas and that works.

Well if I'm seeing dropped frames on playback and my GTX1060/6 gets used only 13% then I'm not completely convinced about this statement. My hardware profile should allow for better performance than what I see. And that has to be code base and hardware acceleration for sure. I like VP and will continue to support it.

My understanding is that 8 Bits will roughly deliver 256 gradations 'per stop' in a 709 environment (omitting some caps top and bottom), and 10 will do 1028 hence there's more data left in highlights and shadows when squeezing a 14+ stop LOG profile into that space. Hence there's more data left in those areas where you need it. And I was hoping this could prove as a viable & efficient alternative until 32-bit performance is sorted out

"I guess I could edit in the 8 bit mode and switch to 32 just for the final grading / export?"

Yes, this works pretty fine.

You are right. In Vegas it is possible to use an 8bit workflow using LUTs to grade log and even HDR footage - and switch for final rendering to 32bit project settings. However, there are some constraints in such a workflow.  Depends on the details.

hmmmm... looks like a serious hardware upgrade just stepped a few steps up the whishlist, as a Sony fs7 is due soon for 10 bit 4.2.2 footage. It‘s mainly things like banding that bug me most in 8 bit.

exactly what I'm talking about @Mindmatter , [edit: plus you can't effectively grade 8-bit LOG source without falling apart] as I am sitting here waiting & hoping for a meaningful [10bit] A7Siii surprise I want to have my options sorted..

exactly what I'm talking about @Mindmatter , as I am sitting here waiting & hoping for a meaningful [10bit] A7Siii surprise I want to have my options sorted..

AVsupport, I'm mostly still using my A7s I, and I doubt the A7sIII will have 10 bit 4.2.2. internal. They just won't reach into the specs of their higher end cameras.