32bit float vs 8 bit

[Matthew Chaboud]

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.

[Glenn Chan]

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

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.

[Matthew Chaboud]

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).

[Michael Mann]

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.

[Glenn Chan]

YUV, YPbPr, YCbCr

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.

[Mark Duckworth]

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

[John Miller]

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.

[Mark Duckworth]

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.

[John Miller]

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!

[Greg Boston]

Originally Posted by Mark Duckworth

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.

<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-

[Douglas Spotted Eagle]

Originally Posted by Mark Duckworth

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.

When you input 10bit, you get 10 bit out, assuming you have a hardware card that can ingest/output 10bit such as the AJA Xena LH/LHe.

Blame Glenn and David for taking the thread into the realm of "what????"

[Serge Victorovich]

Originally Posted by Douglas Spotted Eagle

When you input 10bit, you get 10 bit out, assuming you have a hardware card that can ingest/output 10bit such as the AJA Xena LH/LHe.

Blame Glenn and David for taking the thread into the realm of "what????"

This meant Vegas8 have a new core and can import 10 bit CineformHD avi's and export to CineformHD 10 bit avi as do it Premiere without internal conversion to 8 bit RGB?

[Mark Duckworth]

Originally Posted by Douglas Spotted Eagle

When you input 10bit, you get 10 bit out, assuming you have a hardware card that can ingest/output 10bit such as the AJA Xena LH/LHe.

Blame Glenn and David for taking the thread into the realm of "what????"

Thank you, DSE. That was all I needed to know. :)

[Jon McGuffin]

There really are some extremely credible and knowledgeable guys here... I really appreciate you all....

If I'm reading this accurately, it appears Sony Vegas 8 is in fact a true 10-bit capable NLE in and out provided you have the appropriate hard/codec's at play.

[Michael Mann]

Originally Posted by Serge Victorovich

This meant Vegas8 have a new core and can import 10 bit CineformHD avi's and export to CineformHD 10 bit avi as do it Premiere without internal conversion to 8 bit RGB?

Is that really so? (Would be great if David Newman could verify that.)