Still no word of 10bit support. sigh.
Everything else sounds great.

10-bit? ...... how about 32-bit?

-Dan

Yeah, something isn't right with this "32-bit video signal path" they are talking about. This is not the same thing as true 10-bit video, I'm fairly certain of that.

Jon

What? What's not right about it? It's the same color space Adobe After Effects works in. It's not like it's impossible.

Jon,
I think it's the real thing.
http://www.videoguys.com/vegaspro8.html
and to think all I was asking for was 10bit.

"32-bit Floating Point Video Processing
Surpass traditional 10-bit standards with 32-bit floating point video processing. Take advantage of greater color range for more vivid colors, reduced gradient banding and posterization for smoother color transitions, linear light capability for optically correct compositing, and many other precision enhancements."

32-bit floating point video processing is the not the same as a 10-bit colorspace. It's like comparing a 64-bit CPU to 24-bit color display on your monitor (which is 8-bit RGB, and 32-bit color is 12-bit RGB).

The words in their language is "floating point video processing". This would indicate more of a color processing performance advantage and their wording following this supports that.

The fact they are comparing their 32-bit to 10-bit "standards" has me thrown a little bit and maybe questioning my skeptisicm. Either they are pulling a Creative Labs when creative tried to sell us that their X-Fi Crystalizer was so powerfull it would increase the resolution of the original music (which is bogus) or there is something they are doing that I don't quite understand.

Jon

Huh??? 32-bit color usually means 4 channels (RGB + alpha) with 8bits/channel.

So is Vegas 8 a '32-bit' capable application or a '12-bit' application?

Jon

I'm telling you, something feels very fish about the claims Vegas is making..

To suggest that Vegas was ONLY an 8-bit color application is crazy. 8-bit color is only capable of 256 colors. Remember the old VGA standard?
See here:
http://www.cambridgeincolour.com/tut.../bit-depth.htm

To now go from 8-bit all the way to 32-bit when SGI and the like all work in a 10-bit or 12-bit environment is fishy.

I'm pretty sure what is going on here is we're talking about bit depth per color channel which means vegas is/was an application working in 24-bits 16,700,000 colorspace (8-bits X RGB or 8-bits X YUV).

Now maybe it's capable of processing colors in 32 bits which is a "fancy" way of saying it processes in the 12-bit realm.

But still... why aren't they advertising this as a "12-bit color with 32-bit processing"

The floating point remark refers to mathmatical calculations not color density...

Jon

Jon.... 3 x 12 = 36. Not 32.

Vegas 7 and previous versions were always capable of 8 bit / CHANNEL, not 8 bits / pixel.
8 bits / channel
is
24 bits / pixel
assuming three color channels (red, green, and blue). 8 bits/channel X 3 channels = 24 bits.

Glenn,

Is that not what I said my my very next line? That we were talking bit level per channel. So what exactly does vegas mean by saying its 32-bits?

When discussing computer graphics, bits-per-pixel was used as there is only one color system 4:4:4:(4) RGB. In video systems, channel depth was used as bit-per-pixel is more confusing. RGB 4:4:4 is 24-bit in computer graphics terms and 8-bit in video terms, then consider 4:2:2 which is still 8-bit in video terms, but an averages 16-bits per pixel. 4:2:0 is 12-bits-per-pixel, yet still an 8-bit video system. You can start to see why bits-per-pixel is not used in video systems, as it requires a deeper understanding of the color sub-sampling. 10-bit 4:2:2 YUV is for pro broadcast applications, with an average of 20-bits per pixel, it looks significant better and more flexible than a computer graphic 24-bit image, as it has 4 times the number of luminance levels.

You'll first want to understand the difference between processing bits and color bits.

Technically it doesn't. ;) Only the values 64 to 940 have legal luma levels. The values below 64 should not be reproducible (because it calls for negative light).

