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

Blooey

photon78s Thanks! That is interesting. What model display is this? What I see is that even the 8-bit level breaks down without Apple dithering. That surprises me if this is truly an 8-bit native panel.

And I think we can see from the no Apple dithering photograph that the banding does still have blending between divisions at the 8+ bit levels. This makes sense since the FRC of the LG display is likely taking over the dithering. To do this, it needs 9-bit or greater input signal. With an older/slower 8-bit cable, the banding should be sharp edged above 8-bits, and roughly match the 8-bit level in band count.

What you are seeing here is what I would expect on a built in display of a MacBook if the TCON was taking over dithering. But @DannyD2 shows the MacBook Air M2 15" does not show any evidence of the TCON dithering taking over for Apple dithering.

Another interesting note about your photos is how much higher quality the Apple dithering is than the LG TCON dithering, in terms of color. The edges are sharper above the native panel depth. So it makes good sense why Apple wants to pass their proprietary dithering to a display. And once they do, a dithering algorithm down the chain cannot touch Apple's signal. A dithered signal should simply pass through any further attempt at dithering down the chain, unchanged.

But I am still curious why your LG display sees improvement with dithering at the 8-bit level. This really indicates that the panel is only 6-bit. I'm not sure if 7-bit native panels exist, but that would fit what we are seeing more accurately.

photon78s

Blooey

Thanks for your analysis!

https://www.displayspecifications.com/en/model/a1652d68
https://www.displaydb.com/monitor/lg-27gp95r

If it is 6 or 7 bit then another instance of marketing lie (suppose to be 8 bit + FRC)

Blooey

photon78s I just realized it's perfectly reasonable that the 8-bit level can show inconsistent banding. Even on an 8-bit native display. Because I forgot about ColorSync. The image has been color corrected for that monitor, so the linear 8-bit values are being shifted into non-native, higher bit depth levels. This explains why dithering even improves the 8-bit level.

Aggressive color correction should cause the native bit-level to break down. Something like Apple Night Shift, Apple True Tone, or any other aggressive icc color profile can in this way activate dithering on the native bit depth. Very cool to see this effect in your photo.

DisplaysShouldNotBeTVs

Blooey Don't forget about the monitor's own color settings too, adjusting contrast, gamma, or RGB values in the monitor OSD will clamp the color range further will introduce more banding

(And if there is some monitor where doing that doesn't introduce banding, that might mean the monitor itself is adding additional spatial or temporal dithering to the signal whenever it's own color adjustments are used)

photon78s

Blooey

So for the user, what would you recommend for settings both for the monitor and in the OS? In the LG I have it set to default contrast and a "sRGB game mode" in which settings like gamma, color temp, and R/G/B are unavailable greyed out in the OSD. In the Mac OS, I have it set to sRGB IEC61966-2.1 for color profile. I don't use night shift and I don't have true tone available since this is a non-supported external monitor.

aiaf

async you're absolutely right. I really don't want to mess with the TCON just yet. My attempts to read from it have already failed from user space.

Instead, I'm going to re-visit my assumptions about _IOMobileFramebufferEnableDisableDithering and the following:

From IOKit _IOAVVideoInterfaceSetColorDitherRemoval
From SkyLight _WSWindowSetDitherDisabled
From CoreDisplay _CGXDisplayGetDither _CGXDisplaySetDither gDisplayDither
From IOSurface _kIOSurfaceDisplayDitherCbThresholds _kIOSurfaceDisplayDitherCrThresholds _kIOSurfaceDisplayDitherThresholds _kIOSurfaceDisplayDitherYThresholds

The thing that occurred to me is what if IOMobileFramebufferEnableDisableDithering (which calls IOMobileFramebufferAP::enable_disable_dithering) is not merely a setter for enableDither and actually does more than that, i.e. what if it configures the TCON too?

So I'm going to try to invoke these methods from a kext and see what happens.

async

aiaf

Sounds like a reasonable assumption worth pursuing. Not sure how easy it is to follow calls between the frameworks. Seems like it might be possible with Binary Ninja and the dyld plugin, and using the cross reference thing.

