32-bit and 8-bit comparison ..
 

I love this!

But my Preview fps IS taking a hit though

Grazie

That is pretty dramatic.

Was there color (colour) correction applied?

Somehow this is taking me back several years to the days that you had to be very careful not to oversaturate (!) colors in preparing video for VHS distribution. The first image, the editor is saying "this is what you want". The second, the client is saying "No, this is what I want!". To which the editor replies "It isn't going to look that way at home". "But it's what I want!" And so on...

I think the second image is what we all want! And now, it will look that way "at home" too :-)

Yes, to Colour Correction but the same CC for both!!

Yes, the second one.

This 32-bit is astounding me. I can think of much narrative work that I can now achieve with it. More layers and more dynamic range with my glass filters too!! - However, the low fps is a killer for me. I've been asking just what the workflow for good fps should be?

I should actually post a complete UN-touched still .. . sorry Seth.

I'll get on the case with that now .. what a twit!!

Grazie

Correct me if I'm wrong, but I'm fairly certain that when comparing your 8 bit version compared to the same 8 bit video "untouched" 32 bit version (exported to 8 bit), they should appear the same.

>>>>>But my Preview fps IS taking a hit though


Grazie,

Can the effect be simply turned off in Preview to increase the playback speed?

Brian

Steven...

No, I disagree! 32-bit float maps colors to the ITU709 specification, as opposed to the ITU601 spec used for 8-bit. The ITU709 spec allows a full RGB display of colors, ie RGB 0-255. ITU601 allowed a reduced set, RGB 16-235. What this means is more detail in the shadows and highlights, as well as smaller "buckets" for each RGB color display resulting in higher dynamic range(less banding).

Are you implying just by capturing your 8 bit video and allowing the 32 bit option in Vegas 8, then rendering out your video "without" making any edits, the rendered video will appear better (or different) than the original?

I understand the 32bit benefits when color correcting, adjusting color curves, gamma, ect..., then exporting back out to your 8 bit format.

The above photos are comparing apples and oranges.

8-bits and 32-float should not change the overall colors. It should reduce banding and quantization noise, but that's all. It should not change your black or white levels.

If one is 16-235 and the other is 0-255, then one should be adjusted before displaying on the same monitor. If the monitor is set for 16-235, then the 0-255 signal will have higher than normal contrast and might clip. If the monitor is set for 0-255, then the 16-235 signal will have low contrast and look weak and washed out.

32-bit float is great to have, but it should not impact the overall look. For instance, colorbars are a test signal. If you use an 8-bit colorbar signal through the 8-bit or 32-bit paths and do not alter the colors, the final result should look identical. If the results look different, something is not calibrated properly. With a 10-bit color bar input, the maximum difference on any given color should be less than 0.5%. The white and black bars should be identical - even with a 10-bit input.

I haven't/hadn't posted an 8 bit video "untouched" version. As I said above:

"Yes, to Colour Correction but the same CC for both!!"

So, using CC/CGrading and THEN going from 8bit TO 32bit made a helluva difference.

When I saw this, I leapt out of my chair - and wanted to share it! I don't profess to understand 93.67% of what is actually going on - I understand that 32bit has a factor of 4(?) more processing/sampling power - yeah? But the remaining 6.33% of my "awareness" is, I guess, my "WOW" factor coming into play - and when that happens, I wish to share it with my more knowledgeable chums hereabouts. Yeah? What I reeeealy should do is post the untouched version too!

"The above photos are comparing apples and oranges." Well John, I'll take your comment on board. But when I DO switch back and forth, between 8 and 32, with the cursor in the SAME position AND on a frame that has the SAME CC/CGrading and on the SAME monitor, I see this difference. tell me what I must do now?

"32-bit float is great to have, but it should not impact the overall look." - So, 32bit is ONLY for reducing issues amongst banding resulting from some FX? Yes? Then why is it not also possible to then see this markedly different result AFTER using colour correction or colour grading? CC and CGrading are ALSO Fxs - yes? As I say, I don't profess to understand the maths. It was the result that astounded me.

Interesting. If you have any further feedback concerning this I would dearly like to hear it.

