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

Blooey @aiaf FYI, there actually is some evidence that Apple uses "one additional bit of depth" (i.e. 11-bit) as you are describing, at least on some Intel Macs:

https://github.com/Psychtoolbox-3/Psychtoolbox-3/blob/a59a448bec34f1909db77092adaeda79bb8a98b8/Psychtoolbox/PsychGLImageProcessing/PsychImaging.m#L716

They refer to "spatial dithering", but I'm not sure is entirely accurate that it's just spatial — I suspect it has a temporal element too

waydabber the LEDs in those zones will work at full capacity - to compensate that the surrounding areas will have "darker" pixels produced in the crystal layer

Do you believe there could be a way to disable local dimming entirely on the mini-LED Mac internal displays — to set all LEDs to the same backlight level and represent color brightness purely through the crystal layer, in order to simulate a traditional LCD?

(I don't care about black levels or HDR, and honestly prefer the feel of a display with a uniform light source + no blooming — I just want a comfortable display to write documents and code on)

BTW, I messed around with the property BLMStandbyEnable in the IO registry and it's able to get the mini-LED layer to pause, for example leave a spot of dark LEDs where a dark window used to be until standby is set to disabled again. But not sure how to control backlight modulation more precisely than this.

In addition, I'd highly suggest an option to disable the uniformity2D IO registry property for XDR internal displays in your software (can be done in the same way as setting enableDither to false) — this fixes the "vignette/slight fade to black" effect at the edges of the display I've always noticed and have found annoying on mini-LED Macs, the display looks so much cleaner to me with it off.

DisplaysShouldNotBeTVs Very interesting. I had 5-6 mini-led monitors for test, and all of them had an option to disable local dimming and they were acting like a regular dc-dimming backlight without PWM or any other flickering.

DisplaysShouldNotBeTVs I added a command line options to alter any numeric and bool framebuffer propertiy just yesterday to simplify playing with these (on Apple Silicon).

This build has this: https://github.com/waydabber/BetterDisplay/releases/download/v2.0.0-pre-release/BetterDisplay-v2.3.0-b27732-pre.zip

For example to get/set brightness correction for the built-in display (default value is 0x10000 or 65536):

betterdisplaycli get -namelike=built -framebufferNumericProperty -propertyName=brightnessCorrection

betterdisplaycli set -namelike=built -framebufferNumericProperty=0x5000 -propertyName=brightnessCorrection

Here is how to change (set, get, toggle) uniformity2D you mentioned:

betterdisplaycli set -namelike=built -framebufferBoolProperty=off -propertyName=uniformity2D

betterdisplaycli get -namelike=built -framebufferBoolProperty -propertyName=uniformity2D

betterdisplaycli toggle -namelike=built -framebufferBoolProperty -propertyName=uniformity2D

You can get betterdisplaycli here: https://github.com/waydabber/betterdisplaycli for these command line commands to work with the above linked build.

waydabber Woah. Love having you around here

There are some hierarchical ones, but I'm not sure if they are used as toggles or just output. Can they be changed as well? They're easy to browse thru with this command.

ioreg -l -d0 -w0 -r -c AppleCLCD2 -a \ | sed -e '/^\t*<data>/,/^\t*<\/data>/ { /^\(\t*\)<data>\(.*\)/ { s//\1<string>data:\2/; h; d; }; /^\t*<\/data>\(.*\)/! { s/^\t\(.*\)/\1/; H; d; }; /^\t*<\/data>\(.*\)/ { s//\1:data<\/string>/; H; g; s/\n//g; }; }' \ | plutil -convert json -r - -o -

Also I've had cases where after changing things the screen goes blank after closing the lid or after changing color profile. I guess you know way more about this, but for some maybe some sort of reload command needs to be sent for it to take effect?

I fiddled around with a way to monitor ioreg changes as they happen. It's earlier in this thread. Lacked some filtering and better way to grep the json structures. Feel free to copy of it is useful for your work.

async Of course, any item in the I/O Registry can be read or written (if writable) programmatically. I just added these as convenience to help tinkering (since the app already reads and writes a lot of i/o registry data and identifies the correct framebuffer path for a display anyway as it is required for many of the core app features, it was just a few line of codes to give some CLI access really). But my goal was not to create a generic I/O registry manipulator app. I am sure there are some already out there but if not I can put together a simple command line tool sometime for this purpose.

Just as a general note: some framebuffer related changes need to be applied twice (for some reason) and some won't take effect until there is no screen activity (so if your MBP's screen is a secondary display with static content, you might not see anything happen until you do something on the screen). Most seem to do nothing or something so subtle that it is not easy to understand the effect (like I filed uniformity2D under things doing nothing until @DisplaysShouldNotBeTVs noted what it does - and then upon super closely looking at the edges of the screen I indeed noticed the effect). You can certainly break things with tinkering, either get blank screens or outright kernel panics (I was able to achieve both).

