Yes, in addition to being sharper, your closeup reveals more contrast and a slight blue shift. I can't think of a better way to visually enhance an existing band, which "may" be identical in magnitude.

You are acutely aware of minor image variations, on that I agree. However, one must be extremely careful to know just what he is looking at, and not to assign attributions and conclusions based solely on expectations in the absence of other assignable data; as such impressions can always be explained at their least by the placebo effect. Or even fish tales.

8 bit image gradients will always have banding, regardless of source or signal processing, and these can be made more or less apparent by perceptual factors other than the actual magnitude or the frequency of the banding.

The proof of this statement lies, surprisingly, in the debate over 8 vs. 32 bit processing of 8 bit source itself. And to many, visual evidence alone seems to support the notion of "less banding" by 32 bit float signal processing (shout it from the rooftops!).

In reality, what happens is the appearance of banding is being masked by two distinct types of noise, which degrade the whole image: 1) Frequency (temporal) noise being introduced into the lower two "empty" bits, really a Q-noise artifact, which being retained in the float range, is thus injected back into the 8 bit during reconversion;

and, 2) old school dithering (spatial) noise, which can be really detrimental in the case of pattern dither.

I'd run some tests and see if there is visible banding or other artifacts, such as on skin or sky gradients. If you're not sure what you are seeing feel free to upload a clip post LUT. The Iphone has some 10-bit options, not sure about the 5.

I did. Interesting results. Pixel 5 cannot record in 10-bit color in FilmicPro, and even if it might be able to in the Google Camera app, the other features of FilmicPro are too valuable to me to use the native app.
There are 5 color profiles for Pixel 5 within Filmic Pro: LOGv2, FLAT, DYNAMIC, NATURAL, NATIVE. Both LOGv2 and FLAT require a specific (and different, of course) LUT to translate to Rec.709.
A distressing and not-yet-understood phenomenon happened with all but the LOGv2 profile: grotesque pixelation during camera movement (panning slowly on a tripod).
All the clips I took were recorded at 120 Mbps data rate, HEVC CODEC, 2160p, 23.976 fps. That taxes the little phone, but I began and ended with a LOGv2 capture, and even at the end, that was the one profile that didn't get garbaged-up with motion; so, I am sure "overheating" wasn't the cause.
LOGv2 still (after LUT translation to Rec.709):

FLAT still (after LUT translation to Rec.709):

DYNAMIC still:

NATURAL still:

NATIVE still:

