Lauda89 sorry to hear.

Well, I guess the best would be to have a reliable and easy to perform testing procedure. So we are sure that the changes are based on facts rather than feelings or even placebo.

Having said that I want to share some of my nonscientific experiences.
Before using StillColor I noticed that OS/software-wise not only OSX's dithering is the problem. Running some apps make the pixel flickering worse.

  • I cannot use Firefox or Chrome. Both are hard to read and I result to using Safari now
  • Blender 4.0.0 is better than 4.0.1 ( both Apple Silicon )
  • VisualStudio Code is good until I install the vim-Plugin. That makes the screen flicker even more, not sure why. Using the vim-Plugin with nvim as a backend works however. ( the problem with the vim-plugin is even true on Linux )
  • When using tmux ( terminal multiplexer ) the screen seems to be more straining than without. So I need to work with multiple terminal windows or use the one within vscode.
  • being on a video call in Zoom made it worse ( true on Windows, need to retest on OSX )
  • some background tasks seemed to make it worse also
  • and even having some apps from the appstore installed ( but this might just be a feeling, not sure if this is true )

So, my suggestion would be to turn off any background tasks ( also auto updaters ), and remove any apps from the AppStore that you do not need.

Hope that helps.

It was a long process for me and I think I found something now that I can use for work. Cheers

      NewDwarf The main thing which is not clear for me is how the input file (input.mov) being processed reveals temporal dithering? Each frame is processed programmatically and ffmpeg does diffs between the consecutive frames. The video frame is not even placed in the video buffer of the graphics card

      input.mov is a capture of an HDMI frame buffer. An UltraStudio Recorder 3G was used to capture that buffer.

      You can tell the frequency of dithering by counting the frames between changes. The time blend is the isolated temporal dithering signal. So if every frame has a different pattern, we know the dithering occurs in sync with the refresh rate.

          Blooey How to interpret results after capturing the static screen via HDMI?

          What will be on the diff.mov in the case of temporal dithering?

          ADDED: It looks like, the captured static screen (without dithering) after processing will be just solid gray color.

              NewDwarf What will be on the diff.mov in the case of temporal dithering?

              It will show the difference in sub-pixel brightnesses between the dithering noise from this frame, and the previous frame, where middle gray is the zero value. So to be more accurate, this is not the actual dither signal per frame, it is the difference between the past two dithering signals. We are assuming that this noise pattern is an FRC color dithering pattern intended to increase the panel bits per color.

              To get into the weeds a bit, I think it is unlikely that Apple is using an accurate color dither across pairs of frames. My guess is they would use a simpler approach that applies a standard spatial dither, but re-randomized per frame. Over time, this would approximate an accurate per frame color dither.

              The diff.mov shows each sub pixel rise, or fall in brightness, or do nothing. All by a single 8 bit integer value. To be fair, I haven't looked closely at those files yet. But this should be the case. Whether the output rises or falls is determined by a standard color dithering algorithm.

              A good algorithm would be to first convert the 10 bit color value to 0-1, then multiply that by the number of brightness steps available native to that display. So if we are converting to an 8 bit native display, that is 255 steps. Then, you add to this value a random number from 0-1. Then convert that sum to 8 bits. The 8 bit conversion chops off the remainder. What you are left with is a seemingly randomized 8 bit brightness value, that amazingly still can contribute to a 10 bit signal. We can extract and display the exact 10 bit value by repeating and displaying the output of this algorithm over time (temporary). If the frame rate is fast enough, you can achieve the 10 bit precision again. The other extraction works spatially across pixels, but that is not the focus of Stillcolor.

                deepflame I too have noticed this phenomenon. My current Machine, a 2017 13 inch Macbook Pro (no touch bar) was pretty much fine with all versions of Mac OS through Catalina. Starting with Big Sur, I had issues with different OS versions and versions of browsers and apps. I couldn't use Big Sur or Monterrey on this machine at all. I am now on Mac OS Ventura and as long as I set a black wallpaper, disable wallpaper tinting of windows, and also use the "green" accent and highlight color that is default on the green M1 iMac I do OK with the OS and most apps.

                The main sticking point has been browsers. I pretty much exclusively used Safari through version 13, but versions 14, 15, and 16 on Mac OS caused migraine aura like symptoms. 17 is somewhat better. But I migrated to using Firefox with dark mode, dark theme, and gfx.color_management.mode = 2. I also use the ESR version because I've noticed on the main branch they tend to add and break stuff that sometimes effects the graphics rendering. ESR is more stable - I've rarely had an issue with it.

                The only explanation I can come up with for all of this is that sometime around the Big Sur OS release and Safari 14, they started making use of wide color in web rendering and also in some OS and app graphics. This caused my previously good mbp to dither more using certain colors and start to cause issues - unless I use certain settings? But I don't really know.

                I am fine with the M1 iMac (even on default settings, even in Safari - except I still use green accent color) and also the M2 Mac Mini and studio display (even with Safari and use the default accent color). All of the Apple Silicon laptops so far have bothered me in one way or another.

                  Blooey thank you, it's very helpful.

                  deepflame this is great! I'm glad to hear it's working for you. Re. iOS, I don't see why a similar solution wouldn't work if indeed dithering is toggled via the same mechanism. We just need to get there. I think @DisplaysShouldNotBeTVs is working on something.

                  asus389 this is the million dollar question. Waiting for someone with a true 10-bit display to try it out and measure things. If it indeed turns off dithering in response to a 10-bit panel, that would be amazing. In fact, you don't even need a 10-bit display, TRUE 8-bit (which seems tricky to find also) with Stillcolor should suffice.

                  jordan which ViewSonic model is that? They released a new VX2781-4K-PRO-6 with IGZO IPS panel in China a few days ago which claims to be true 10-bit!

                  madmozg the mechanism is the same across all M-series Macs. It disables the enableDither property and with that the GPU/DCP stops applying temporal dithering to the pixel buffer. Try using an sRGB color profile and see if that makes an additional difference. Did you enable Launch at login? The app needs to run every time the computer starts.

                  NewDwarf @Blooey explained it very nicely. The main thing to note is that Apple's GPU/DCP applies temporal dithering to the pixel buffer way before it even touches your HDMI/Thunderbolt port. That's why you can capture all of this with an HDMI capture card.

                                aiaf I have seen the desktop Pro Display XDR cited as being true 10 bit, but I have no way to verify. Its also Mini-LED which I think would complicate things.

                                  madmozg Also, if you can tolerate the smaller scale of the UI and text, try setting your display scale setting to the option that is exactly 200% retina scaling (this is not the default for some reason), rather than one of the other scaling settings. This should eliminate some blurry/shimmering text.

                                    The built in display in my 2017 MBP shows:

                                    Color LCD:

                                    Display Type: Built-In Retina LCD

                                    Resolution: 2560 x 1600 Retina

                                    Framebuffer Depth: 24-Bit Color (ARGB8888)

                                    Does anyone have the equivalent M1 or M2 13 inch Macbook Pro? Or even a newer than 2017 intel 13 inch? Does it report 8 bit color by default or is it 10 bit? Does this change if you use StillColor? IIRC they used the same basic panel all the way through the end of the 13 inch w/ and w/o touchbar models. But maybe not?

                                      aiaf
                                      The model I inquired about was the vp2786-4k monitor. I can ask them about that igzo one but I'm sure it's probably 8+2frc. They word it as true 10 bit color, not sure if that's being tricky and not true 10 bit panel.

                                      The only other two I'm aware of are the up2720q dell and the Eizo cs2740

                                      Edit: oh didn't realize the igzo one is China only they probably won't tell me until it's released here in US.

                                        aiaf Re. iOS, I don't see why a similar solution wouldn't work if indeed dithering is toggled via the same mechanism. We just need to get there. I think @DisplaysShouldNotBeTVs is working on something.

                                        I'm stuck, I haven't really been able to get anything working so far as I don't know how to interface with the IOKit features you've used within iOS.

                                        I've tried referencing two older projects called GammaThingy and GoodNight, but the way they're interfacing with the IOMobileFramebuffer isn't using the "registry" and didn't seem to give me access to the enableDither parameter (they work more similarly to the earlier ways you were trying to interface with IOKit, where you weren't able to change certain parameters).

                                        Those projects can successfully change "reduce white point" (below the system limit, in fact) and invert color/grayscale settings, but trying to change other parameters causes them to crash or simply do nothing. I think this is due to them not using the registry method.

                                        It would really, really help me out if you could set up a really basic iOS Xcode project that simply provides a way to call the same functions/private APIs that Stillcolor uses on Mac, in a way that builds successfully with an iOS target. (If it has to be in Objective-C, that's fine.)

                                        Then I could take it from there, I can hook up a simple UI and test it on a ton of my iOS devices, I know exactly what signs and small details to look for to see if dithering can be disabled successfully.

                                          asus389 All Apple Silicon Macs, including the 13" Touchbar LCD M1/M2 Pros, always output a 10-bit signal (this can be seen in BetterDisplay) even if the internal laptop panel is technically 8-bit or even when an external monitor the laptop is connected to is 8-bit.

                                          macOS provides no way to truly force a lower color depth on Apple Silicon, that's why it would be a big deal if Stillcolor is able to gain this feature.

                                          You can "mirror" an 8-bit virtual desktop to a physical screen on an Apple Silicon Mac with BetterDisplay, but I'm pretty sure the signal at the very end is still 10-bit, especially on the internal displays.

                                          Later Intel Macs use a 10-bit signal by default but also allow you to switch to an 8-bit signal using software like BetterDisplay or SwitchResX. Unfortunately both use temporal dithering anyway (this is to allow macOS to be able to apply a bunch of stuff like color profile calibration, gamma calibration, mapping sRGB content to P3, Night Shift, transparency effects without introducing banding…)

                                              DisplaysShouldNotBeTVs with real device testing I found that Macbook Pro 16'' in 2019 with new keyboard and with Intel chipset was the first macbook started to use Dithering. Would be great to know if there is a real switch to turn off dithering on Intel/AMD GPUs for macbooks.

                                              As you mentioned, I also think that M1/M2/M3 chip was designed only outputting 10bit signal, and it doesn't support any back compatibility.

                                              Btw just remembered that when I was testing Macbook pro 16' 2019, I was having issues when AMD GPU was enabled, and as soon as I switched to Intel graphics dithering was not bothering me.

                                                  aiaf yes I tried with sRGB, i'm pretty much sure its doesn't do anything, but just a color correction.

                                                    madmozg counterpoint: I have a 2015 retina macbook pro 15", so way before the 2019, but it also has Intel Iris Pro and AMD graphics. The dithering on it is really bad, shimmer everywhere, can clearly notice solid-color backgrounds moving, despite being all the way back from 2015.

                                                    I have even found a new AMD dither disable method that works on the 2015 that does improve external monitor output. However, even though it also affects the internal display in some way, there is still moving shimmer.

                                                    I'm pretty sure this is coming from something macOS itself is additionally doing, since even though I've figured out how to get the AMD graphics card to disable its own dithering (which seems to specifically concern color profiles / gamma tables, because both of those cause much stronger banding after applying the method), the IOKit registry still says "automatic" dither mode and "dith=true", as I've mentioned in a previous post in this thread. I assume these two are related to extra processing by macOS itself for the internal display.

                                                    FWIW, my 2015 Pro is on Monterey 12.6.8.

                                                    So there was definitely macbooks before 2019 that had dithering, especially the ones with AMD graphics (although on mine I can still see shimmering even in integrated intel mode too, although it is a bit less than in AMD mode)

                                                      DisplaysShouldNotBeTVs macOS provides no way to truly force a lower color depth on Apple Silicon, that's why it would be a big deal if Stillcolor is able to gain this feature.

                                                      Did you look at the EDID direction?

                                                      Probably, changing the EDID value can tell to the graphics card to enforce using of the 8-bit mode.

                                                          Got stuff to run. Experimenting with different options. Seems like most stuff doesn't really affect anything noticable, but at least they can be changed. BacklightMatching is interesting, but I didn't manage to change it as it is a dict and this is a bit new too me. ChatGPT / Claude can give a fairly good guestimate on what different things are.

                                                          "BacklightMatching" = {"IOPropertyMatch"={"backlight-control"=Yes}}

                                                          Some output from ChatGPT

                                                          Let's illuminate the path by highlighting the cryptic runes that might hold the power to alter the very fabric of visual presentation, based on their assumed roles in this arcane machinery:

                                                          Dithering and Flicker Management:

                                                          • enableDither: No (A clear toggle for dithering, turning on or off could influence visual quality and potentially affect flickering.)

                                                          • uniformity2D: No (May relate to screen uniformity adjustments, possibly involving dithering processes.)

                                                          • enable2DTemperatureCorrection: No (Temperature-related corrections could impact display properties, possibly affecting flicker.)

                                                          • IOMFBDigitalDimmingLevel: Various values (Controls the dimming level; digital dimming techniques can influence flicker.)

                                                          • enablePixelCapture: No (While not directly related, capturing pixel data might involve processes that can influence screen rendering and flicker.)

                                                          • IOMFBBrightnessCompensationEnable: Yes/No (Adjusts brightness dynamically, potentially influencing flickering behaviors.)

                                                          • IOMFBBrightnessLevel: Various values (Direct control over brightness can impact the visibility and perception of flicker.)

                                                          • IOMFBBrightnessLevelMA: Various values (Likely related to manual adjustment of brightness levels, affecting flicker perception.)

                                                          • IOMFBBrightnessLevelIDAC: Various values (IDAC adjustments relate to current control for brightness, impacting flicker.)

                                                          • IOMFBTemperatureCompensationEnable: Yes/No (Temperature compensation can alter display characteristics, potentially affecting flicker.)

                                                          Advanced Control and Optimization:

                                                          • DisableDisplayOptimize: 0 (Disabling optimizations might reveal underlying flicker or dithering artifacts by removing compensations.)

                                                          • enableDarkEnhancer: No (Enhancing dark regions may involve adjusting dithering or dimming strategies to reduce flicker.)

                                                          • PCCEnable: Yes (Pixel Compensation Curves can affect how visuals are rendered, possibly influencing dithering and flicker.)

                                                          • enableLinearToPanel: Yes (Adjustments between linear light and panel display can involve processes that affect flickering.)

                                                          • enableDefaultTemperatureCorrection: No (Indicates if default temperature correction is used, which can affect visual output and potentially flicker.)

                                                          Display Performance and Quality:

                                                          • DispPerfState: 0 (Performance states can affect how content is rendered and displayed, including flicker management strategies.)

                                                          • IOMFBSupportsICC: Yes (ICC profiles control color management, which can indirectly affect visual rendering processes related to dithering and flickering.)

                                                          • IOMFBSupports2DBL: Yes/No (2D backlighting support might influence how backlight adjustments are made, affecting flicker.)

                                                          Debug and Testing:

                                                          • DebugUInt32: 0 (Generic debug parameter; its role in flickering/dithering is uncertain without further context but could be useful for testing.)

                                                          • IOMFB Debug Info: {} (Contains debug information; could reveal insights into flicker and dither control mechanisms during troubleshooting.)

                                                            I actually had some situations where after thinkering the backlight wass off reopening the lid. So it seems like some things might require more than just changing the value.

                                                            async Awesome! Keep experimenting, are you measuring things subjectively or are you doing microscopy? Personally I'd take anything ChatGPT spouts about these props with a grain of salt. I think brightness compensation is something we should spend more time on.

                                                                dev