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

photon78s

That is why I was wondering why some says screens don't manage being color "accurate" over time and dithering and other algorithms can be used to "hide" defects in hardware. On my T480s, I recorded something but it is hard to be sure. Really need to find a better camera not just a better phone app with better camera sensor and ideally bigger/brighter scope as well.

Over at flickersense.org, it is reported that certain LED lights start out with no or very little flicker and start flickering over time as they "degrade". Similar things probably happen with screens.

Blooey

photon78s

photon78s Over at flickersense.org, it is reported that certain LED lights start out with no or very little flicker and start flickering over time as they "degrade". Similar things probably happen with screens.

Yes it’s my understanding that bulb manufacturers can use off-brand smoothing capacitors, where the liquid dialectic tends to dry up. This removes the smoothing capacitance from the original circuit.

async

DisplaysShouldNotBeTVs Here's the tool. It's a bit rough. If you have node installed it should be runnable with npm i; npm run start

https://we.tl/t-PNMjtpQ6Qd

Not really relevant in this topic, but out of curiousity, when you get glowing text at times, try to turn on the light on your cellphone and hold it to the side of your head so you see the reflection in the screen. Try moving the reflected light on top of the text you read, and try moving the head together with the light. At least for me that instantly gets the text into focus again. The effect is way more prominent with my Mateview 28 that has a matte screen. I've had some luck with aiming light at the screen from the side of the screen as well previously. Not exactly sure how it cleans up the "glow", but it sure changes how easy the text is to read at times. Might even be related the proproreception.

aiaf

async I'll give this a try with a capture card

aiaf

aiaf I made a quick (dis)proof of concept of a dither busting overlay

https://gist.github.com/aiaf/8006286d0b38fe02518bf7f8a8890918

Plays a transparent checkerboard pattern every other frame over most of the screen at 60fps. I checked with my capture card, it does not alter the pixels in a significant way frame-to-frame for the DCP dithering algorithm to change its behavior. In fact, this overlay becomes another source of eyestrain and screen instability in its current incarnation. But maybe someone can experiment with different patterns, frequencies, or blending modes and see if that makes a difference.

Easier to just disable DCP dithering entirely with Stillcolor.

Hunter20

aiaf

The Apple ProMotion mechanism automatically switches between 48/60/120hz according to the content you are running.

Therefore I think the advantage of running something on the screen has to be researched from a different perspective.

If you look at monitor reviews on https://www.rtings.com/ you can see that monitors show different behavior on different refresh rates. For example there are monitors who flicker if you run at a certain refresh rate (60hz), and also at the same time the same monitor doesn't flicker at the maximum refresh rate of the panel (120/144hz).

The ProMotion mechanism drops the refresh rate to 48hz if nothing is moving on the screen, but when you move your mouse it immediately goes up to 120hz. Argument of Apple is battery optimization. There is no setting to force fixed 120hz.

The point is if you have running a video (even invisible) on the screen the ProMotion mechanism changes in a different state. Atleast the author of this program found a notable difference: https://github.com/abinabdc/flickeringMacFix

I cannot test it myself as I have the MBA without ProMotion, but I think its definitely something worth to figure out. For example maybe there can be different PWM rates at different refresh rates.

async

DisplaysShouldNotBeTVs Any idea if similar apis will be accessible on iOS when pushing apps directly from XCode, or would it require jailbreaking? Unfortunately I'm at iOS 17 now, so that most likely won't be cracked for some time. Did a lot of jailbreaking previously, but forgot about it at some point.

MTNEYE

@aiaf thank you so much for working on this, super excited there's a chance I can have a usable M2.

as a note: I am using a M2 MBA 13" with a cheap eBay replacement screen I put it, kind that auto disables True Tone. Running Stillcolor I still notice same symptoms. I also see no banding, and no change whatsoever when toggling Stillcolor on/off. Tried running an RGB profile instead of usual sRGB but still no luck. Today I tried to se the banding on an M3 (I believe) 15 MBA in the Apple store and I could not notice it either.

Do you think you will be releasing a Beta to test the added features you were testing on your personal? would love to try.

