Confirmed to work on 14" M1 MBP + BetterDisplay implementation?

[waydabber]

Hi there,

just wanted to confirm that this works with the M1 MBP as well (tested on a 14" MBP with M1 Pro). Works well on a 16" M3 Max too.

I was trying to use various IOMobileFramebuffer stuff in the past (some working, some not), the only actual useful thing came out of it was inverting the screen and turning it to grayscale waydabber/BetterDisplay#2745

Is it ok with you if I add a toggle for temporal dithering in BetterDisplay for built-in screens using this method in the next app version?

https://github.com/waydabber/BetterDisplay/wiki/Eye-care:-prevent-PWM-and-or-temporal-dithering

Thank you!

(ps. an user pointed me to your project here: waydabber/BetterDisplay#1201)

[waydabber]

Oh ok, I am just reading the ledstrain.org discussion and see various M1 MBPs working have been confirmed already, so this is not news + I see the project is MIT licensed and the method itself quite generic so my question probably does not make much sense. :) Sorry.

Anyway, great finding, thanks for all you are doing! 👍

[aiaf]

It's been confirmed to work with various configurations, I've personally tested it on M2 and M3.

Absolutely go ahead, as you mentioned, the project is MIT licensed :)

I use BetterDisplay, and previously Monitor Control. It would be nice to have a dynamic per-display control over DCP dithering.

Funnily enough I was testing the BlendOutputCSCMethod property today and it inverted the colors on the screen.

Which property did you use to toggle grayscale? I can't see the options when I option+click Image Adjustments.

I'm now focusing my efforts on trying to disable TCON-controlled (reverse temporal) dithering (not 100% proven yet), and perhaps forcing a lower bit depth on the internal display, which is proving to be really challenging.

[waydabber]

Hi there,

yes, I added it on a per display basis. For external displays it does not do much it seems (does something as the screen gets marginarry darker interestingly, but gradients look the same on the displays I tested).

I use the IOMobileFramebufferSetColorRemapMode directly both to invert and toggle grayscale - this seems to work both for internal and external displays (however IOMobileFramebufferGetColorRemapMode strangle seems to work for built-in screens only).

Tried changing other stuffs directly under IOMobileFramebufferShim using IORegistryEntrySetCFProperty but so far I did not find much useful things (some changes had weird effects though), will test things further!

[waydabber]

Note: waydabber/BetterDisplay#2766

[aiaf]

Use the gradient image created by Blooey https://ledstrain.org/d/2686-i-disabled-dithering-on-apple-silicon-introducing-stillcolor-macos-m1m2m3/330 to measure your display's apparent bit depth. Lagom gradient only works reliably for up to 8bpc.

enableDither = No setting absolutely works for both built-in and external displays. In fact, it's equally important for both.

The tone shift you noted is evidence that dithering has been toggled.

However, for external displays, there are a couple of variables to note:

• Built-in FRC/temporal dithering on the external panel. If the panel receives a 10-bit signal and it's only capable of 8-bit+FRC, it will still dither in addition to the dithering applied by the DCP (this is where disabling DCP dither helps)
• Actual signal bit depth transmitted by your cable+port+resolution+refresh rate+bpc combo. I use an old High Speed with Ethernet HDMI cable on my M3 Max to force a 8bpc on my external monitor (which does 10-bits (8+FRC)). Forcing 8bpc this way stops the monitor from doing its own FRC. See https://ledstrain.org/d/2686-i-disabled-dithering-on-apple-silicon-introducing-stillcolor-macos-m1m2m3/308

[waydabber]

Ok, checked it on some more external displays. On at least one display I noticebly see a difference (banding appears) - so it might be connection dependent. There are others where I cannot see any banding appear however some shades of gray do shift.

But if for the external display a GPU-side temporal dithering would apply (as opposed to maybe spatial dithering which I seem to see on the external display where banding does not appear), that should look obvious on low refresh rates. For example if I switch the display to 24fps, GPU side temporal dithering would effectively create a 12Hz flicker + the entire mechanism should break down and look inconsistent on VRR. For the built-in display GPU temporal dithering does not seem to be affected by low refresh rates and ProMotion, but that could be explained by the fact that maybe there is a direct communication to the panel controller board.