Best regards,

Grazie

Nope. You can download both specs for yourself by taking advantage of ITU's 3 free downloads.

709 and 601 call for Y'CbCr values with legal range from 16-235 (assuming 8-bit). There is no 0-255 range, and it does not call for R'G'B' color space.

2- What's happening is this:

When you change between 8-bit and 32-bit, Vegas changes more than the bit depth. Certain codecs like HDV, SonyYUV will decode differently depending on this setting. Other codecs like DV and Cineform do not do this.

In 8-bit, those codecs will decode to studio RGB levels.
In 32-bit, those codecs will decode to computer RGB levels.

I believe the intention is that you keep your project in either 8-bit or 32-bit mode (and 1.000 or 2.222 compositing gamma)... because flipping between the modes can potentially give you headaches.

More info here:
http://glennchan.info/articles/vegas...or/v8color.htm

Not really. It does give you added precision... though not exactly 4X. Floating point gets a little weird in its rounding errors... this gets into some pretty intense computer science. Depending on how you look at it and the implementation, you can either get a lot more than 4X precision or less.

Anyways let's talk about the practical differences, as opposed to differences on paper. In order of noticeability (in my opinion):
A-
You can do linear light processing. Yes you can see the difference.
http://glennchan.info/articles/vegas...t/linlight.htm

B-
The 1.000 compositing gamma implementation in Vegas has some weird-ness and bugs in it currently. You can get terrible banding if you use 8-bit transitions (bug).

C-
32-bit float will avoid banding from sending 8-bit values between filters. But you usually don't get banding problems from this to begin with. You can see banding problems if you are dealing with large gradients and noise-free images.
32-bit float processing won't get rid of all the ways in which banding can happen.
Generally speaking, you rarely have to deal with this problem.

The benefit of 32-bit processing in the case of C is extremely subtle. I never worry about it.

Glenn..

This is rather in keeping with the earlier discussion we had with V7. Importing a color bar generated from my HD110(which is to the ITU709 spec), and using 32 bit float, 2.22 gamma, I see 0-255 on my waveform monitor. The color bars line up with the expected reference values on the WM. If I switch to 8-bit, the image changes. On the WM I see RGB 16-235 and the color bar references no longer align to the actual color bars.

I disagree that clipping or muddiness is the expected result. It really depends on the display media. Too many people who have been in the business since NTSC days think that TV is the only distribution venue. Computer RGB is an expanded color space, every bit as real and even more dynamic the NTSC TV. I agree that output mapped 0-255 will clip on an NTSC TV. I ask, who cares if I don't distribute to NTSC TV format?

Had a few minutes this morning, waiting for the plumber to show up to make our water hot again...

You want to see something interesting?

Put up Grazie's two images from the top of this thread on the timeline, and look at the vector scope. Color correct the 8-bit image until it has apx. the same color saturation as the 32-bit.

What I'm seeing is a huge difference in the color spectrum - about 25 degrees for the 8-bit, about 38 degress for the 32-bit. (is that (38-25)/38=34% more of the spectrum?)

I'd wanted to see if I could color-correct the 8-bit output to look like the 32-bit. No way. The 32-bit engine is pulling color info out of the m2t file that you can't get any other way (like Glenn said...).

So? Is this a good thing or not? You kinda lost me at the "Plumber called"!

So, am I seeing good or not? I think it is good .. .

Seth, thank you for taking interest and the time on it. There has been much written on 32-bit in V8 on several V boards, I kinda like the idea that these pics might be being of use - apart from the "WOW" factor I got.

Seth, is it good news?

Grazie

More video - less plumbing. Too much dirty wet water... then there's the electricity, they don't mix. But, ya' know, we could probably all make more money in plumbing! All done now.

Grazie, I think it's *very* good. What the vectorscope seems to be saying to me is "34% more colors!" with 32-bit processing through CC. Imagine some old laundry detergent commercial... "new Scrubsoft, your old clothes now with 34% more color!"