Also to anyone what wants any info on this cheap replacement screen for research purposes, send me the commands to enter in terminal and I will pull up what I can. It seems to be identical the broken OEM one I had

Thanks again.

madmozg

MTNEYE I don't think that if you change your display on laptop going to remove dithering, because the connection cable from your motherboard to new display will still be the same and capable to send the same amount of data to your display, and the display will project the same, but I might be wrong. I think the same is happening with when you connecting external displays.

async

Hunter20 It goes way below that. See screenshot. Doesn't matter if it is with ProMotion or set to 60 hz. Both are variable. Low / High Power also doesn't seem to matter. It can be checked with Quartz Debug (Additional Tools for Xcode). Variable refresh rate is important for smooth scroll, but tbh I don't really see much difference. In Quartz Debug you can also force disable the variable refresh rate, but that creates screen tearing when scrolling.

There are flags for number of windows open in the framebuffer, and ofc the refresh rates change if you have anything that changes like a video in some other window. So there are tons of things that might change how it behaves.

asus389

Is there a way to programmatically set the frame rate to a fixed number on Mac OS? IIRC the "limit frame rate" setting only caps it at 60hz. It still drops lower if it "sees fit". So its still a variable refresh rate, albeit less so.

aiaf

Findings on external monitors & bit depth

This might be common knowledge on this forum, but I’ll share it anyway.

I have a Samsung Odyssey G7 which is reported as 10 bits (8-bit+FRC).

I’m using an old HDMI cable I have laying around whose provenance I’m uncertain of but the jacket reads “High Speed HDMI Cable with Ethernet.” It’s capable of a max 10.2 Gb/s transmission rate (1), (2). Let’s call it HSwE.

I can now confirm the following behavior on an M3 Max MPB (equipped with an HDMI 2.1 port capable of 48.0 Gb/s)

I set the monitor to 1920x1080 (HiDPI) at 60Hz.

When connected via HDMI-2.1 -> (HSwE cable) -> HDMI-2.0:
- (enableDither = No): Lagom gradient shows 128 distinct bands, screen is much easier to look at. My custom-made gray test shows a very obvious and abrupt change in tone when you toggle dithering.
- (enableDither = Yes): Lagom gradient is a lot smoother and shows 256 bands, corresponding with the change in grayscale value at 3px intervals. My gray test shows a colder gray. The gradient here looks as smooth as the gradient on my built-in display. Same gradations.

When connected via Thunderbolt/USB4->DP1.4 (TB/USB4 maxes out at 40Gb/s, DP 1.4 at 32.4Gbps)
- (enableDither = No): Lagom gradient looks just as smooth as my built-in display, showing 256 bars. There’s a shimmer around the top white border of the gradient, especially at higher brightness. My gray test shows a change in tone when toggling dithering, but not as obvious as when connected via HSwE-HDMI.
- (enableDither = Yes): gradient still has 256 bars. There’s a change in the quality and smoothness of the gradient that’s difficult to put into words, a difference in luminosity. My gray test shows a slightly darker shade of gray.

Conclusions:

Assuming RGB pixel encoding and no DSC (Display Stream Compression).

Using a HSwE HDMI cable or lower forces 8bpc. The bandwidth required to send 10bpc (32-bit signal) at 60Hz for 3840x2160 pixels (1920x1080 HiDPI) is around 14-16 Gbps + HDMI overhead. This requires at least a Premium High Speed HDMI® (aka Category 3 or 4K).
Increase refresh rate and resolution to increase bandwidth requirements (bandwidth calculator )
Using the USB4->DP cable allows the Mac to output a 32-bit signal which makes the external display apply its FRC/dithering algorithms, as evident by the above observations re. gradient banding.
M-series Macs apply DCP temporal dithering to the pixel buffer regardless of bit depth.
These Macs are capable of producing an 8-bit signal if forced to, at least based on bandwidth/speed negotiations. The machinery is there, we just have to find the right buttons.
So if you have a true 8-bit panel or 10-bit (8-bit+FRC), use an HSwE HDMI cable or lower + Stillcolor to eliminate temporal dithering entirely. Avoid 6-bit+FRC panels.
Based on the above observations re. banding and gray change, I conclude that the built-in display receives a 10bpc signal by default. The unknown right now is whether the built-in panel (at least on an M3 Max MBP) is true 10-bit or has additional temporal dither applied by the TCON (Time Controller), in addition to DCP dithering which Stillcolor successfully disables.

