32-bit and 8-bit comparison ..

[Graham Bernard]

I love this!

But my Preview fps IS taking a hit though

Grazie

[Seth Bloombaum]

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

[Graham Bernard]

Originally Posted by Seth Bloombaum

That is pretty dramatic.

Was there color (colour) correction applied?

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

[Steven Thomas]

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.

[Brian Mitchell Warshawsky]

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

[Bill Ravens]

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

[Steven Thomas]

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.

[Jon Fairhurst]

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.

[Graham Bernard]

Originally Posted by Steven Thomas

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.

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

[Glenn Chan]

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.

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

[Glenn Chan]

I understand that 32bit has a factor of 4(?) more processing/sampling power - yeah?

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.

[Bill Ravens]

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?

[Seth Bloombaum]

Originally Posted by Glenn Chan

...Anyways let's talk about the practical differences, as opposed to differences on paper...

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

[Graham Bernard]

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

[Seth Bloombaum]

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.