@ALO No, it wouldn't make a difference.

@ALO When I render Nvidia hevc, I always go with 10bit when the source footage is 10bit hevc. If the source footage is 8bit, I would render 8bit if all I was doing was trimming. But if there's fx processing that adds detail or content, I'd go 10bit.

Note that the 8bit project settings refers to back-end data-storage and/or math processing precision, not a single stream pipe-width that puts a cap on render quality... because projects with fx constitute multiple parallel processing streams and measurements I've done suggest they must be getting delivered in parallel to the cpu or gpu which performs both the mux and render. However, I have measured a pipe-width constraint when Vegas feeds input to 3rd party render plugins, suggesting Vegas does a pre-mux and funnels it into a limited bandwidth single pipe... but that only seems to affect 4k projects because the 3rd-party pipe was probably designed back in the hd days and never upscaled for 4k. I've noticed that measured output quality decreases only slightly comparing 8bit 4k projects with 10-bit hevc media when rendered by internal Vegas presets, compared to 32bit projects, which is easily offset by a minimal increase in render bit-rate/file-size.

Here's something interesting:

Claude says yes, it can make sense to render 8-bit projects with 10-bits-per-pixel (instead of 8) when encoding to HEVC because HEVC compression algorithms are optimized for 10-bit color depth, and so tend to give better visual results ie fewer compression artifacts.

In any case at the same bitrate I assume you end up with the same file size, so I guess if it doesn't cause problems with render times or crashes why not?

Who is Claude and is Claude familiar with VEGAS?

Try using a tool to measure the results both ways and see if it's any different.

Ultimately I don't now if the metrics catch artifacts so I think the point is to avoid banding, posterization and other color artifacts. Try comparing 8-bit renders to 8-bit and 10-bit against project 32-bit mode as well, especially if you are doing log transforms as the 32-bit pipeline there seems to make a significant difference. Visually does the final render look acceptable?

https://www.anthropic.com/

Does this chatbot cite a source? What if you ask about quality impacts of maintaining the same bitrate while increasing the bit depth from 8 to10 bits precision (more tonal values with fewer bits to cover each).

Since I'm not seeing data here let me start with 32-bit vs 8-bit project settings with a conversion LUT for Slog 3 added via CGP at the media level.

I picked media that had banding issues before.
Then I did renders to ProRes XQ in 32-bit full, 8-bit full and then MagixHEVC with 32-bit full and 8-bit full projects.

The 32-bit variants are somewhat higher performing than the 8-bit project ones but whether the difference is meaningful I'm not sure. When I have more time I'll try other test files and also with a visual check (will use images with smooth gradients to judge banding).

And then again with 2 more Mainconcept MagixHEVC renders at the same bitrate but this time with 10-bit checked in the render dialog.

So the most significant quality difference in this test appears to be the render 8 vs 10-bit, not the project bit depth setting.

How the render quality metrics compare to real world visual quality is something I'll look at later and am curious what others see as well.

I had a chance to review the renders and there is a banding issue with the 8-bit project ones, even with ProRes XQ (which I believe is 12-bit). The 10-bit HEVC Mainconcept one has banding.

So while the scores may look good the files are not acceptable in my opinion.

This is with Slog 3 and a conversion LUT using 32-bit ProRes XQ as the reference. A straight transcode may yield different results but I think the normal use case requiring > 8 bits of precision involves log conversions.

Do we get a 10-bits-per-pixel option in AV1 in the Vegas beta? I don't see that in the current build of VP22.

Here's more (from ChatGPT) on the subject:

https://chatgpt.com/share/67f13b63-b86c-8002-a1e9-bf1ec14f2785

AV1 encoding is broken in my testing, there are posts in the forum about it.

oh. thanks by the way for the Shutter Encoder recommendation (on an unrelated thread)--it's a great tool and clearly better for AV1 encodes!

VEGAS AV1 would be fine in regards to encode quality except for frequent glitched frames in my testing (which doesn't show up in render metrics). There are also decoding issues with AV1 though only when the CPU decoder is used. Hopefully development will continue and these issues will be sorted out.

The ChatGPT "conversation" is interesting though in some places inconsistent and in others counterintuitive. I don't know enough to say if it's wrong but we could use an expert to validate or dispute the findings. Why would 16.7 million possible colors/shades require more data to represent than 1 billion? Are the answers about 10-bit delivery files relevant for both HDR and SDR workflows? Is it conflating precision for internal calculations with that of the encoded files?

The answers are delivered with great confidence but as these tools are not capable of cognition I wonder if they make sense. I'd request sources and interrogate the sources to see what they say, whether if it's applicable to the situation in question and if these tools accurately have represented the sources or not.