I was able to find a somewhat roundabout way to turn off XDR built-in screen local dimming and get a traditional-looking uniform backlighting (works properly at standard 500 nits - or 600 nits for M3). However the hack can cause crashes/freezes if not turned off properly prior to sleep, lid close, preset change and some other circumstances. So I don't think it is viable to add to the app (or maybe as a hidden option with warnings).

Here is a full 16-bit gradient png. Good to add to the collection of test patterns.

waydabber what's the method? i want to try this despite the instability because i really want to know what the screen feels like to my eyes without local dimming

for my personal workflow I also don't usually put the Mac into sleep mode either, so that doesn't matter to me (since i keep the Mac on a lot of the time when i'm not using it, in order to keep some development web servers running)

@async @DisplaysShouldNotBeTVs - Sure, you can experiment with it. Here is a build that has this:

https://github.com/waydabber/BetterDisplay/releases/download/v2.0.0-pre-release/BetterDisplay-v2.3.0-b27760-pre.zip

If you hold SHIFT+OPTION while opening Image Adjustments, you should see this experimental option appear:

The way it works is hopelessly complicated as multiple things must be done to toggle it on/off. The feature locks the backlight at full SDR peak brightness for the entire array while enabling software brightness control. However after this is toggled, you can expect your MacBook to freeze (requiring a manual restart) or kernel panic instantly or on sleep, lid close, preset change, mode change etc - at least this happens on my M3 16" MBP Max. Tested on my secondary M1 14" MBP Pro as well - it froze during turning local dimming back on in a way that it could not boot to macOS anymore (note: recovery environment works and can mount the Data partition of my system drive so will try to figure out what to do to resurrect it without a complete reinstall - luckily I use that Mac for testing only…). You were warned! Happy testing!

UPDATE: Since @DisplaysShouldNotBeTVs asked for the method - the app creates and activates a new XDR profile with locked brightness at the reported max SDR nits for the screen (500 or 600) with disabled EDR (that interferes with the process and creates artifacts), uniformizes the backlight LED array at full SDR brightness level (this should be PWM free for sure + above this things do not work well for various reasons), then locks the current backlight configuration using BLMStandbyEnable.

There might be a better way than this of course.

DisplaysShouldNotBeTVs Not sure what's wrong with it. Sometimes similar things happened of course while experimenting - usually booting to the Recovery environment, getting rid of the windowserver configuration file under /Library/Preferences, starting in safe mode etc, forcing a boot in clamshell mode with external displays connected, etc solved the issue (at least to gain back control). None of these seem to work and the Mac is fully dead after a brief loading episode, even keyboard backlight is gone. Did not have this issue on my M3 MBP though. And until turning local-dimming back on, things did work on the M1 MBP as well. Anyway, will figure something out, no worries. I'll wipe the whole thing and reinstall I guess.

UPDATE: I had to decrypt the volume in Recovery Terminal to bypass a (for some reason?) broken filevault login apparently, this fixed things (+clearing nvram, deleting windowserver config). All good now.

I tried again, now it did not freeze like last time on the M1 MBP so it might have been a one off thing. But the entire process is somewhat unstable.