I believe that Vegas only handles 8-bit unsigned integers. So any underlying 10-bit values are converted to 8-bit when it is handed over to Vegas. -Glenn

what? wait. want to be sure i'm understanding this.

so if it's 16-bit sRGB CG, it'll be handled as 16-bit, but if 10-bit sRGB CG it'd be dumbed down to 8-bit? or did i miss something? (i use a lot of 8/16bit sRGB files)

Rob, I think he was just pointing out that all integer math must be unsigned calculations ranging from 0 -255 because 8bit RGB does not have negative values in the computer data for video. :-)

the 10bit to 8 bit comment implies the the 10bit must be "mapped" to a predetermine value..... which is ok but its just simpler to add 10bit values first as a 16bit unsigned math operation then save as 10bit or remap the 10bit to 8bit for output.

It would be a lot faster to just keep everything as 10bit vs all the overhead in remapping/converting. 32bit math for multi track composites is the only to go IN MY VIEW. What screws everything up is when an 8bit filter or "fx" is in the middle. :-(

so if it's 16-bit sRGB CG, it'll be handled as 16-bit
I'm not sure. Vegas might just bring it in in 8-bit form????? It depends on what Vegas supports.

2- My previous post may be incorrect.

There is no 16-bit mode in Vegas, only an 8-bit mode and a 32-bit floating point mode. So you would figure that everything either comes in as 8-bit or 32-bit float.

It would be a lot faster to just keep everything as 10bit vs all the overhead in remapping/converting.
That would work in a world where you have customized hardware, e.g. a lot of the VTRs and decks in the higher-end broadcast/professional world.

But your desktop PC handles math fastest for 8/16/32 bit values. And you are going to have overhead in remapping/converting anyways I believe.

...sigh...

but thx everyone for the info; always like seeing what others are experiencing in this area of NLE work.

"a lot of the VTRs and decks in the higher-end broadcast/professional world"

Um, tape is dead. No one manufactures anything with a tape transport in it.

10 bit recorders are now dirt cheap, cheaper than DV camcorders used to be.

Cameras capable of images that justify 10bit pipelines are not expensive today. Sony's F3 with it's SLog option are standard fare for the indie producers.
The top shelf cameras are now justifying 12 bit or 14 bit recording.

The whole "well you guys can only afford palmcorders and web cams" argument is plain daft. If Vegas doesn't have a functional, easy to use pipeline, suitable for images from anything more than "Dummy Cams" then it will forever be stuck on the bottom shelf. Sadly that's pretty much where it is today and such thinking is in large part why it is there and not just for video post production, the same "near enough is good enough" thinking has killed it off as a serious audio tool as well.

Bob.

If you wanted, you could get a decklink card + RAID array and work with the Sony uncompressed codecs. As far as scopes go, you should honestly get a set of hardware scopes.

But I just don't think that it is Vegas' market. If you look at Final Cut X, they totally abandoned the professional broadcast market... so it seems like other companies don't think it's a good idea to court the professional broadcast market.

"If you wanted, you could get a decklink card + RAID array and work with the Sony uncompressed codecs. As far as scopes go, you should honestly get a set of hardware scopes."

Been there, done that. RAID 0 disks, Decklink card, SDI + 9 pin cable + DVW A500P. Hardware scopes as well. That didn't work thanks to several SCS code screwups.

Moving on to 21st Century and HD.
Sony YUV Codec eats up disk space and bandiwidth. Sure a rack full of SAS drives and fibre would do it. Not that wealthy and Tektronixs quoted me $45K for a 3G SDI hardware scope :( BMDs software scopes way cheaper I guess.
BUT back in the world of what us mortals can afford. Prores, DNxHD and Cineform to name a few are 10 bit capable codecs that don't eat expensive disk space for breakfast.

"But I just don't think that it is Vegas' market. If you look at Final Cut X, they totally abandoned the professional broadcast market... so it seems like other companies don't think it's a good idea to court the professional broadcast market."

True but todays "professional" is tomorrows Indie.
At a technical pixel peeping level more and more I hear people saying "But this is just for YouTube not cinema". BIG MISTAKE. Look at the stiff made for cinema on YT. It looks a million bucks and the stuff that was made for 10 bucks looks just like they got what they paid for.
The more highly compressed the delivery channel the more both sound and vision degrades. I first noticed that going from acetate audio disks to mp3, mush until I spent a lot of time cleaning up all the noise before compression. Same goes for vision. Noise in the blacks eats bandwidth and I'm pretty certain adding in more quantization noise doesn't help.

Bob.

Does everyone else other than me get the exposure right first time and not have to fiddle later on? Does no-one feel the need to lift shadows or backlit subjects? This is where the extra bits would come in handy - to give you latitude for post processing, rather than delivering with high dynamic range (used in its literal sense, not those weird distortions you sometimes see as a result of trying to map HDR to normal dynamic range so that there are no shadows whatsoever).

"Does everyone else other than me get the exposure right first time and not have to fiddle later on?"

I'm getting better but still sometimes when I'm not feeling too confident I do tend to underexpose.

"This is where the extra bits would come in handy - to give you latitude for post processing,"

It's not that simple and this is what (sort of) Glenn was getting at. The noise floor in the all but top end ( >$10K) cameras means 8bpc is adequate. For most of us better chroma sampling would bring more to the table than more bits per channel.

Bob.

Ah yes, you really need true 10 bits quality at the outset, but failing that you don't want the noise to be worsened by subsequent processing.