They also aren't luminance levels per se, since video uses luma. See
http://poynton.com/papers/YUV_and_lu...e_harmful.html
or
http://glennchan.info/articles/techn...ma/chroma1.htm
(my article has pictures and shows flaws with 4:2:2 chroma subsampling)

2- In my opinion, 8-bit R'G'B' (no subsampling) is superior to 10-bit 4:2:2 Y'CbCr as chroma subsampling can produce visible artifacts (see the pictures in my article). Here the distinction between luma and luminance is actually important. I prefer using the correct terms as the difference can be somewhat significant (assuming you are bothered by chroma subsampling artifacts).

But anyways, this is perhaps getting overly overly complicated. :D

Glen,
Whats your take on the new color processing or are you under a NDA?

I disagree, and so does most of the industry. While chroma subsampling is an artifact, so is 8-bit contouring/banding, which I fell is a more significant artifact under normally viewing conditions. 10-bit 4:2:2, matches the human visual system better than 8-bit 4:4:4, that is why it is better performer.

Negative light - nonesense. The full luma range is able to you, yes the extremes value are super-black and super-white they perfectly usable and highly valuable. Some lowend solutions just crop them off, yet these values are increased dynamic range of YUV over CG-RGB. Nearly all video cameras use these values. Now Vegas uses video systems RGB, so the 0-64 luma values map to 0-16 in RGB, so it is not even negative in the Vegas presentation. Vegas uses a wider gamut RGB so it can store the naturally wider gamut of YUV. So 10-bit YUV does have 4 times the luma levels as 8-bit 4:4:4 video systems RGB.

While the term luma is more correct, I was describing the number of discrete brightness levels, so accurate color system terminology is not needed.

Fully agreed, David. Indeed the 8-bit quantization effects you've mentioned were an annoying problem for some owners of the original Canon XL1. It's ancient history now, but I documented this issue long ago (with a lot of help from Don Palomaki) at http://www.dvinfo.net/canon/articles/article10.php

For the layman getting confused...32bit float is better than 10bit, way better, in terms of processing RGB color and everything else, even if you final output will be 8bit per channel. Until recently only programs like AE, Fusion, Nuke and other high end compositing apps supported it. (not counting Cineform).

Hopefully this will mean Vegas users can take full advantage of Cineform tools.

Awesome is an understatement for me.