But maybe I am not sensitive enough (I hate flicker generally and easily detect it on my iPhone screen for example so I don't use dimming beyond a certain point, use instead a color filter at night), but maybe I can't sense a gray-to-gray flicker even at 12Hz?

[waydabber]

(Note: my understanding is that with GPU-side temporal dithering the GPU would send odd and even frames with slightly different gray values, alternating them to create a perceived middle-ground gray - but this technique, especially at low refresh rates could only produce maybe one interim gray level reliably and cannot be as potent as display-side temporal dithering. But I can be mistaken of course.).

[waydabber]

The BlendOutputCSCMethod you mentioned can not only toggle inverted but grayscale and inverted grayscale too. Various other colors/combinations are possible as well (interestingly sometimes you need to write it twice to take effect and most of the time you need to create a dirty area - some kind of activity - on screen to initiate a redraw). But this seems to work for the built-in screen only for some reason (although the property is present for external displays as well).

[aiaf]

But this seems to work for the built-in screen only for some reason (although the property is present for external displays as well).

My theory is that if a property has an effect only on the built-in panel then it's a property that pertains to the built-in TCON's behavior. For example, behavior related to the Color Engine, backlight, brightness compensation, temperature compensation, etc.

or example if I switch the display to 24fps, GPU side temporal dithering would effectively create a 12Hz flicker + the entire mechanism should break down and look inconsistent on VRR.

I've captured 24fps HDMI output with enableDither = Yes. It absolutely does change the image frame to frame. The flicker is readily noticeable on gradients and darker colors. DCP temporal dithering matches the selected output refresh rate from my testing. Also it's not necessarily 2 frames to approximate 1 intermediate color. Could be 3 or possibly more. There's also the idea of refresh-rate dependent temporal dithering, which external display may, in theory, apply. But this of course is a feature that may or may not be present on the controller.

I've also tested Stillcolor on a 6-bit+FRC monitor (so have a couple users). The fact that image was double temporally dithered creates visible artifacts, and disabling dithering outputs non-temporally dithered frames that the display can now comfortably dither from 8bpc.

I believe that the tone shifts you notice when you toggle dithering is the algorithm at work trying to approximate an intermediate color.

In the end, whatever the connection bit depth is, and whatever the advertised bit depth of the panel is, a silicon Mac will always output temporally dithered frames by default until you disable it with enableDither = No

[waydabber]

All right, thanks for these + the tests you did, that settles it then!

[europaJDM]

I am testing it on the M1 Pro with an external display. I see the change in gradient banding on the external display (with the setting off vs on).

One question I had is does PWM behavior transfer to the external display? I never had issues with this display before. I can't really tell since my eyes are tired.

[aiaf]

PWM is baked into the display and is decided by the manufacturer- the Mac has no say in it. Check your if your display has flicker/PWM on https://rtings.com or https://displayspecifications.com or you can simply use your phone's video camera at a very high shutter speed and play around with the screen's brightness. If it's your first day with Stillcolor give your eyes some time to relax, could take a day, or two or more until your eyes are no longe strained. Additionally your display could have its own temporal
dithering depending on its advertised color bit depth and whether or not it used FRC to achieve those bit depths

Check this post https://ledstrain.org/d/2686-i-disabled-dithering-on-apple-silicon-introducing-stillcolor-macos-m1m2m3/308

[europaJDM]

Thank you!

[europaJDM]

This is the spec for my display. No FRC and the manual says it's flicker-free (I'm not sure where it's mentioned on this spec sheet though). https://www.displayspecifications.com/en/model/1232168e

Edit: it says flickr-free under "features" but no mention of PWM

[aiaf]

This is good news! If your display is truly 8 bits (sometimes they advertise 8 bits when it's really 6 bits+FRC under the hood), then you should have 0 temporal dithering with Stillcolor. Contact ViewSonic to verify the flicker-free and 8-bit color depth claims

[europaJDM]

Another quick question, why do I only have 3 entries like this vs 5 in your example when running the command ioreg -lw0 | grep -i enableDither?

| |   |   |   "enableDither" = No
| |   |   |   "enableDither" = No
| |   |   |   "enableDither" = No

[aiaf]

Possibly related to the maximum number of displays supported by your Mac.

[europaJDM]

This is good news! If your display is truly 8 bits (sometimes they advertise 8 bits when it's really 6 bits+FRC under the hood), then you should have 0 temporal dithering with Stillcolor. Contact ViewSonic to verify the flicker-free and 8-bit color depth claims

Thanks! I am inclined to believe the "true 8 bit" statement, because they advertise other models as (6 bit + FRC), and the third party spec site makes the same distinction for this brand. (I checked both the official spec site/manual and the third party site)