A few seconds worth of each color profile (this is not the panning portion of each shot, but there is some residual pixelation happening in all but the LOGv2 profile...

Notes on my previous two posts with the stills and the short video example of the 5 profiles:
1. NO color grading was done in VEGAS Pro to any of the clips.
2. I wanted to shoot at a fixed "shutter speed" of 1/48 sec; however, the light was too bright for that, even with the Moment brand Neutral Density (32) filter I used. I kept the shutter as "slow" as possible without overexposing the sky.
3. My conclusion is that I should shoot in LOGv2 in FilmicPro, apply the specific LUT for translating that to Rec.709, then do a little grading to get a desired look.

Given all of that, I am eager to read any feedback or suggestions, including why my conclusion may be wrong. Thanks, VEGAS Pro community! You share valuable insights and information.
 

. Quantization error also creeps into content and increases with every added track.

Excuse me, what?

Yes, that's exactly right. The only audio work-arounds are increasing digital word size or summing in the analog domain. But summing in the analog domain isn't an option for video. I'm just not sure there is an actual issue in video if data sizes are sufficient large already. Being that the digital solution works by pushing the creeping error components further away from content. If present data element sizes in video already do that, then it''s a solution in search of a problem. It needs to be demonstrated to be a problem in video as has been done in audio. The acid test being trying a larger data-element size and seeing an improvement.

Know this guy?

Or this one:

I can't folow your logic, Howard-Vigorita, but I surely can theirs. :)

More experiments reveal:
1. For my Google Pixel 5, Filmic Pro LOGv2 is the best option of the 5 available color profiles.
2. AVC (h.264) is the CODEC to use in Filmic Pro on this device, rather than HEVC (h.265). This MIGHT be because the processor chokes on 4K HEVC encoding during capture, resulting in artifacts in the images, or it might be for some other reason I cannot guess. But the artifacts are present during panning motion with HEVC, and NOT present at all during panning motion with AVC.
3. The two high-bitrate options in Filmic Pro are 75 Mbps and 120 Mbps. The 120 Mbps option actually does look better with AVC files recorded on my Pixel 5.
4. Only being able to record in 8-bit color DOES lead to some banding issues in bright skies during color grading. However, a viewer would have to be rather attentive to such things to notice.
5. A bigger issue with the limited dynamic range is overexposure/underexposure in scenes with sunlight and shadows. Balancing those considerations, I'd sacrifice (crush) some of the blacks, rather than blow out whites, because the latter is way more troublesome onscreen.
6. To get no overexposure, yet maintain "shutter speed" of 1/48 sec as I intend to maintain for a generally "film-like" look, I must use a neutral density filter. It happens that my current options for ND filters are too light to deal with truly bright days, so I have ordered ND filters that will give that additional capability as well.
7. It actually IS possible to get film-like imagery via modern smartphones. Steven Soderbergh proved this with his theatrical (and later UltraHD 4K BluRay) release of "Unsane." He shot that on iPhones. That was part of what motivated me to try to rely on my Pixel 5 for my upcoming short movie project, and to conduct these ongoing experiments.

I'm not sure how well it will show up here, but a sky example in S-log 2 (some banding/posterization in the clouds)

Somewhat ameliorated in 32-bit mode:

Seems pretty clear to me the gradient in the sky is smoother in #2. It's subtle in this example, but I don't know why anyone would look at those two images and pick #1 ... unless you want the shorter render time. Is there a case for "I want more visible banding in my skies" ?

Seems pretty clear to me the gradient in the sky is smoother in #2. It's subtle in this example, but I don't know why anyone would look at those two images and pick #1 ... unless you want the shorter render time. Is there a case for "I want more visible banding in my skies" ?

Ha, good point. It's more noticeable in motion as the line of banding shimmers a bit.

@IAM4UK Maybe start a new thread with your phone experiments as it's not totally related to the original topic here and you might get more people sharing experience with smartphone based filmmaking if the thread had a new title. You can shoot anything on a phone but bigger productions are going to use rigging and lighting, etc. that compensates for the device's weaknesses.

What you're describing here holds true for normal cameras as well (need an ND, have to take care with exposure and avoid overexposure, 8-bit color invites banding). I look forward to seeing what you come up with!

I understand, @RogerS​​​​​​

My posts here are really about "why would anyone shoot in LOG in 8-bit?" But I see your point. Thanks.

A 1.0 Gamma line in an 8 bit container can pack a full 10 bits of data; such is the scheme used by Protune.

Even tho I've been editing in vegas for years, and I did try to read & understand the 8/32 bit thingy but I still dont fully understand lol.

One of the main difference is integer math versus floating point math. The 32 bit property of the float point mode in Vegas Pro probably is the most misinterpreted one. It's not like 8 bit, 12 bit 16 bit integer color bit. 32 bit is the processing precision of the float point math. A good point to start investigating.

Another main and basic difference is the fact that in float point math values aren't cut-off beyond it's low and high ends even when in the end the output will be limited. Output limit is the range between 0 and 1. But the processing math used until output can be all way below 0 and all way above 1.

But the processing math used until output can be all way below 0 and all way above 1...

... making plenty of room for temporal (frequency) noise and space junk to encroach where signal is not resident. That's why we don't put 8 bit 2.2 Gamma on that playing field.

Even tho I've been editing in vegas for years, and I did try to read & understand the 8/32 bit thingy but I still dont fully understand lol.

@alifftudm95 you needn't waste time for such conquettishness.

A traditional painting can be taken in this 2high8bit "depth" way.

Or this 2high32bit "floating" way.

Both are limited here:

Beyond it there's a so called ACESystem way.

That is so much easier to understand. Simple analogy! @Yelandkeil

"Or this 2high32bit "floating" way."

Though this is right the misinterpreted way.

32 bit floating point is NOT(!!!) just "2high32bit". It is a completely different base math.

😁😁 I say drive the airplane into the sky.

You correct Nope! It must be V1 and V2 and then take off!

Alone the title is a big misleading:

Vegas Video 32bit video levels vs 8bit video levels

I find it's much clearer dropping to mention the 32. It's 8 bit integer vs. floating point. It just isn't a trivial difference.

Even if it would be 8 bit floating point there'd be a huge difference to 8 bit integer.

But the processing math used until output can be all way below 0 and all way above 1...

... making plenty of room for temporal (frequency) noise and space junk to encroach where signal is not resident. That's why we don't put 8 bit 2.2 Gamma on that playing field.

Am I misunderstanding you? I believe every significant video editing suite *other* than Vegas uses 32-bit float for internal processing regardless of source content (ie, unlike in Vegas, users aren't given a choice of mode). Editing and/or rendering 8-bit video using higher-precision math for processing is I believe a well-established precedent.

"I believe every significant video editing suite *other* than Vegas uses 32-bit float for internal processing regardless of source content"

I doubt this is the case. I know some offer float point options (HitFilm Pro does, too, but its default is 8 bit integer) but some of them even claim to use float point processing from in to out but actually it isn't true. My simple test is to let such software import this EXR graphic file (unzip to get the EXR file) and let it lower the luminance level. Only if this recreates the text in the graphic it's true float point processing.

The link to EXR graphic file is not working.