Not sure why part of my files are like this. Probably some config stuff. but _kern is probably kernel. Might even be possible to load the frameworks in some debug mode to stop on specific calls to specific parts.

DisplaysShouldNotBeTVs

I'm picking up an M2 Air pretty soon to try out, I will let y'all know how it works for me with Stillcolor running on Sonoma 🙂

I possibly might be able to try an M2 Pro (13", Touch Bar, standard LCD) later this week too

DisplaysShouldNotBeTVs

DisplaysShouldNotBeTVs @aiaf let me know if there's anything that would be useful for me to run (such as dumping data, etc.) while I have the M2 Air

There's also a chance I might be able to get 2 M2 Airs side-by-side to compare panel variations, backlight bleed, etc.

async

There is a KEXT for the TCON here as well, but it doesn't seem to contain a binary for some reaosn.

/System/Library/Extensions/AppleDPDisplayTCON.kext

DisplaysShouldNotBeTVs

async This is true for a lot of system kexts since from I think around Big Sur-Monterey, iirc they are loaded in dynamically or something along those lines now. Had the same issue trying to find what I think was the IOKit or CoreDisplay kext's binary on Monterey.

Blooey

DannyD2 Since your MacBook Air M2 15" seems to perform perfectly with Stillcolor, I wonder if you can try an experiment.

The test is at pixelinversion.com. This is a new test site with some well designed, and thorough test patterns for LCD Polarity Inversion. People can upvote whichever pattern reveals Polarity Inversion on their machine.

Currently, the 3rd example down flickers on my MacBook Pro M1 16". The image is called Layout: Checkerboard: 2 pixels by 2 pixels_ _Color combination: #009F00 and #000000. Unfortunately the order of images changes as people upvote the most reactive patterns. The flicker is easily visible with the naked eye with my display refreshing at 60 Hz or less. But a slow motion camera can help. I have confirmed this pattern is used by Apple under microscope. Disabling dithering has no effect on the flicker on my machine. This flicker should be Polarity Inversion. But I'm really wondering if it is also a noise component of the pattern Apple is using for FRC dithering.

If you get a chance with your machine, without Stillcolor, can you see flicker on any of these patterns? And if so, does Stillcolor disable, or lessen that flicker?

photon78s

Blooey

So pixelinversion.com. Just a quick glance tells me that Stillcolor seems to not have any significant effect on the pixelinversion.com tests. Many of the green quick tests on the left side pulsate. Very difficult to look at for those sensitive. However the results make sense since my refresh rate is so low (30hz).

Setup is the same LG and m2 mac mini.

async

DisplaysShouldNotBeTVs Tried to look up some of the stuff. There is an absolutely massive amount of tools and info about patching kexts and other hacks. A lot of in relation to the Hackintosh community. As well as semi related stuff mostly for jailbreaking iOS. Obviously some of it doesn't work anymore with Silicon.

https://github.com/hack-different/apple-knowledge

Blooey

photon78s Sorry, they aren't fun test images. But the test patterns expose the flicker that is always present on LCD panels, but has been hidden in a noise pattern. Whenever someone says they'd like all future displays to be LCD, they clearly are not aware of this trickery. These test images simply mask off the pixels that would normally act 180 degrees out of phase to seemingly canceling out the flicker. But the reality is, we can resolve a single pixel. So to the eye, we are given two flicker signals that need to be combined somewhere in our biology. They have passed the problem along to our biology, as is often the case.

photon78s

Blooey

No worries, I've spend a lot of time on pixel inversion and I somehow forget to test the mac mini setup with that website created by another forum member. To focused on dithering lol. The LG monitor with respect to inversion is easily the worst of my devices and much worse than the internal panel of the legion pro 7i and T480s. Fortunately, using a high bandwidth cable to enable 120fps refresh rate at UHD resolution improves flicker on most of the green areas.

I quoted EPFL (the Swiss research university) on pixel inversion here:
https://ledstrain.org/d/2589-products-to-try-or-avoid-pwm-flicker-and-temporal-dithering-testing/150

DisplaysShouldNotBeTVs

Got the M2 Air. Disable dithering definitely does way more on an Air than it does on an XDR mini-LED Pro.

Going to test a bunch of things before I make any conclusions, but can anyone else here with an M2 Air verify that this also occurs on their model?

I'm on Ventura 13.3 which is what this Air shipped with.

Turn on Stillcolor (check Disable Dithering)
Open https://lcdtech.info/en/tests/dynamic.range.banding.htm on Firefox (it needs to be Firefox because the site uses CSS gradients, which Chrome and Safari apply spatial dithering to but Firefox does not. My Firefox is at default settings)
Screen generally default settings, Color LCD profile, but change resolution to 1280x832 and True Tone off
Zoom into the green gradient with pinch-to-zoom so it fills the whole window
Slowly scroll left to right with the trackpad

Do you notice "blotches" of obviously different shades of green, within each band, that then also begin to move around in sync based on how fast you're scrolling on the trackpad?

Notice how the blotches are no longer visible if you re-enable dithering. (Assuming that the OS is trying to "hide" these blotches by using a bunch of temporally dithered colors to attempt to make the bands look "uniform")

This is not coming from Firefox itself, because if you zoom additionally with the Ctrl+Scroll accessibility shortcut, the location of these blotches remain constant.

I want to know if anyone else with an M2 Air notices this…

I can also notice these blotches on a solid color dark background too. (For example, the solid gray background in Dark Mode of an empty folder in Finder in icon view)

I was surprised to see this effect, because I was assuming any additional color calibration "that doesn't uniformly apply to the whole display" would be something I would only find on XDR mini-LED Pro models. Was not expecting to see this on a laptop that doesn't have any local dimming like the Air. @aiaf

Unlike a relatively similar effect I recently pointed out on a mini-LED Pro, this one is fully visible without having to dim with Software Brightness / squint to see it and such. This one is very obvious (yet only is noticeable when dithering is disabled with Stillcolor)

I wonder if this is connected to the "dirty screen effect" that some on Reddit, etc. have noticed with certain M2 Airs? Whites also seem more yellowish on this Air than I expected, even with Night Shift/True Tone off. I will test for backlight bleed soon.

Edit: Tested for backlight bleed, this M2 Air actually doesn't seem to have the "M2 Air backlight bleed issue" at all. Full brightness black background in dark room looks completely uniform except for maybeee a tiny barely brighter area at the bottom right. Not really any bleed on this laptop compared to some of the pics I've seen online of other M2 Airs.

Donux

DisplaysShouldNotBeTVs You have missed the most important measure - how do you feel using device 🙂 I personally feel like rotten potato after day or two.

DisplaysShouldNotBeTVs

Donux still evaluating but it's a lot better than 14" pro mini led of course. the air doesn't make me feel "seasick" like my pro mini led does

with Stillcolor, better than some intel macs that have temporal dithering too (i think i prefer it over 2015 15" pro AMD, 2018 air with macOS, 2020 intel 13" pro touch bar, since all of those have really heavy temporal dithering)

not sure if as good as my actual working laptops tho (2012 lenovo laptop, 2015 12" macbook, 2018 air but with windows installed and old drivers)

stillcolor actually makes the screen feel more still on the air (which it doesn't do on the pro mini led, so that's progress)

i also much prefer looking at the M2 Air compared to my iPhone SE 2, which is really reassuring because the SE 2 (on iOS 17) is a much worse example of a modern Apple LCD. the SE has way more glare and temporal dithering shimmer than the Air has even at default settings

Blooey

DisplaysShouldNotBeTVs It would be helpful to know if someone with an M2 MacBook Air can control any of the inversion test images at pixelinversion.com with Stillcolor. As in, do any of the test images flicker without Stillcolor, but flicker less with Stillcolor?

I’m trying to determine if Apple is combining their color dithering system with polarity inversion mitigation. Will make it easier to identify between the two under the microscope if we know.

The third test pattern down flickers on my MacBook Pro M1 16”.

Donux

DisplaysShouldNotBeTVs Do you set specific color profile, or you can actually handle Color LCD?

DisplaysShouldNotBeTVs

Blooey I'll try to test this later today 🙂

« Previous Page Next Page »