32-Bit Floating Point Full Range issues?

JaredF wrote on 4/15/2021, 11:14 AM

I hesitate to start another thread about pixel format, but I’ve been having an issue that I haven’t been able to find elsewhere on the forum.

Using Vegas Pro 18 Build 482. I shoot and edit 10-bit video. Up until now, I’ve been editing my projects in 8 bit full range for best system performance. Then, when it’s time to render, I switch over to 32 bit full range, for better quality and less banding. 

PROBLEM: Sometimes when I switch the pixel format setting from 8 bit full range to 32 bit full range, the image in the preview window stays exactly the same and the final render looks exactly the same as the preview window. Success. But other times, same project, same footage, unpredictably and randomly, the image in the preview window gets dimmer when I switch over to 32 bit full range, and the histogram changes as well. I’m being very careful to make sure my settings stay the same between 8-bit and 32-bit floating point, which are:

Composing Gamma: 2.2
Aces Version 1.2
Aces Color Space: Default
View Transform: Off

Is there something I’m not understanding in this process? Or is it possible there’s some sort of glitch here? Has anyone else experienced this?

PROBLEM 2: If before rendering I instead switch the pixel format from 8 bit full range to 32 bit video levels, the image in the preview windows gets dimmer and less contrasty, as is to be expected. However, when I render out the video, the final video looks ALMOST as I want it to look, except some of the very darkest black detail is crushed and lost. So this isn’t a good workout around.

Comments

RogerS wrote on 4/15/2021, 11:20 AM

I personally stick with 32-bit video levels as avoiding ACES makes it predictable. It also works with LUTs as expected.

It works exactly as 8-bit video levels does (and the same way Vegas worked until VP 18) but with extra precision. So if you don't touch the file's levels it will render fine with no further intervention. (crushed blacks is likely due to an uncontrolled test. Try a grayscale step wedge or other known target and do a few tests)

Personally, I like to see what I'm doing when editing color, so I add a levels filter (studio to computer RGB) to the event or to the video tracks [and not to any tracks with still photos or other full range media], and then back again upon output (computer to studio RGB levels Fx in the preview window) so I don't have illegal levels in the rendered studio-range video.
 

Marco. wrote on 4/15/2021, 12:07 PM

I'd also recommend to use 32 bit floating point video levels instead. Saves you lots of trouble.

JaredF wrote on 4/15/2021, 12:08 PM

Thanks Roger. That sound very similar to how I used to work in Vegas 17 and earlier. Then Vegas 18 came along and I thought "Great, I'll never have to remember to click and unclick those studio to computer RGB levels again."

There's no way to work in 32 Bit Full range without having to interact with ACES?

Marco. wrote on 4/15/2021, 12:46 PM

"There's no way to work in 32 Bit Full range without having to interact with ACES?"

I think this is right, floating point full range at the same time also means ACES based.

But for what reason do you aim for full range? I doubt there is any advantage for you.

JaredF wrote on 4/15/2021, 1:03 PM

I suppose my hope was to never have to use a studio to computer RGB levels filter again. I find 8-bit full range is very convenient because you see full range throughout the entire process and never have to worry about transforming anything or remembering to do anything. But it's only 8 bit...

JaredF wrote on 4/15/2021, 1:09 PM

But I'm convinced, thank you. I'm just going to go back to 32-bit video levels.

Marco. wrote on 4/15/2021, 1:14 PM

Ah, I see. VP uses the clip's color range meta data in float point full range projects but not in float point video level projects.

Actually I'm not even sure if this (not reading the color range meta data in float point video level project) is expected behaviour. I'll ask about that one.

john_dennis wrote on 4/15/2021, 3:09 PM

Look at these three screenshots when you're bored.

https://www.vegascreativesoftware.info/us/forum/color-profile-luts-for-vegas-new--128046/#ca799241

Musicvid wrote on 4/15/2021, 5:52 PM

Then, when it’s time to render, I switch over to 32 bit full range, for better quality and less banding. 

You may be doing the wrong thing for the right reason.

That is because the transform to and from 32 bit populates the lower 2 bits of the frequency domain with some noise, not additional signal. Unfortunately, some seem to choose that happenstance as meaning less banding, rather than a destructive side effect.

Doing these gymnastics can cause long render times, internal gamma shift (like what you have), and grainy shadows, without a measurable positive effect. You can see some old tests in my signature, but they were done in VP14, so won't be discussing.

There are much more controllable means of adding noise to the output, if that helps the perception of reduced banding from 8 bit source. I have found that using a 10 bit YUV intermediate to an external encoder (x264) can tame banding, but not eliminate it.

RogerS wrote on 4/15/2021, 7:10 PM

The source here is 10 bit footage, so isn't 32 bit at the time of render compulsory?

Musicvid wrote on 4/15/2021, 7:40 PM

Look at these three screenshots when you're bored.

Yup, it's working every time with AdobeRGB. Got a Camera RAW profile to test?

john_dennis wrote on 4/15/2021, 7:57 PM

No. Just started shooting RAW in the last few weeks and haven’t even done any video.