I disabled dithering on Apple silicon + Introducing Stillcolor macOS M1/M2/M3

DannyD2 Are you viewing the image in Preview? Preview uses its own non-moving spatial dithering which is why higher bit depths still seem to look slightly more precise.

You can verify this by zooming in with Ctrl-Scroll accessibility zoom. There will actually only be as many colors as the panel's real max bit depth, but there is a spatial dither pattern visible (and in this case, actually will even show in a screenshot!)

So if you're using Preview, the split bands are probably not additional panel FRC, you're just seeing the app's own spatial dithering.

languidicity No, the flicker happens on all colors, the camera (and I suspect my eyesight too) just doesn't pick up the flicker on certain shades as much.

However, if you turn your camera's exposure way down (so white looks like dark gray to the camera), you'll actually see the flicker on white in the recording too. The M2 Air flickers on all colors including white! I just choose the dark gray wallpaper because it makes it really obvious at first glance even to people who would easily miss it by not analyzing the camera footage closely enough.

There are also other displays where this is the case too. For example, when filming the OLED Apple Watch Series 7, it's easy to see the PWM on dark gray in the slow motion recording but harder to see it on whites. (even though it's still definitely flickering on whites)

DisplaysShouldNotBeTVs Before creating the PNG test image, I originally wrote the test image as a MetalKit shader. And, even there, the noise pattern you are seeing was present. This should mean no image viewer on MacOS can circumvent that noise pattern. Given Metal is extremely low level on the drawing pipeline. With that in mind, Preview.app performed the most accurately in terms of expectation with the test image.

The usual advice for test images is to view raw in Firefox. But I find Firefox is simply lopping off the 9-th bit and beyond, with or without Stillcolor.

The noise pattern is plainly visible, and can even be sampled using Pixie or the Digital Color Meter. But it seems the noise doesn’t boost the test image into as high a bit level as a good spatial dither should. As such, people are apparently seeing a breakdown of bit depth using Stillcolor, using the image, with Preview.app.

new-jdm I'm curious about this too. If so this could be the most safe hardware then. Mac mini sounds like it would be solid just dunno if there's anything else the OS is doing on a external monitor that could harm

jordan I know this is a super long thread… I took a screenshot of a response that answered my question.

Here it is, in a nutshell ( credit @DisplaysShouldNotBeTVs )

If you have a true 8bit external monitor that is flicker free (no FRC), then with Still color on, the display output is totally still.

"Stillcolor is what has made M1 Macs great machines for external monitors for the first time"

jordan Fair point, I was confused too. Here's another recent post to clarify it further: https://github.com/aiaf/Stillcolor/discussions/2#discussioncomment-8972484

Edit: in other words, dithering can be built into the external monitor also, along with PWM, so you have to have the right external monitor to completely solve the issue.

jordan a lot of people having issues were using 10bit (8+FRC) monitors (for example, monitors with any sort of HDR support) that might typically use 8bit by default when connected to a PC — but become forced to 10bit (thus activating the monitor's own FRC) when connected to a Mac.

In those cases with HDR monitors (HDR monitors should be avoided anyway) you need a really old low bandwidth cable to ensure 10bit is never activated.

But with a monitor that is simply true 8bit with no 10bit support at all, that you know works well with some good Windows device, Stillcolor should work perfectly.

DisplaysShouldNotBeTVs Thanks for the clarification. Appreciate your continued efforts in investigating this.