aiaf Thanks a lot for the new release. I tried uniformity2D on a Dell u2711 ( 8bit + FRC, but CCFL ) and it feels way better than before. I am surprised myself!
For a week now or so I used a Windows PC with an Nvidia 4060 GPU and dithering turned off which felt already pretty good but with uniformity2d turned off it seems to be the best experience I had in years.
But let's wait a bit more
Sentiny I could enable it and it made a difference for me. However "something happened" an I am back to Windows. Seems there is still something on OSX that is weird for my eyes. StillColor makes it however a lot better.
Continuation of my observations:
Got EVanlak 8K dummy hdmi plug. Set up the mirroring of it to external display connected to macbook pro 14 m1 pro via DP cable.
This dongle does not corrupt it's edid info (which is over 256 bytes for some reason). Also it has built in support for 120 hz mode and 1440p out of the box.
So it's basically plug and play setup for now.
I do see color banding like the true 8-bit mode without dithering
Whenever I connect it to Windows PC YCbCr 4:4:0 or 4:2:0 is shown in the connection details.
I have a suspicion that using YCbCr dummy and rgb output for external monitor forces 8-bit color internally.
Also tried flashing EDID with YCbCr signals completely removed from EDID. This way mirroring of RGB color space of dummy to RGB color space of external monitor did not help - I've got the same headaches as plugging to it using DP (without dummy mirroring).
Maybe the MacOS's dithering can also be disabled using YCbCr/RGB color space manipulations?
Connecting the monitor (AOC Q27G2S/EU 1440p 165 HZ 8-bit+FRC) using HDMI forces the color space to YCbCr with colors that look off (too darkened). However, the color banding is here the same as with YCbCr to RGB conversion.
Connecting the monitor using HDMI with modified EDID which has all the blocks related to YCbCr support removed results in the same picture 1 to 1 as when connecting using DP 1.4 cable (almost no banding seen) and immediate headaches.
Color reproduction seems the same when mirroring YCbCr hdmi dummy to RGB external display.
@DisplaysShouldNotBeTVs do you know why with StillColor enabled I see this on MBP M2 with touch bar?
ioreg -lw0 | grep -i enableDither
| | | | | "enableDither" = Yes
| | | | "enableDither" = No
| | | | "enableDither" = No
Do you know why first is Yes? Is it because touch bar is active?
Does anyone else get flickering of the entire display when some hdr video starts playing on M1 Max? It happens while browising Instagram, and it seems like there is some bug there. Flickers intensely for 1-3 sec. Happens when that window is in the background as well. Tried reverting to regular XDR profile and color profile, as well as disable BetterDisplay entirely. AppleAVD that processes video is involved.
Not exactly sure what it does, but this could be related to the percieved variation in the XDR display.
async When you start a HDR video, the screen switches to EDR mode which has a ramp-up time. During this time the available EDR headroom (the extra brightness beyond the SDR peak brightness) changes multiple times. When this happens the system dispatches out multiple system notifications to subscribing running apps asking them to re-tone-map their HDR content to match the changed luminance range. Some apps like Safari, Photos etc that can have HDR content on screen might redraw things as a consequence. This might cause flickering (normally it shouldn't though) + somewhat slow down the system temporarily.
If I kill it continously with this command I don't get the flicker. However it does generate console messages about the services and apps using it that was restarted, and causes a short freeze upon restarting after a while.
Not sure what this means, but I found it somewhat interesting.
while true; do ps aux | grep corebrightnessd; pgrep corebrightnessd | xargs kill -9; sleep 1; done
waydabber Awesome explanation. Any way to reliably disable it, to see if it brings any improvements? I guess I could delete the daemon entirely, but I have a feeling I'll be in safe mode scrambling to fix stuff pretty fast. Can't remember seeing this intense flickering of the entire screen before, but it was super visible on Instagram.
Sentiny Stumbled upon something relevant to enabling different options changing the rendering. AXVisualSupportAgent has been noted by others to use a lot of ram, and it shuts down when you disable all the relevant options. As you can see below it even has system calls to the brightness daemon.
sudo fs_usage | grep AXVisualSupportAgent
async ffmpeg is not my forte to be honest, and I didn't capture HDR on the BMD device. Are you trying to use it to capture your screen? Try asking ChatGPT to create the ffmpeg args for you, it will generally nudge you in the right direction with obviously broken code but you can then refine it by looking at docs and other examples on the web.
deepflame you must've been having a good eye day because uniformity2d is only applicable to the built-in display driver 
It's a proprietary Apple thing that affects the backlighting system on the TCON, and Stillcolor only toggles it for the built-in display.
pl01 unfortunately it's extremely challenging to change color bit depth and the default RGB 4:4:4 used on the internal display. For external displays, we can modify EDIDs, windowserver display plist, and use low bandwidth cables.
madmozg are sure you're running Stillcolor (also that it automatically launches on login) and that no other app touched the enableDither property? Try enabling/disabling dithering and check again.
While rummaging through logs, I thought I'd search for DCP messages to help figure out what color bit depth we're using internally, and lo and behold, the entire DisplayPort link setup and training is on show. Here's the relevant part:
The command to produce the above output is
log show --last 3h --info --predicate "processImagePath CONTAINS 'kernel' AND senderImagePath ENDSWITH 'DCP'"
Change 3h to the period you last turned on your Mac or changed resolution/framerate.
We can see Apple using a proprietary 7.992Gbps lane rate (just a tad shy of HBR3 8.1Gbps). At 4 lanes, this gives us a total link bandwidth of 31.968Gbps, or 25.5744Gbps usable bandwidth (DP has around 20% overhead).
We can also see that DSC is not used, and that the total video bandwidth is 25011120000bps, which barely fits within the usable bandwidth limit to transmit a maximum 3536x2456 at 8bpc and 120Hz.
This means it's impossible to transmit 10bpc at 120Hz at the required resolution, because that would require 31.264Gbps of usable bandwidth, which is not possible on HB3 rates, let alone Apple's 7.992Gbps.
Also the validateVideo function already tells us we're using 8bpc.
So GPU/DCP dithering makes a ton of sense now, and it's to work around bandwidth limitations. Apple cannot send 10bpc at 120Hz to the TCON, so it engineered the internal display pipeline to use 8bpc at all times, and by sending pre-temporally dithered frames to the TCON, it can claim 1 billion colors and 120Hz (ProMotion).
The 8 bits video input definition we saw on the EDIDs also confirm these findings.
The above logging trick also works for external displays, and it's useful for showing the negotiated color bit depth.
log show --last 3h --info --predicate "processImagePath CONTAINS 'kernel' AND senderImagePath CONTAINS 'DCPEXT'"
Again, replace 3h with the appropriate time period.
Here's the color bit depth I see on the external display when I connect the low bandwidth HDMI cable
It appears to select a color and timing mode to fit within the available bandwidth. AllRez and BetterDisplay do not report this "final" mode.
VS when I connect using a recent DP cable
There's a lot of questions now, such as whether the TCON is actively using its dithering system. The LUT config payloads from the ipsw packages are proving difficult to reverse engineer. Here's one of them
This kind of looks like nothing to me? Sequential 4-byte segments that are almost identical. Needs expert eyes to decipher for sure.
Additionally, what about @Blooey's gradient image? Why do we see fine gradations above the 8-bit section? Spatial dithering? Gamma trickery? Do we need to revise our assumptions about native 8-bit displays? Additional dithering from the DCP/GPU?
Whatever the case is, I think there's very little doubt that the panel receives an 8-bit signal.
aiaf yes i'm sure, i tried restart and reinstall app, everything 
The app works fine, I don't feel any problems with MBP 13' M2 with touchbar. But just wanted to ask why that parameter the only one has yes.
Here is the log:
{
"MaxVideoSrcDownscalingWidth" = 4096 "maxPeakBpp" = 0 "BacklightMatching" = {"IOPropertyMatch"={"backlight-control"=Yes}} "QoSDebug" = 0 "IOPersonalityPublisher" = "com.apple.driver.AppleMobileDispH14G-DFR" "IdleState" = 5 "ESDThresholdMS" = 0 "VRRDivisor" = 131072 "IOMFBTestBacklightDimValue" = 0 "IOMatchCategory" = "IODefaultMatchCategory" "PowerGateFrontEndIsIdle" = 0 "VRRIsIdle" = 0 "clockRatio" = 0 "VideoClock" = 0 "MemCacheState" = No "PowerGateADPIdleThreshold" = 3 "enableDarkEnhancer" = No "gamutConversionPipe0" = 0 "IdleCachingMethod" = 0 "IOMatchedAtBoot" = Yes "PixelClock" = 0 "IOProbeScore" = 0 "enableDither" = Yes "IOClass" = "AppleMobileADBE0" "SystemConsoleMode" = No "MaxSubtitleRegions" = 0 "DisplayPipeStrideRequirements" = {"StrideLinearVertical"=1,"StrideTiledHorizontal"=256,"StrideLinearHorizontal"=64,"StrideTiledVertical"=16} "IOMFB_KTRACE_API_VERSION" = "3.0" "enableSubPixelLayoutCompensation" = No "IONameMatched" = "dispdfr,t8112" "dfr" = Yes "VRRBurnInCooldownThreshold" = 60 "VRRBurnInCooldownEnabled" = No "IOReportLegend" = ({"IOReportGroupName"="IOMFB Reporting","IOReportChannels"=((5282525852084355412,4295098369),(5282525852083639635,4295098369)),"IOReportChannelInfo"={"IOReportChannelUnit"=0},"IOReportSubGroupName"="Total native/custom refresh rate"},{"IOReportGroupName"="IOMFB Reporting","IOReportChannels"=((5282525852084818770,25769934851)),"IOReportChannelInfo"={"IOReportChannelConfig"=<01000000000000000000000006000000>,"IOReportChannelUnit"=648518346341351424},"IOReportSubGroupName"="VBIs between user swaps"}) "DisplayPipePlaneBaseAlignment" = {"TileY_Alignment"=16,"PlaneBaseAlignmentLinear"=64,"PlaneBaseAlignmentTiled"=4096,"LinearY_Alignment"=1,"LinearX_Alignment"=64,"DefaultStride"=0,"TileX_Alignment"=256} "CFBundleIdentifier" = "com.apple.driver.AppleMobileDispH14G-DFR" "VRRIdleThreshold" = 5 "enableGammaCorrection" = Yes "enableADBEColorManager" = No "requestPixelBacklightModulation" = No "forcePixelBacklightModulation" = 2 "PowerGateADPIdleEnabled" = Yes "SPLCSupported" = No "SystemIdlenessEnabled" = Yes "VRRIdleEnabled" = No "enableVideoCaching" = No "IOMFBMaxSrcPixels" = {"PixelClock"=0,"MaxSrcRectTotal"=16777216,"MaxSrcBufferHeight"=65536,"VideoClock"=0,"MaxSrcRectWidth"=4096,"MaxSrcBufferWidth"=65536,"MaxVideoSrcDownscalingWidth"=4096} "IOMFBSupportsYFlip" = Yes "CFBundleIdentifierKernel" = "com.apple.driver.AppleMobileDispH14G-DFR" "IOReportLegendPublic" = Yes "IOMFB Debug Info" = {} "enablePLCMode" = No "VRRBurnInEnabled" = No "maxAverageBpp" = 0 "gamutConversionPipe1" = 0 "IOFunctionParent0000003F" = <> "SystemIdlenessThreshold" = 30 "IOMFBSupportsXFlip" = Yes "IOProviderClass" = "AppleARMIODevice" "ALSSRGBCoeffsPrecision" = 8 "IOMFBDisplayRefresh" = {"displayRefreshStepMachTime"=0,"displayRefreshStep"=0,"displayMaxRefreshInterval"=0,"displayMinRefreshInterval"=0,"displayMinRefreshIntervalMachTime"=0,"displayMaxRefreshIntervalMachTime"=0} "IONameMatch" = ("dispdfr,t8112") "DisplayIsIdle" = 0 "enableAmbientLightSensorStatistics" = Yes "VRRBurnInThreshold" = 108000 "enable2DTemperatureCorrection" = No "IOPowerManagement" = {"CapabilityFlags"=32768,"MaxPowerState"=1,"CurrentPowerState"=1} "IOMFBScalingLimits" = {"YUVLayer_MaxScale"=4,"YUVLayer_MinScaleFraction"=4,"RGBLayer_MinScaleFraction"=4,"RGBLayer_MaxScale"=4} "enablePowerGateDCS" = No "gamutConversionPostBlend" = 6 "VRRVersion" = 0 "ALSSSupported" = Yes "BlendOutputCSCMethod" = 0 "EnableEven60FPSFrames" = No "enableFiltersNoRewriteMode" = Yes "ADP is generic pipe" = Yes "InitialPanelTemperature" = 0}
aiaf Yep it is, properties like "enableSubPixelLayoutCompensation" implies OLED display related features
aiaf Amazing!
AllRez reports DP configuration details on Intel (afaik) but not on Apple Silicon. BetterDisplay does not report any DP connection details, it only deals with framebuffer bit depth, not connection bit depth.
The current data should be in the ColorModes section for the current Timing.
The log entry about connection color format Color: depth=8bpc encoding=0 [RGB 4:4:4] range=0 [Full] colorimetry=16 [Default RGB] should correspond to this:
I wanted to add these info to BetterDisplay but I am still not 100% sure how to figure out which ColorMode is the proper one when multiple modes are available (not a problem for the built-in display).
So, @aiaf & @waydabber -- what do these most recent findings mean "for dummies" from the standpoint of turning off dithering with Stillcolor?
new-jdm @aiaf has shown from the kernel logs that the color depth of the connection (negotiated by the "DCP", a component of the Apple Silicon chip that handles display connections among other things) from the GPU to the panel is 8-bit (this is about 16 million different colors). Since the panel can produce 8-bit colors without temporal dithering/FRC, this in theory should mean that if GPU side temporal dithering is turned off by StillColor or BetterDisplay, there should be no more temporal dithering going on at the panel side (for MBPs with XDR displays, but possibly other displays as well - logs need to be checked). The only remaining question is whether the "LUT", which is a look up table that typically tells the panel's controller ("TCON" - timing controller) how to produce the color values sent by the GPU, does introduce an unwanted element - or not. Very likely not. This remains to be seen.
The takeaway is that all this should give folks a peace of mind that temporal dithering is indeed turned off. 