madmozg

aiaf Thanks for those tests. I also mentioned this in my comment before. With 4K monitors its easy to achieve those limitations with basic cables. But its hard if you have 1080p or 2K display 🙂

Also please take a look into chroma subsampling. https://en.wikipedia.org/wiki/Chroma_subsampling Its also very important thing.

jordan

aiaf that's an awesome finding. I've been wondering about using a lower bandwidth cable to purposely bottleneck output. I'm sure this would also apply on other computers. I'm curious if you got a dell up2720q true 10 bit monitor that if it would also use dithering still. I did look and dell acknowledges "8+A FRC" and also "true 10bit". So I think the up2720q can be the cheapest true 10bit option if anyone wants to try it. I think you can get them as cheap as $800 form b&h photo as open box condition through their eBay store and I think their site as well.

Pics show the true 10bit and then a 8+FRC to show that dell advertises both which makes me trust the up2720q being true 10bit

async

aiaf this is exceptional. I've suspected quality chabges between cables before. Maybe there is a flag or value where we can pick up the negotiated bandwidth or info about what is active. I looked into creating a tool to continously diff parts of ioreg to show deep changes as they happen, but didn't find enough time yet. I looked around in some other places as well, and there are lots of info. Do ioreg with the -a flag to output xml and more easily see deeper hierarchical values that are mostly there for debugging.

What I don't get is the many references to bitdepth 8 for the built in monitor.

Not sure, but I guess other interference from power cables might also be capable of affecting the bandwidth.

aiaf

aiaf I'd like to make one correction to these findings, the change in Lagom gradient banding observed in the undithered 8bpc signal is detected by adjusting software brightness/gamma/contrast using BetterDisplay. Otherwise, it's not necessarily 128 bands in 8bpc. Whereas on a 10-bit (8-bit+FRC) image, the 256 band count does not change or behave erratically with brightness/contrast/gamma adjustments. Thanks to @DisplaysShouldNotBeTVs for this tip.

This does not change my conclusion regarding bit depth being affected by cable choice.

Request

Can anyone with an M2 Air note or videotape their observations re. banding behavior and count with dithering disabled and through adjusting software brightness, gamma, and contrast?

aiaf

madmozg The Samsung Odyssey G7 is a 1440p panel, so there's that. You want to find a combination of resolution + refresh rate that makes 10bpc transmission physically impossible on your cable.

Re. YUV, I'm certain that output's pixel encoding is set to RGB, unless I'm misunderstanding something here.

aiaf

jordan unfortunately I don't have access to a true 10-bit panel (unless you count the built-in display if that turns out to be true). If anyone here has a Pro Display XDR you'll do us a real solid comparing it to the image of an M2/M3 Max/Pro, at least it will tell us they use the same tech.

MTNEYE

madmozg Totally yeah I get that, I just meant that sometimes no OEM screens yield different (usually worse) results then OEM. Basically there's no crazy increased flashing or dithering, same as before, also the display doesn't appear to be a sRGB/RGB/6 bit +FRC etc as you might think from a cheaper panel.

Not really related because it PWM but for example swapping a iPhone 13 mini I had from OEM OLED to LCD got rid of the PWM, with some draw backs. Also changing my iPhone 12 mini, no PWM at max brightness, to LCD got rid of the annoying dithering they added in iOS 17.

photon78s

aiaf

Potential other true 10-bit panels.
https://www.isolapse.com/best-true-10-bit-4k-monitor-for-color-grading-32-inch/

But then you have PWM with local dimming:
https://www.reddit.com/r/Monitors/comments/vnm4cf/asus_proart_pa32ucxk_coil_whine/

madmozg

@aiaf I've just reproduced how dithering works with different type of cables and external monitor with StillColor on/off. Making a video, will post in hour or two.

