aiaf i'm going to try to guess a few…

BypassPCC2DLed (and DisablePCC2DBrc) could this possibly be able to disable the "2D" array of mini-LEDs and force a uniform backlight?

IOMFBBrightnessCompensationEnable given that this is false on external but true on internal, this might be related to the uneven colors i was mentioning? i bet uniformity2D and NormalModeEnable are related too because the laptop seems like it's trying to "normalize" the brightness over areas of the display (and failing at that LOL)?

enableDarkEnhancer i bet this is dithering related for sure

enableLinearToPanel if this is what i think it is, it might be "converting linear (exact) colors into whatever the panel color space is". if so, it would be good to disable, because that might reduce color management / help prevent colors from being modified

interesting i tried to edit your code to attempt to change these and i get "IOKit not permitted" on all of them except for enableDither which goes through fine, any idea why that might be the case and how to possibly modify these other properties?

  • aiaf replied to this.

    aiaf The flicker frequency matches the refresh rate. I am recording the flicker at 240 FPS.

    I can't yet say for certain that FRC color dithering is the source of flicker, but I can rule out PWM, since it tracks with refresh rate. I don't know the exact behaviour of LCD inversion, but at full white, there is no visible flicker. I would think full white would also have some flicker from inversion bias, but I am not sure if that artifact is expected to only occur on lower voltages. There is also what appears to be a slight randomness to the flicker intensity per sub-pixel. Which resembles FRC dithering. The problem is I have heard that Apple might intentionally source slower response time panels, to allow for better blending of temporal dithering signals. This latency makes it difficult to make sense of the flicker signal. One other factor is I don't really see any change in the noise signal for the better under the microscope when enabling Stillcolor. If there is a layering of temporal noise happening, I would maybe expect to see more flicker when disabled. It still makes more sense to me that there is a static spatial dithering layer being removed by the command, and only on the built-in display. And we know from IOGraphicsTypes.h that there is a spatial dithering option.

    I also tested an external OLED display. The Gigabyte AORUS FO48U. This display is OLED, and apparently has 10 bit native color. It also apparently has no built in FRC color dithering. But it also shows FRC color dithering under the microscope. I think I trust this is FRC dithering on that display, since the flicker frequency varies with refresh rate, OLED's do not have LCD inversion, and the sub-pixels light out of order at times. There is no muddiness to the effect, since the response time of the OLED is near instant.

    What is interesting is that when enabling Stillcolor, I see the difference in the Lagom Test Gradient on the built-in LCD, but not on the external OLED display. Again, my guess is the spatial dithering layer is removed by the command, but was only applied to built-in displays. But right now, it's all more of a guess.

      Blooey

      I am testing the M2 mini with a 144 Hz IPS LG display. When I look at the Lagom Test Gradient on that monitor and toggling Stillcolor, I only notice a slight brightness shift but the banding looks the same to my naked eye. I went into terminal and verified that dithering is off.

      @photon78s

      I have the same setup as you, with no banding using USB-C to DisplayPort, only a minor shift in brightness. However, when using HDMI to HDMI, I experience banding with no relief. The issue lies in how macOS renders the UI, especially when I am on the scaling 'retina' mode. It exacerbates the 'side effects' for me. I strongly believe that retina mode creates a pattern glare that negatively affects my eyes and head. A quote from Reddit perfectly describes my situation: "For example, a 5K Mac screen outputs 5120×2880 and then divides it by 2 to display a 2560x1440 "retina" resolution.
      This process (dividing) can be seizure inducing for me, as it creates a pattern glare where everything appears to be moving and vibrating. Unlike Windows, which does not use this type of rendering and simply zooms in without dividing the resolution."

        anon123

        That's interesting. I'm new to modern Macs as you can see (my last Mac that I truly used for significant period of time was the CRT iMac lol).

        At this point I am a bit tired of chasing new monitors and hardware swaps. Focusing now on how to build up defenses (breaks, eye washes with water, acupresssure, etc. ) and using the screens less.

          anon123 when macOS divides by exactly 2 it works by just doing a 200% zoom, the same as Windows, so the vibrating feeling they had is probably related to usual Mac temporal dithering. Sounds just like the dithering symptoms I get on iPhone SE 2, most Macs, AMD video cards etc.

          however, yes there will be additional distortion and moire patterns on not-exactly-2 scale factors (this is where it does differ from Windows). But exactly 2 should be fine, so they're definitely just feeling the symptoms of dithering

            photon78s I'm not sure what to make of these videos. If your Windows setup is outputting an 8-bit signal (with dithering disabled) over to an FRC display and you're measuring a flicker, then that says more about the display than your particular OS+GPU config.

            We've already seen that Stillcolor disables Apple GPU/DCP dithering in the Mira e-ink monitor (USB-C to ?), Blackmagicdesign capture card (HDMI to HDMI 1080p60), and via user testimony.

            If you can take microscope footage on a monitor that's proven to be FRC-free at a particular bit depth, showing no flicker, then take footage using a OS+GPU combo on the same display that demonstrates flicker, then we can start diagnosing the software.

            Edit: does your phone have a "Pro Video" mode at at 120fps FHD? If you can set your output's refresh rate to the minimum possible (30fps?) and and take scope footage with 120fps, it will probably be easier to analyze.

              aiaf

              Thanks for the suggestions. The pro video mode is not very useful in my case. Will try something else.

              aiaf Please how should I send it to you? I exported it into *.txt file, but its quite a lot of text to copy it here.

                martin I would also be interested in it for research purposes.

                https://gist.github.com could work if there's no sensitive information in there.

                Forum has a PM function under the user profile.

                  JTL I think PM permissions are disabled by default. I had to manually ask admin to give me permissions for it.

                  • JTL replied to this.

                    aiaf DISABLING "uniformity2D" WORKS

                    IT FIXES THE "weird fading to black bands around the edges" while still keeping bands on shadows (i.e. dithering is disabled TOO! this is in addition to it)

                    there is still some blotches of solid white backgrounds where changing gamma affects them differently than other areas of the same background, so that may be related to a different property, but uniformity2D is behind that weird edge effect!!!

                    the effects of disabling uniformity2D are sooooo obvious even when dithering is still enabled (but i can still notice an additional change when disabling/enabling dithering too)

                    this fixes something that's annoyed me about this screen for years where i always KNEW the edges were fading to dark instead of displaying a solid background

                    once you disable uniformity2D "you'll never unsee it" when it's on like it is by default! it's such a dumb screen effect because the screen honestly looks more color accurate when it's off!

                    in summary:

                    disabling and enabling dithering affects whether the fading to black at the edges (most visible on a white background) is banded or "smooth"

                    disabling uniformity2D GETS RID of the fade to black entirely

                    fyi:

                    a good way to test the effects of disabling and enabling dithering is looking at the transparent dark sidebar of Xcode against a wallpaper of a partly cloudy sky. you can easily see banding appearing and disappearing here

                      So after some more experimentation with the microscope, it turns out the OLED display I was testing Stillcolor with seems to have built-in FRC dithering. In fact, it is quite aggressive. The marketing and independent specification for the display make no mention of this. It occurred to me that I might be able to confirm that there is no temporal dithering built into the display by looking at the onscreen controls under the microscope. Sure enough, the middle grey design elements in the onscreen display settings have temporal flicker.

                      With that, I am more confident that Stillcolor is working on the M1 MacBook Pro 16". And that the temporal dithering visible under microscope might be LCD inversion with a sub-pixel implementation. But it amazes me how bad the LCD inversion is. The built-in MacBook display performs well on the many inversion tests available, but under the microscope it is pretty much terrible. If this flicker is LCD inversion, then I could see LCD inversion being a main cause of people's discomfort with these machines. I didn't know it was this bad, and had always thought this sub-pixel independent flicker under microscope on darker colors was temporal dithering.

                      Stillcolor does for sure increase the banding on the Lagom gradient test. So there is evidence it is working. It would be awesome to see time blend output from an M1 MacBook Pro 16" to a capture card, but for now I'll just have to assume Stillcolor is working. Because of the very similar noise of inversion, it is so far not obvious that anything temporal has been disabled by Stillcolor, through the microscope.

                      In the meantime, I am going to try to come up with an experiment to distinguish between LCD inversion and temporal dithering (sub-pixel type) to put this confusion completely to rest.

                        Blooey i still think the XDR Pros are dithering with an additional 10-bit to 8-bit FRC step like external monitors do (because macOS output is 10-bit but I doubt the internal panel is "true" 10-bit), and this would best be solved if Stillcolor gains the ability to truly force color depth

                        can you try measuring the display with both Stillcolor enabled and BetterDisplay dummy/virtual display mirrored to the physical display? BetterDisplay dummies try to render 8-bit (but I'm pretty sure the actual output of the Mac in the end is still 10-bit, until progress on forcing bit depths is made), curious if the flicker pattern changes with that configuration

                          DisplaysShouldNotBeTVs @aiaf in addition to the obvious change made by disabling uniformity2D DISABLING "NormalModeEnable" ALSO MAKES A HUGE CHANGE

                          (⚠️ FYI, when disabling NormalModeEnable, make sure that ProMotion is off (use 60 FPS or lower.) Even though it also affects ProMotion, trackpad mouse cursor movement will get totally messed up, but this isn't an issue on 60 FPS and lower.)

                          after disabling:

                          at default gamma the screen will slightly change color tint and dark grays will get brighter

                          at darker gamma the screen gets A LOT brighter overall, and background colors look more solid

                          disabling it also makes shadows on windows feel less 3D (maybe because the level of backlight zones now becomes more similar between a dark window and a lighter background?)

                          AND on some pages, like the animation when you load the "MacBook Pro" page on Apple.com, there is even more banding after setting NormalModeEnable to false. (look at the white gaps between the laptops that are animating)

                          again, disabling this simply makes the screen BETTER, it removes another one of the strange tricks used to mask the imperfections(?) of the display, potentially this one is related to control of the mini-LED backlight zones?

                          this image on Apple's website implies that typically mini-LED zones will have different brightness per zone that attempts to match whatever image is being shown?

                          potentially this property reduces or disables this?

                          there are still some blotches of (now not dithered anymore) gray on white backgrounds visible at lower gammas, but we're just a property away from clean screen output (aside from forcing 8-bit which is also important), i can feel it

                          So far:

                          enableDither = false: way less text shimmer, can more easily visually process multiple occurrences of a repeating object at once, edges of "pixel-perfect" icons in Finder list view look sharper

                          uniformity2D = false: the "vignette effect" / fade at edges is GONE

                          NormalModeEnable = false: less "cloudy", more natural color tint

                          both uniformity2D and this potentially reduce the weird "fake 3D" effect

                          The issues that remain:

                          "Fuzzy text/glowing halo around text" (may be related to panels from one of the multiple manufacturers only, based on prior experience since one friend's Mac didn't have this issue), some shimmer on certain background colors, blotches of slightly different shades on solid backgrounds (that are very obvious now because they can't "blend in" by being dithered)

                            aiaf Thank you for your great work and sharing the technical details!

                            I tried to reverse the Apple silicon video drivers a year ago but gave up because of complicated logic of the driver set.

                              @aiaf do you have any pointers for being able to use IOKit in Swift on iOS so I could experiment with adjusting enableDither on my iOS devices? IOKit is a private framework on iOS and gives an error when trying to import it with IOKit.

                              Some people said they could use it through Objective-C instead, but I don't know how to write ObjC at all (despite me being very experienced with Swift). However, even when trying to do this just to see if it would work, I actually couldn't get IOKit to load in ObjC either.

                              ———

                              FYI: As I am a mobile developer, I have a LOT of iOS devices I've collected over the years… so I can certainly help with testing anything iOS-related if this ever becomes something you're interested in.

                              For reference:

                              Devices I own with "good screens": iPhone 4 (iOS 7), iPhone 5 (iOS 6.1.3 native, but also runs iOS 7/8 via dual boot), iPhone 6 (iOS 12), iPhone 7 (iOS 15), iPad mini 2 (iOS 10.2), iPad 6 (iOS 15)

                              Devices I own with "bad screens": iPhone 5s (iOS 12), iPad Pro 11" 2018 (iOS 17), iPhone SE 2 (iOS 17.2.1), iPhone 14 Pro (iOS 16.4)

                                dev