On macOS with a wide-gamut (Display P3) screen, colors specified via hex codes (e.g. #ff0000) in Anki’s UI render more saturated/intense than true sRGB. Instead of being correctly mapped down to sRGB red within the P3 gamut, the raw RGB values appear to be stretched out and interpreted as native P3 values.
Notice in the following screenshots, the hex color that Firefox renders is being shifted downwards back into the sRGB color-space correctly. In the “Digital Color Meter”, #ff0000 reads as 223,68,26
While the color in Anki is the maximum red of the color-space, rendering as a more vibrant red than intended. In the “Digital Color Meter”, #ff0000 reads as 255,0,0
Steps to reproduce
- On a Mac with a wide-gamut (Display P3) screen, most Macs since ~2016, install the minimal reproduction addon, which just draws a plain
#ff0000square viaQLabel { background-color: #ff0000 }. - Open the test window via Tools > sRGB Color Space Test.
- Compare the square against a known-good sRGB rendering of
#ff0000shown on the same screen at the same time, e.g. a plain#ff0000PNG opened in a browser.
Expected behavior
Both reds should look the same, since both are nominally sRGB #ff0000.
Actual behavior
The color rendered by Anki/Qt is noticeably more saturated/vivid than the reference rendering in Firefox, indicating the value is being interpreted in the display’s native (wider) gamut rather than being color-managed as sRGB.
Environment
- Anki version:
25.09.2 - Qt version:
6.9.1 - macOS version:
26.5.2 - Display:
Alienware aw3423dwf