It seems to me that it shows that there is more color available in a well-shot HDV tape than can be exploited with an 8-bit workflow. I don't pretend to understand what the various color spaces offer us, nor can I compare and grok 8-bit acquisition with 32-bit internal processing to 10 or 12-bit acquisition and processing (is that what DVCPro HD through Premiere gives you?).

But I do know how to read a vectorscope, and there's just more color in your 32-bit than 8-bit image, and it's not as simple as saying "oh, it's just more saturated", there are actually more colors - a larger samping of the color spectrum - in the 32-bit image.

If some readers of this thread are not familiar with the vectorscope, it is an easy way to measure the hue and intensity (saturation) of a color or an image. I think of it as the 360 degrees of the circle representing all the color hues. Distance out from the center is the saturation.

It is a *very* handy tool for checking that colors are not oversaturated, or, to match or complement a particular color in a scene. Also used quite a bit in matching cameras, or, matching camera tapes. Definately look at the vectorscope when you're color correcting . Try it with a solid color, bars, people, other familiar and easy to understand images - there's an education right there.

So, what I am seeing in the 32-bit image is (mostly) a color range from about 140 to 102 degrees, plus a spike at 241 that probably represents the green duck head. After adding saturation to the 8-bit image, most of the color info is in the range of 128-103 degrees. These are all approximations.

Bill,
The color bars may not line up since the waveform monitor has its own settings for studio RGB versus computer RGB. The color bars will probably line up right if you set the WM appropriately.


Back to the main topic...
Some(/many/all?) filters will yield different results depending on whether you feed them studio RGB or computer RGB levels. So that might explain the differences in Grazie's JPEGs.

For the record, I used 32-bit 1.000 Linear working ON a 2 Link chain:

Link 1: CC - To achieve a better balance PLUS more contrast. Interesting, Glenn, 8bit gives me 95 on the Waveform (Luminance) Scope and 32bit gives me 98. Doesn't sound much, but at that high end it does quite a bit. PLUS 32bit removes a pink blush from everything too. This has to be the accuracy kicking in - yes?

Link 2: CCurves - To achieve a bit more warmth to the now CC-ed coldish look. The "reeds" which were pale-ish are now ruddier. But using the 32bit did NOT seriously affect the "green" watery look - which I wanted to retain.

I am still searching as to where I shall fit this in to my "creative" workflow and not get bogged down with low fps rates.

Best regards,

Grazie

It's probably not the extra accuracy, but rather the filter being fed with computer RGB versus studio RGB levels.

There's different numbers going into the filter... so therefore different numbers come out.

Where's that happening?

G

Flipping between 8-bit and 32-bit will change the behaviour of some codecs.
http://glennchan.info/articles/vegas...or/v8color.htm

HDV will decode to either studio RGB or computer RGB depending on the bit depth of your project.

Seems to me, then, that the vectorscope is currently inadequate for displaying the 32-bit float. Might I suggest a note that appears on the vectorscope that alerts the user as to which REC (601 vs 709) is being read/used, as well as a button to correct the readout. The vectorscope in DVRack/HDRack, reads out which color space is being used.

That's a good suggestion, Bill....having a small "601" or "709" appearing in the upper or lower corner...

It's always 601.

If you could flip between 601 and 709, the color bar targets would move (since the luma co-efficients are different). You can see this in FCP.

2- The difference between Rec. 601 and 709 is not the same as computer RGB versus studio RGB levels. It's two separate issues.

3- The settings for the scopes will affect its read-out.
7.5 IRE setup
computer RGB / studio RGB

There's no indication as to what the settings are.

Glenn..

Isn't it incorrect, and even useless, if the V8 vectorscope doesn't show REC709?

very confusing

It's really not that confusing. Had the two samples been posted with no discussion of color correction, or had the samples been generated with no color correction and simply an "8 bit display" and a "32bit display" it would make more sense.
What you *need* to know is this:
32 bit float modes will decode slightly differently than 8 bit mode with certain types of files. HDV, XDCAM, AVCHD benefit the most from this mode.
It "stretches" the gamma by nature of the additional bits. If you don't like this mode, then either stay in 8 bit mode, or use the 2.222 mode found in the 32 bit mode dialog in the Project Properties dialog.

It's really pretty simple overall.

