Description of the issue: 30-bit color broken on September 4th update.
How can this issue be reproduced?
-
Setup a display with at least 10bpc and enable it.
-
Turn on Windows 11’s “ACM” (this enables 16-bit float, and thus DWM can enter 30-bit color depth.
-
Set brave in brave://flags to set the color profile to “scRGB” (required for wide gamut to work correctly in ACM, and enable 30-bit color depths)
Expected result: 30-bit color to work everywhere, not broken on some sites with visible banding.
Brave Version( check About Brave): Brave 1.82.161
Additional Information: Currently the only location I’m noticing 30-bit color broken is YouTube’s “Ambient Mode”, but only on videos with bt.709 color. It still works correctly if the video is bt.2020, but the video itself should have no effect on Ambient Mode like it previously did.
Since I cannot screenshot this since screenshots are 24-bits, I can at least take a photo from the previous Brave version, and the current Brave version, on the same YouTube video, and at least the noise from the camera acts as a form of dithering so hopefully you can see the visual banding now present in the latest version on a fully 30-bit system.
OLD Brave (No visible banding while in scRGB with ACM enabled on a 10bpc monitor):
Latest version of Brave with visible banding under the same conditions:
If I write a script to pull “document.getElementById(‘colorDepth’).textContent = screen.colorDepth” it DOES still properly report 30, and some websites like PalmDB (a Palm Pilot app database) which has a translucent blurred top part of the page, IS rendering with 30-bit precision. So whatever this bug is, it’s happening seemingly only to YouTube right now.
Up to date Edge (version 139.0.3405.125) is not having this issue, and still working like old Brave did.
I looked at the changelog, and honestly don’t see anything that should have caused this, so I have no idea what was done that borked this. WebGPU features reported however have NOT changed either, just Brave itself.
(Also for feedback, the default color space with ACM enabled should be scRGB, otherwise Brave will lose all wide gamut capability under ACM’s control (ProPhoto or P3 tagged photos look like sRGB). Most photo editing apps know this and will use scRGB now with ACM. Please ensure this is being handled correctly because it seems many misunderstand what ACM does under the hood, and what’s really going on with your framebuffer color depth wise, as the pixel format changes from RGBA 8888 to RGBA 1010102 as output to the screen, but DWM internally is doing RGBA16161616.)
UPDATE 9/5/2025 7:42p: Apparently this only happens if the video playing on YouTube has a bt709 color space. Videos with a bt2020 color space still have smooth 30-bit gradients. Not sure why that is, it’s never been an issue in the past.
UPDATE 9/5/2025 9:25p: It does appear something was changed, and maybe it’s Chromium side, and it does indeed have to do with color support. It looks like support for “Display P3 with cICP chunk - PNG” is properly functional now. Maybe related? Maybe not, but this might be upstream and not Brave specific, therefore I need to bark up another tree. Old Brave didn’t support cICP chunks. Current Edge still doesn’t support cICP chunks, but is working with YouTube’s ambient mode in 30-bit. I bet when Edge supports cICP chunks, it’ll then have broke YouTube 30-bit ambient mode as well.