Looks very promising

aiaf

async Diffing is essential, thanks for the -a flag tip. I planned to do it for this investigation but I thought I'd post my initial findings first. Regarding Depth in the registry, it's not what you think it means.

Depending on where it appears, the known values are 4 and 8 (you can confirm this by looking at AllRez source code). Mine was set to 7 at some point in the past couple of months- not sure how or why or if it was me who did it.

DepthFormat = 8 => PixelEncoding = "--RRRRRRRRRRGGGGGGGGGGBBBBBBBBBB"
DepthFormat = 4 => PixelEncoding = "--------RRRRRRRRGGGGGGGGBBBBBBBB"

So a depth format of 8 means 10bpc

async

aiaf I created a continous diff solution. It's a starting point and can be adapted to other interesting areas. Finally got a working conversion of the data to json, so I used a json diff that also makes it easy enough to see where things changed.

Just created it, so didn't test anything yet, but you can see the AmbientBrightness changing live for example. I'm sure there are areas where you can monitor things related to the cable bandwith as well that can be found thru IORegistryExplorer.

This script needs jd for the diffing, so run brew install jd first, and then more or less just sh iodiff.sh

#!/bin/bash

CMD="ioreg -l -d0 -w0 -r -c AppleCLCD2 -a \
| sed -e '/^\t*<data>/,/^\t*<\/data>/ { /^\(\t*\)<data>\(.*\)/ { s//\1<string>_data:\2/; h; d; }; /^\t*<\/data>\(.*\)/! { s/^\t\(.*\)/\1/; H; d; }; /^\t*<\/data>\(.*\)/ { s//\1:data_<\/string>/; H; g; s/\n//g; }; }' \
| plutil -convert json -r - -o -"
SLEEP_TIME=5

OLD_FILE="/tmp/iodiff_old.json"
NEW_FILE="/tmp/iodiff_new.json"

# Initialize both files before starting the loop
eval "$CMD" > "$OLD_FILE"
cp "$OLD_FILE" "$NEW_FILE"

print_heading() {
  echo "\033[1m$1\033[0m"
}

print_heading "$(date)"
cat "$OLD_FILE"
echo ""

while true; do
  eval "$CMD" > "$NEW_FILE"
  OUTPUT=$(jd -color "$OLD_FILE" "$NEW_FILE")
  if [ ! -z "$OUTPUT" ]; then
    print_heading "$(date +"%Y-%m-%d %H:%M:%S")"
    echo "$OUTPUT"
  fi
  mv "$NEW_FILE" "$OLD_FILE"

  sleep "$SLEEP_TIME"
done

async

async Here is a version of the script that does not stream outputs.
So that means you can run sh iodiff.sh, change some cable or thing, then run iodiff.sh again to see what changed. It should probably target some other places as well, or diff some of the AllRez output, but it's a starting point to try to work out what actually happens in different circumstance.

#!/bin/sh

CMD="ioreg -l -d0 -w0 -r -c AppleCLCD2 -a \
| sed -e '/^\t*<data>/,/^\t*<\/data>/ { /^\(\t*\)<data>\(.*\)/ { s//\1<string>_data:\2/; h; d; }; /^\t*<\/data>\(.*\)/! { s/^\t\(.*\)/\1/; H; d; }; /^\t*<\/data>\(.*\)/ { s//\1:data_<\/string>/; H; g; s/\n//g; }; }' \
| plutil -convert json -r - -o -"

OLD_FILE="/tmp/iodiff_old.json"
NEW_FILE="/tmp/iodiff_new.json"

# Execute command and save output to NEW_FILE
eval "$CMD" > "$NEW_FILE"

# Compare OLD_FILE and NEW_FILE if OLD_FILE exists
if [ -f "$OLD_FILE" ]; then
  OUTPUT=$(jd -color "$OLD_FILE" "$NEW_FILE")
  if [ ! -z "$OUTPUT" ]; then
    echo "$OUTPUT"
  fi
fi

# Move NEW_FILE to OLD_FILE for next comparison
mv "$NEW_FILE" "$OLD_FILE"

« Previous Page Next Page »