Yes and no? It depends on what you're using the scopes for.

2- Hmm my previous post may be wrong. It might be that Vegas' scopes behave as if they were monitoring a NTSC Y'UV signal. NTSC Y'UV is not the same as Rec. 601 Y'CbCr and not the same as Rec. 709 Y'CbCr.

2b- Basically the difference for the vectorscope is that the values and color bar targets move around.
http://www.dsclabs.com/images/244_VS_Web.jpg

The reason why everything shifts around is because all the numbers change.
The R'G'B' signal is converted into Y' B'-Y' R'-Y' and then into either Y'UV, Rec. 601 Y'CbCr, or Rec. 709 Y'CbCr.
The formulas are all different... you can look them up in Charles Poynton's book.

2c- The Vegas scopes can be misleading/"wrong" for various reasons. They do not behave like real hardware scopes and cannot do everything the hardware scopes can do. e.g. Hardware scopes can show the true levels for analog or SDI signals. Vegas' scopes can't do that.

3- The Vegas scopes behaviour can be somewhat useful in the following situation:

You pick chroma values off the scope and take note of their magnitude and angle. e.g. You can mouse over the scope and vegas will show you % and degree.
If you move between SD and HD resolution, the numbers will stay the same.

If Vegas had the FCP behaviour, the angle and magnitude would change depending if the project were SD or HD.

Indeed. I'm very confused about what the scopes show.
Nevertheless, Spot, let me be clear...I love the 32 bit mode. I'm just trying to understand what the technology is doing.

1- See my updated post.

2- The Vegas is somewhat like the following situation:

You took a composite SD, analog signal out of Vegas into a scope. This is what the Vegas scopes emulate. (Though there are differences, like what markings are on the scope and the terminology compared to a real vectorscope + waveform monitor.)

Graham, if you're still following this thread, would you do us a favor?

Would you, please, post the original images in their "raw" state, without any correction or changes, other than one in 8-bit and one in 32-bit using the 2.222 mode?

Thanks!

Your wish, Jay, is my command.

They ALL look the same to me? What is being ascertained by me doing this? Please let me in on the secret.

ALL 3 options: 8bit - 32bit Video 2.222 - 32bit 1.00 Linear - NONE having any FX-ing.

Grazie

1. What is the source?
2. Depending on the source, it's quite easy to see what's being done with the image.
3. Where are the images?

Attaching is going wierd on me . .

Trying again.

G

1 - Source - PAL SD

2 - Eh? I can tell you what I've done?

3 - I tried to upload 3 at once. Now trying to do one at a time.

Regards

Grazie

Trying the last one . . seesshh .. "UPLOAD" is telling me I have already loaded it?

Where?

Jay? can I give you this last one for YOU to load? I can't load it!!!

I've tried 3 times now, and I'm being told I have ALREADY uploaded it!! The WIERDNESS is that the UPLOAD manage attachments is telling me it is already loaded - ERROR - but I have even renamed it?!???

Help!

Grazie

There is no difference when dealing with DV. This is why I created the HDV projects for you to compare.
You'll see a diff in SD when you color correct and push color; the banding normally associated with pushed DV/8bit disappears.

Exactly! What I said was that AFTER doing Fx-ing, and compared to 8bit, the 32bit results just lept out at me. And yes colour push and BANDING will be "smoothed".

It was this extraordinary result I got from using 32bit applied to my Fx-ing that thrilled me.

Eh?

Regards

Grazie

Oh, my mistake about the levels differences being the cause of why things look different.

For DV footage, flipping between a 32-bit (2.222 or 1.000) and 8-bit project won't cause the codec behaviour to change like with HDV footage.

However, flipping between 2.222 compositing gamma and 1.000 will cause the behaviour of the filters to change since they are being fed with linear light values instead of gamma-corrected. That should be what you're seeing. If you flip into 1.000 compositing gamma it should look extremely similar to 8-bit.

That's what I wanted to see. Somewhere, I read something that led me to believe that the 32bit alone added some visual improvement. Not having it installed yet, makes all this most difficult to grasp.

Thank you, Graham, for your effort and patience!