After Effects supports 16 bits/channel (so that's 48 bits/pixel). The Videoguys blurb says that Vegas supports 32-bit floating point color, as opposed to 32-bit RGB (8 bits/channel + alpha).

I'm curious what kind of color management support Vegas will have.

AE 7 and CS3 support 16bit integer per channel and 32bit float per channel.
You are referring to the way color has been referred to in marketing terms

aka 32bit color is actually 8bit per channel plus 8bit alpha.

I know it's confusing to a lot. If we referred to it the way salespeople do we could say 128bit floating point color. (adding the channels together).

Hope that helps

I'll give you my thoughts after V8 ships.

If you find natural world objects that are of green and magneta concentric circle then use 8-bit RGB, for the rest of the planet 10-bit 4:2:2 is simply better workflow, that is why it is the workhorse format of HDSDI (not 8-bit RGB.) Of course 10-bit 4:4:4 is better still, that is way we have dual-link HDSDI. Remember this forum primary concern and that film and video production, which requires color correction, when you push an 8-bit image you get less than an 8-bit image, coutouring occurs requiring noise to be injected, which hurts down-stream compression, which is most likely 4:2:2 or 4:2:0 anyway. Starting with more bits, color correct without banding so you can produce the best 8-bit sub-sampled deliverable. Even many film-out have gone through a 4:2:2 10-bit workflow. In the end you can't argue your way around what works particularly, the academic position that 8-bit RGB is better, doesn't holdup to what is needed in post production.

Which was the theme of my last post. Color correction simply benefits from more luma bits than it does from more chroma spatial resolution. As most post production undergoes color correction of some type, most benefit the increased luma precision.

You're still in a situation where you need to pick a poison.

With 8-bit you can get contouring. Ok.

With 10-bit 4:2:2, you either:
A- Get generation loss (if you do chroma filtering and reconstruction properly). To do the image processing properly, you need to convert from 4:2:2 to 4:4:4 and then back down to 4:2:2 for output.
B- Or you get bad quality and no generation loss (by using box or point resampling on your chroma).

In practice it's mostly a moot point since no useful camera records 8-bit R'G'B' (AFAIK... unless you count NoX???). Better yet to go with some flavour of higher bit depth and 4:4:4... which is what Red is doing with their Redcode RGB codec (no chroma subsampling), and what you can do with dual-link HD-SDI. Or lightly-compressed 4:4:4 (e.g. Cineform, HDCAM SR).

In my opinion (and I hope you agree here!) is that lightly-compressed 4:4:4 is a better workflow and better quality than uncompressed 4:2:2. 4:2:2 is simply bad compression at high bitrates. If you look at JPEG, the better encoders only resort to chroma subsampling for the lower bitrates.

For those following this thread, it's been split off as it's significantly deviated from the original post/topic.
That said, it's fun to read the differences of opinion between the academic side and the practical/perceptual side of the split topic.
Academically, I suck. I can manage the base levels of the argument, but I'll leave the math to experts like Glenn and David.
Practically, only a blind man can't see the differences between 10bit and 8bit, or 8 bit and images processed within a greater dynamic range.
As an example (for those of us that arent' math geniuses) I've rendered out the same file segment in SD MPEG.
The origin is unprocessed/corrected, improperly exposed HDV from a Z1, gain set to +3, shutter @1/60, aperture of f1.8.
Here is a zip file of both MPEGs. Nothing different about them whatsoever, except changing the bit depth.
I'll make the original MPEG clip available for you to play with yourself once V8 is in downloadable/demo form.

this is similar to what i asked here:
http://www.dvinfo.net/conf/showthread.php?t=101786

even if we could capture @4:4:4 uncompressed, edit in that mode, the final output can't be enjoyed by avg. joe's without powerful PC's. if you CAN capture, keep the raw footage+editing in 4:4:4 10/12-bit and OUTPUT in the same high color depths, i think the final results will surpass even today's blu-ray+HD DVD. video will finally come close to replacing FILM =P. i think color is the final frontier in these day and age for NLE editing... not HIGHER res. we're @a point that if we go with higher res. now (4k/8k) @home, we won't reap additional discernible quality differences with regard to how color is currently managed.

That is way we make CineForm 444, it is a 12-bit per channel encoder. So yes we agree on this.

To clarify something...

I am not talking about 32bit versus 8-bit (or the 32-bitness of Vegas 8).

My comments were referring to
uncompressed 4:22 10-bit Y'CbCr
versus
uncompressed 4:4:4 8-bit R'G'B'

as formats. Both can be viewed as (small) compromises in quality... you either have the lower bit depth or you have the chroma subsampling (neither of which are always ideal).

This is not the same issue as processing images in 8/16/24/32/64/80/(10/12/14)-bit signed/unsigned integer/floating point/whatever values. You can take either of those two formats and process them in whatever type of values you want.

Sorry if that wasn't clear... I went off on a tangent. Not much to do with the 32-bitness in Vegas 8. It may have seemed that I was disparaging Vegas 8... this is not so!! (It will rock.) Move along folks...

Not sure if I should apologize for being at least partially responsible for taking the subject of this forumn off topic. Very glad to see David, DSE, Glenn, etc chime in on this subject.

Still haven't actually figured out from any of the posts if the 32-bit "floating point" calculations on color is really the same thing as comparing 8-bit, 10-bit, and 12-bit but frankly, the subject is way over my head and If any of my previous posts mislead anybody, I apologize. I'd like to learn more. Any chance there is a good publication out there "Video Color Bit Depth for Dummies?"

I was merely trying to point out that the wording that Vegas has chosen to describe their new color capabilities didn't seem to make it very clear and I was a little skeptical of exactly what their claim meant. Is this concern justified? With that said, I have no doubt this feature is a plus...

In reviewing the images DSE posted regarind 32-bit vs 8-bit... I must be a blind man because the only differences I felt I could really see was in the way compressoin had been applied. It appeared there were slightly more artificats in the 8-bit version, but the 8-bit version almost appeared to have more detail to me. Not really sure, but spent 5-10 minutes going back and forth and the only advantages I could see in the 32-bit other than the artifacting issues being less is that the colors might be a bit more vibrant, but I'm not sure this is necessary a good thing either.

I'm looking at things such as the blue sticker that's on the tripod, the images of the pictures on the wall to the left. I'm also looking at the text on the sign on the back wall.

My fear is that this great new Sony feature of 32-bit processing is going to come at a huge penalty in performace which, to me, is something not acceptable. Vegas is a good performer now, but I think it could do better while working in HD formats such as HDV, etc.

Jon

Wow... this has gone off the rails a bit.
 

My understanding is that Glenn is no longer under NDA on 8. He should check with the responsible parties if he is not sure.

There are a lot of things swirling around here, so it's understandable for people to be confused by all of 30 words on the subject from bullet-points.


8-bit/Channel RGB (i.e. Vegas 7): 256 levels per channel, essentially between specified 0 and 1 definitions when presented, non-linear (otherwise, 256 levels of gradiation would not be enough for human vision). Those of you who are really on-the-ball with Vegas have noticed that Vegas 7 does its processing (most of it) as if what it were using were linear, even though the underlying data is expected to be non-linear. I accounted for this in my pseudo-Technicolor presets. Those of you reading one of Charles Poynton's rather excellent books would get on me for not saying RGB prime...

10-bit/Channel YUV (e.g. SDI): 1024 grey levels, still generally between specified 0 and 1 definitions when presented. This is typically processed in 16-bit because of modern computer hardware performance.

32-bit/Channel float RGB: This can mean a lot of things:

- It can mean having higher-precision for 0-1 (0-255) ranged data. This results in minimal quantization from intermediate processing.

- It can mean having negative RGB values. These can be entirely valid values when converted to other color-spaces, and some are, most importantly, colors that humans can see and displays can show.

- It can mean having RGB values greater than 1. This is most commonly called High Dynamic-Range. Let's be realistic about this. Once the data is floating-point, the world could just agree to have blindingly-bright be 0.1 and, for most practical uses, we'd never break 1.0. As it stands, though, HDR is really a way of expressing values beyond previously specified limits.

- It can mean not needing to use a non-linear reponse representation for storage/processing, which is most commonly referred to as "linear light."

- There's more, of course, but these are the obvious ones for work being done these days.


I'll leave it to the others to fill in all of the details of the updates to Vegas 8, but I will say that it does a few things:

- You can still be in 8-bit, just like Vegas 7. Everything will run as fast (actually, generally faster) as before, and you'll feel right at home.

- You can do your processing in 32-bit float. Some things will look much better, you'll be able to pull some new tricks, and it will be slower and use more memory.

- You can take in and output 10-bit YUV, provided you have the hardware to do it. By that, of course, I mean cards that are not produced by Sony.

Hold on a second... you mention that someone might get on you about R'G'B' and then go on to say YUV? I find that interesting, since his book (and website and SMPTE EG 28) goes on to point out that YUV is usually the wrong terminology. Though it's not like anyone is going to be burned at the stake for it. I just find it interesting.

2- It's my understanding that I shouldn't be talking about new features in Vegas 8 quite yet.

Okay captain pedantic...
 

We'll add you to the six people who draw a sharp distinction between YUV, YPbPr, YCbCr in casual conversation... <g>

Honestly, there are groups of people in which I would draw the distinction. I'll consider adding this group to them.

It's important to note that a gamma difference is really a far greater visual problem (for natural video).

I am confused:
Is Vegas 8 (presumably!) going to support more than 8 bit (per channel) color depth files
OR
is it more likely that it "only" computes video effects in a 32 bit (per pixel?) depth.

Thanks for any clarification in advance.

To get really pedantic... :D
it should be Y'UV Y'PbPr Y'CbCr. Where, as you already know, the prime symbol ' denotes gamma correction.

And now I believe I've really pushed this thread off-topic.

Sorry to interrupt the finer points of apostrophe placement but I have a simple question to ask that needs a yes or no answer.

Will it be possible in Vegas 8 to import a clip that is 10bit 4:2:2, edit, CC, and so forth and then export the edited clip back out of Vegas 8 as 10 bit 4:2:2?

Thank you in advance for your replies (Yes or No,please).

Cheers

As DSE mentioned in passing, this all has to do with the precision of the intermediate calculations used and nothing to do with the depth of the colorspace etc.

Traditional "RGB" and "YUV" use 8 bits per channel - i.e., integer values from 0 to 255. If intermediate calculations are also limited to 8 bits, you will get very noticeable artifacts in the final image.

By way of example, consider a simple case of converting the R channel of an RGB image to a third of its original value. i.e., R -> R * (1/3) etc. In an 8-bit integer world, the first problem is that 1/3 can't be represented. To get around this, the calculation is broken into two parts, both using a scaling factor:

R -> R * (1000 / 3)
R -> R / 1000

The larger the scaling factor (1000 in the above case), the more precise the final result will be. Due to the architecture of PC CPUs, the typical factor is 65536 which allows for some shortcuts to be taken.

The consequence of doing the above is that the result of the calculation is still an 8-bit integer. If additional processing occurs on the frame (e.g., color correction followed by scaling), artifacts of the 8-bit calculations may occur.

When done correctly, 8-bit integer calculations are actually performed at a 32-bit level on the CPU. The intermediate values can be stored at a higher bit level (e.g., 10- or 12-bits), with only the final values being rescaled to the correct 8-bit level.

These kinds of integer calculations are *very* fast on a modern CPU.

The same CPUs support calculations at a 32-bit floating point level. They are somewhat slower and raw 8-bit data have to be converted to 32-bit floating point. Once the calculations are done, the floating point data have to be converted back to 8-bit (for typical SD etc). Additionally, the CPU can perform twice as many integer calculations at a time than 32-bit floating point (due to the way SSE/SSE2/SSE3 etc work).

Frankly, the use of 32-bit floating point has marginal benefits over correctly implemented integer calculations. Many high performance codecs for MPEG2, DV etc use an entirely integer pipeline for their calculations. The determination of such things as discrete cosine transforms (DCTs) demand very precise calculations. These are often integer-based and, in some cases, must pass stringent tests to be deemed compliant with the compression standard.

I think I am back in Philo 101
 

Why is it when someone asks a simple question and asks for a Yes or No answer they get a five hundred word response ( I am not singling you out Mr. Miller, it's this entire thread). Simple answer, please, please, and please. When you put 10-bit in, will you get 10-bit out (all codecs and flavours put aside).Yes or No? Which is it? I appreciate the education that I get when I read one of these threads as the knowledge of the members here is staggering. But I am not a mathematician or interested in anything more than the basics, so if any of you will dare to hazard a guess and give me a Yes or No answer to my question that you are sure is at least 80% accurate that would be wonderful.

Thank you for your time.

Sorry, Mark - my reply wasn't to your post - it was a general reply to having read the thread.

After I posted, I thought I should have mentioned as such....

Re your question - I would certainly hope so, but since I live in a 8-bit world, I daren't commit to a yes or no!

<humor mode on>

Mark, the problem with your request is that the forum software won't accept a simple Yes or No answer. I believe the minimum response is at least 10 words.

<humor mode off>

Honestly, I can't answer your question. It seems very logical though that this would be the case. Hopefully Spot will chime in if the NDA's have been lifted.

-gb-