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

async

aiaf Awesome. I actually saw a reference to some cryptography function in one of the TCON ones. Still not certain things have to be as complex as editing the memory directly or messing with the firmware. Could be possible to just load one of the libs and start toggling options.

When unpacking remember that some stuff is only available in the x86 cache, so both needs to be unpacked.

I found Binary Ninja to be the best for browsing around.

If anyone else wants to dig around this is roughly what I did:

brew install keith/formulae/dyld-shared-cache-extractor
dyld-shared-cache-extractor \
/System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/dyld_shared_cache_arm64e \
$HOME/Projects/dyld-cache-arm64e

dyld-shared-cache-extractor/System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/dyld_shared_cache_x86_64 \
$HOME/Projects/dyld-cache-x86_64

cd $HOME/Projects/

grep --recursive -i uniformity2D (find all libraries with some refernce to a certain string)

There is also another tool to see what a framework depends on that can be useful

brew install dylibtree
dylibtree --depth 3 \
--shared-cache-path /System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/dyld_shared_cache_arm64e \
$HOME/Projects/dyld-cache-arm64e/System/Library/PrivateFrameworks/AppleDisplayTCONControl.framework/Versions/A/AppleDisplayTCONControl

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.

JTL

photon78s I also am using the blackmagic ultrastudio recorder 3g capture device to test for dithering on hdmi output. The problem I have is I am recording no dithering at all on my should-be-dithering windows 11 pc. In my ffmpeg diff videos, moving the mouse will create the dithering effect but I should be seeing much more. I did try with an elgato capture card and that was capturing dithering. Just wondering what I am doing wrong with the blackmagic device.

I don't have my capture setup nor a target device handy, but I was able to record a lack of dithering on a dithering setup by some degradation of color depth by the capturing PC, and nothing the output device was doing (unless there was some sort of bidirectional signaling outside of EDID going on). Sorry for not having more details.

photon78s

JTL

Also using the same blackmagic device (bmd) and its drivers? What is your capturing device? In fact, my original thinking before Stillcolor was developed was to use a cheap hdmi to usb capture device (which I had purchased originally for my DSLR to use as webcam) with visible lossy compression and low color depth to view problematic windows PCs with dithering through OBS on a "safe" device which now is a mac.

While I was recording on the capturing PC, I toggled Stillcolor off and then on on the mac mini. In the ffmpeg diff video, you can see the dithering appear then disappear in real time so that is confirmation of it working.

Blooey

DannyD2 Very cool. That is what I was expecting to see with the test image.

dithering More bands above 8-bit. With some higher levels losing band edge sharpness if not enough frames are used in the dither.

no dithering No additional bands above 8-bit. And sharp edged bands accross the entire test image.

Your photos seem to meet that description. But on my M1 MacBook Pro 16", nothing significant changes with Stillcolor. It behaves more as if I have a native 10-bit panel. I see crisp edged, doubling bands all the way up to 10-bit, with and without Stillcolor. Above 10-bit the bands become muddy, and not clearly defined, with and without Stillcolor.

photon78s

Blooey

Here is another data point for the 8 bit + FRC LG monitor connected to mac mini m2.
With no dithering (Stillcolor enabled) I see same or similar banding above 8-bit. With dithering, I see more/finer banding.

Dithering https://ibb.co/qBgvfDm

no Dithering https://ibb.co/BwKtQ16

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.

Rowe

aiaf 'This trick should work with an inconspicuous menu bar item that animates at 120fps+' Yes, that would be a good improvement

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.

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

« Previous Page Next Page »