terminal
terminal copied to clipboard
microsoft
Refine customization around text color adjustment
Windows Terminal version
1.16.10262.0
Windows build number
10.0.22000.0
Other Software
Inside WSL
Steps to reproduce
Running the following shell script:
T='●●●'
echo -e "\n 40m 41m 42m 43m\
44m 45m 46m 47m";
for FGs in ' m' ' 1m' ' 30m' '1;30m' ' 31m' '1;31m' ' 32m' \
'1;32m' ' 33m' '1;33m' ' 34m' '1;34m' ' 35m' '1;35m' \
' 36m' '1;36m' ' 37m' '1;37m';
do FG=${FGs// /}
echo -en " $FGs \033[$FG $T "
for BG in 40m 41m 42m 43m 44m 45m 46m 47m;
do echo -en "$EINS \033[$FG\033[$BG $T \033[0m";
done
Expected Behavior
Colors in VS Code terminal look like this (all combinations are readable):
Actual Behavior
In the Terminal app, things are worse:
I tried changing color schemes to no avail. Changing "Automatically adjust lightness of indistinguishable text" setting doesn't seem to have any effect either.
2023-03-06 UPDATE
Investigation Into VS Code Inner Workings
The contrast adjustment in VS Code terminal is set by terminal.integrated.minimumContrastRatio in settings. Mentioned in the docs a11y section: .../editor/accessibility#_terminal-accessibility - number between 1 and 21 with 4.5 as a default.
Actually, makes perfect sense it being an accessibility feature. With normal vision some bg/fg combinations are annoyingly hard to process. For a person with even mild colorblindness they could be completely unreadable.
The travel path for the minimum contrast value is:
- The settings value is sent to the
xterm.jsinstance that does the terminal rendering: vscode/.../xtermTerminal.ts:209; xterm.jsinvokes.ensureContrastRatioin xterm.js/.../DomRendererRowFactory.ts:338;- Which is implemented in Color.ts:259 and performs the adjustment based on
relativeLuminance(same file just above).
Most of the math is in there. I haven't found the place where background colors are adjusted (they are clearly darkened a bit).
Reasons to Reuse it for the Terminal App
- Consistency with the other MS app, people that use the setting in one app may look for the same setting in the other;
- Good for a11y (the current adjustment algorithm just isn't aggressive enough, since even with normal vision it's hardly noticeable).
Also, it would be really cool to have an option for the Terminal app to outright pick up VS Code settings (color scheme, minimum contrast, font family, font size, keybindings, etc...), but that is certainly a scope creep in the context of this issue.
Sure. Note that I did try most of the available options that can be in any way related. This is what it looks like after all my manipulation:
settings.json
{
"$help": "https://aka.ms/terminal-documentation",
"$schema": "https://aka.ms/terminal-profiles-schema",
"actions":
[
{
"command":
{
"action": "splitPane",
"split": "right"
},
"keys": "alt+shift+o"
},
{
"command":
{
"action": "splitPane",
"profile": "{00000000-0000-0000-ba54-000000000002}",
"split": "auto"
},
"keys": "alt+shift+5"
},
{
"command":
{
"action": "splitPane",
"profile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
"split": "auto"
},
"keys": "alt+shift+1"
},
{
"command": "find",
"keys": "ctrl+shift+f"
},
{
"command": "unbound",
"keys": "ctrl+c"
},
{
"command": "unbound",
"keys": "ctrl+v"
},
{
"command":
{
"action": "splitPane",
"profile": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
"split": "auto"
},
"keys": "alt+shift+2"
},
{
"command":
{
"action": "splitPane",
"split": "down"
},
"keys": "alt+shift+h"
},
{
"command":
{
"action": "splitPane",
"profile": "{2c4de342-38b7-51cf-b940-2309a097f518}",
"split": "auto"
},
"keys": "alt+shift+3"
},
{
"command":
{
"action": "splitPane",
"split": "auto"
},
"keys": "alt+shift+d"
},
{
"command":
{
"action": "splitPane",
"profile": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
"split": "auto"
},
"keys": "alt+shift+4"
}
],
"copyFormatting": "none",
"copyOnSelect": false,
"defaultProfile": "{d7b20cea-47a9-518c-95a4-c8bd91e2e1c6}",
"profiles":
{
"defaults":
{
"adjustIndistinguishableColors": "always",
"colorScheme": "VSCode WSL",
"font":
{
"face": "FiraCode NFM",
"features":
{
"calt": 1,
"ss03": 1,
"ss05": 1
},
"size": 14.0
},
"useAtlasEngine": false
},
"list":
[
{
"adjustIndistinguishableColors": "indexed",
"antialiasingMode": "cleartype",
"colorScheme": "VSCode WSL",
"font":
{
"face": "FiraCode NFM",
"size": 14.0,
"weight": "normal"
},
"guid": "{d7b20cea-47a9-518c-95a4-c8bd91e2e1c6}",
"hidden": false,
"name": "Ubuntu 22.04.2 LTS",
"opacity": 100,
"source": "CanonicalGroupLimited.Ubuntu22.04LTS_79rhkp1fndgsc",
"useAtlasEngine": true
},
{
"guid": "{17bf3de4-5353-5709-bcf9-835bd952a95e}",
"hidden": true,
"name": "Ubuntu-22.04",
"source": "Windows.Terminal.Wsl"
},
{
"guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
"hidden": false,
"name": "Windows PowerShell"
},
{
"guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
"hidden": false,
"name": "Command Prompt"
},
{
"guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
"hidden": true,
"name": "Ubuntu",
"source": "Windows.Terminal.Wsl",
"startingDirectory": "//wsl$/Ubuntu/home/ignat/projects"
},
{
"guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
"hidden": true,
"name": "Azure Cloud Shell",
"source": "Windows.Terminal.Azure"
},
{
"commandline": "%PROGRAMFILES%/git/usr/bin/bash.exe -i -l",
"guid": "{00000000-0000-0000-ba54-000000000002}",
"icon": "%PROGRAMFILES%/Git/mingw64/share/git/git-for-windows.ico",
"name": "Git Bash",
"startingDirectory": "%USERPROFILE%"
},
{
"guid": "{b9363be8-5790-5ecc-b943-5154b666d572}",
"hidden": true,
"name": "Developer Command Prompt for VS 2022",
"source": "Windows.Terminal.VisualStudio"
},
{
"guid": "{5e2884e9-b7c4-583f-856c-c712398f7c29}",
"hidden": true,
"name": "Developer PowerShell for VS 2022",
"source": "Windows.Terminal.VisualStudio"
},
{
"guid": "{b8fff302-10ea-579a-82f8-ed4d452b3a4d}",
"hidden": true,
"name": "Developer Command Prompt for VS 2019",
"source": "Windows.Terminal.VisualStudio"
},
{
"guid": "{1d58632f-d73e-54fd-909a-c3c09e989d2f}",
"hidden": true,
"name": "Developer PowerShell for VS 2019",
"source": "Windows.Terminal.VisualStudio"
},
{
"guid": "{c520fdae-4659-598e-bedb-4899c12fc45b}",
"hidden": true,
"name": "Developer Command Prompt for VS 2017",
"source": "Windows.Terminal.VisualStudio"
},
{
"altGrAliasing": true,
"antialiasingMode": "grayscale",
"closeOnExit": "automatic",
"commandline": "%SystemRoot%\\System32\\cmd.exe",
"cursorShape": "bar",
"elevate": true,
"guid": "{ffcfd0e1-d07a-4fbd-8aee-d2948fedd21b}",
"hidden": false,
"historySize": 9001,
"icon": "ms-appx:///ProfileIcons/{0caa0dad-35be-5f56-a8ff-afceeeaa6101}.png",
"name": "Command Prompt (Admin)",
"padding": "8, 8, 8, 8",
"snapOnInput": true,
"startingDirectory": "%USERPROFILE%",
"useAcrylic": false
}
]
},
"schemes":
[
{
"background": "#0C0C0C",
"black": "#0C0C0C",
"blue": "#0037DA",
"brightBlack": "#767676",
"brightBlue": "#3B78FF",
"brightCyan": "#61D6D6",
"brightGreen": "#16C60C",
"brightPurple": "#B4009E",
"brightRed": "#E74856",
"brightWhite": "#F2F2F2",
"brightYellow": "#F9F1A5",
"cursorColor": "#FFFFFF",
"cyan": "#3A96DD",
"foreground": "#CCCCCC",
"green": "#13A10E",
"name": "Campbell",
"purple": "#881798",
"red": "#C50F1F",
"selectionBackground": "#FFFFFF",
"white": "#CCCCCC",
"yellow": "#C19C00"
},
{
"background": "#012456",
"black": "#0C0C0C",
"blue": "#0037DA",
"brightBlack": "#767676",
"brightBlue": "#3B78FF",
"brightCyan": "#61D6D6",
"brightGreen": "#16C60C",
"brightPurple": "#B4009E",
"brightRed": "#E74856",
"brightWhite": "#F2F2F2",
"brightYellow": "#F9F1A5",
"cursorColor": "#FFFFFF",
"cyan": "#3A96DD",
"foreground": "#CCCCCC",
"green": "#13A10E",
"name": "Campbell Powershell",
"purple": "#881798",
"red": "#C50F1F",
"selectionBackground": "#FFFFFF",
"white": "#CCCCCC",
"yellow": "#C19C00"
},
{
"background": "#282C34",
"black": "#282C34",
"blue": "#61AFEF",
"brightBlack": "#5A6374",
"brightBlue": "#61AFEF",
"brightCyan": "#56B6C2",
"brightGreen": "#98C379",
"brightPurple": "#C678DD",
"brightRed": "#E06C75",
"brightWhite": "#DCDFE4",
"brightYellow": "#E5C07B",
"cursorColor": "#FFFFFF",
"cyan": "#56B6C2",
"foreground": "#DCDFE4",
"green": "#98C379",
"name": "One Half Dark",
"purple": "#C678DD",
"red": "#E06C75",
"selectionBackground": "#FFFFFF",
"white": "#DCDFE4",
"yellow": "#E5C07B"
},
{
"background": "#FAFAFA",
"black": "#383A42",
"blue": "#0184BC",
"brightBlack": "#4F525D",
"brightBlue": "#61AFEF",
"brightCyan": "#56B5C1",
"brightGreen": "#98C379",
"brightPurple": "#C577DD",
"brightRed": "#DF6C75",
"brightWhite": "#FFFFFF",
"brightYellow": "#E4C07A",
"cursorColor": "#4F525D",
"cyan": "#0997B3",
"foreground": "#383A42",
"green": "#50A14F",
"name": "One Half Light",
"purple": "#A626A4",
"red": "#E45649",
"selectionBackground": "#FFFFFF",
"white": "#FAFAFA",
"yellow": "#C18301"
},
{
"background": "#002B36",
"black": "#002B36",
"blue": "#268BD2",
"brightBlack": "#073642",
"brightBlue": "#839496",
"brightCyan": "#93A1A1",
"brightGreen": "#586E75",
"brightPurple": "#6C71C4",
"brightRed": "#CB4B16",
"brightWhite": "#FDF6E3",
"brightYellow": "#657B83",
"cursorColor": "#FFFFFF",
"cyan": "#2AA198",
"foreground": "#839496",
"green": "#859900",
"name": "Solarized Dark",
"purple": "#D33682",
"red": "#DC322F",
"selectionBackground": "#FFFFFF",
"white": "#EEE8D5",
"yellow": "#B58900"
},
{
"background": "#FDF6E3",
"black": "#002B36",
"blue": "#268BD2",
"brightBlack": "#073642",
"brightBlue": "#839496",
"brightCyan": "#93A1A1",
"brightGreen": "#586E75",
"brightPurple": "#6C71C4",
"brightRed": "#CB4B16",
"brightWhite": "#FDF6E3",
"brightYellow": "#657B83",
"cursorColor": "#002B36",
"cyan": "#2AA198",
"foreground": "#657B83",
"green": "#859900",
"name": "Solarized Light",
"purple": "#D33682",
"red": "#DC322F",
"selectionBackground": "#FFFFFF",
"white": "#EEE8D5",
"yellow": "#B58900"
},
{
"background": "#000000",
"black": "#000000",
"blue": "#3465A4",
"brightBlack": "#555753",
"brightBlue": "#729FCF",
"brightCyan": "#34E2E2",
"brightGreen": "#8AE234",
"brightPurple": "#AD7FA8",
"brightRed": "#EF2929",
"brightWhite": "#EEEEEC",
"brightYellow": "#FCE94F",
"cursorColor": "#FFFFFF",
"cyan": "#06989A",
"foreground": "#D3D7CF",
"green": "#4E9A06",
"name": "Tango Dark",
"purple": "#75507B",
"red": "#CC0000",
"selectionBackground": "#FFFFFF",
"white": "#D3D7CF",
"yellow": "#C4A000"
},
{
"background": "#FFFFFF",
"black": "#000000",
"blue": "#3465A4",
"brightBlack": "#555753",
"brightBlue": "#729FCF",
"brightCyan": "#34E2E2",
"brightGreen": "#8AE234",
"brightPurple": "#AD7FA8",
"brightRed": "#EF2929",
"brightWhite": "#EEEEEC",
"brightYellow": "#FCE94F",
"cursorColor": "#000000",
"cyan": "#06989A",
"foreground": "#555753",
"green": "#4E9A06",
"name": "Tango Light",
"purple": "#75507B",
"red": "#CC0000",
"selectionBackground": "#FFFFFF",
"white": "#D3D7CF",
"yellow": "#C4A000"
},
{
"background": "#300A24",
"black": "#171421",
"blue": "#0037DA",
"brightBlack": "#767676",
"brightBlue": "#08458F",
"brightCyan": "#2C9FB3",
"brightGreen": "#26A269",
"brightPurple": "#A347BA",
"brightRed": "#C01C28",
"brightWhite": "#F2F2F2",
"brightYellow": "#A2734C",
"cursorColor": "#FFFFFF",
"cyan": "#3A96DD",
"foreground": "#FFFFFF",
"green": "#26A269",
"name": "Ubuntu-22.04-ColorScheme",
"purple": "#881798",
"red": "#C21A23",
"selectionBackground": "#FFFFFF",
"white": "#CCCCCC",
"yellow": "#A2734C"
},
{
"background": "#000000",
"black": "#777C7D",
"blue": "#5C83B7",
"brightBlack": "#767875",
"brightBlue": "#729FCF",
"brightCyan": "#34E2E2",
"brightGreen": "#8AE234",
"brightPurple": "#AD7FA8",
"brightRed": "#EF2929",
"brightWhite": "#EEEEEC",
"brightYellow": "#FCE94F",
"cursorColor": "#FFFFFF",
"cyan": "#06989A",
"foreground": "#FFFFFF",
"green": "#4E9A06",
"name": "VSCode WSL",
"purple": "#907295",
"red": "#DB4646",
"selectionBackground": "#F0F0F0",
"white": "#CCCCCC",
"yellow": "#C4A000"
},
{
"background": "#000000",
"black": "#000000",
"blue": "#000080",
"brightBlack": "#808080",
"brightBlue": "#0000FF",
"brightCyan": "#00FFFF",
"brightGreen": "#00FF00",
"brightPurple": "#FF00FF",
"brightRed": "#FF0000",
"brightWhite": "#FFFFFF",
"brightYellow": "#FFFF00",
"cursorColor": "#FFFFFF",
"cyan": "#008080",
"foreground": "#C0C0C0",
"green": "#008000",
"name": "Vintage",
"purple": "#800080",
"red": "#800000",
"selectionBackground": "#FFFFFF",
"white": "#C0C0C0",
"yellow": "#808000"
}
],
"themes": []
}
For what it's worth, I tried a bunch of other terminal apps and all of them are struggling more or less. So maybe it's just VS Code terminal that just better in this particular case and this shouldn't be a bug report but a feature request?
We're never going to get anything like what VS Code is doing without a significantly different color adjustment algorithm. Look at the green, yellow, and cyan backgrounds. The foreground colors have been adjusted to such an extent that they might as well all be black!
Also note that there are color combinations that are intended to be invisible, but in VS they are not. For example, if an application has output something in red on red, I expect it to be completely invisible, and not show up as bright white on red!
If we wanted to do something like this, it would probably mean we'd have to offer it as yet another color rendering option, because I don't see this has a replacement for the existing algorithm. At least the Delta E algorithm still keeps the foreground colors reasonably distinguishable.
I tend to agree. That's such an aggressive adjustment of the original colors, that it's hardly recognizable as the original scheme in the first place.
I think we've had discussions in the past on letting users configure the delta-E threshold for adjusting the colors, but I suspect that wouldn't create the magnitude of change here.
There's also been other discussions about having a "high-contrast mode", that very aggressively replaces the selected colors with ones that would be more legible. I forget how that works. That sounds like something you'd possible be more interested in. That's tracked in... #12999 / #3066.
I'll let @PankajBhojwani make the final call on this one
Maybe the answer is to give users a table of 162 color combinations and just let them tweak the values in whatever way they prefer.
We could also let people configure the minimum distance between the foreground and background color for a similar effect, but with almost no required code changes necessary. I personally don't think that letting users configure the visibility of text that has an identical foreground/background color is necessary, since it's intentionally invisible anyways.
Maybe the answer is to give users a table of 162 color combinations and just let them tweak the values in whatever way they prefer.
This is a good idea. But practice says that users customize the appearance of applications rather with the help of the applications themselves. The only exception is the color of the cursor, which cannot be set without changing the value in settings.json, because OSC 12 is overwritten.
I would be happy with tweakable 162 color combinations, :+1: to that.
Also note that there are color combinations that are intended to be invisible, but in VS they are not. For example, if an application has output something in red on red, I expect it to be completely invisible, and not show up as bright white on red!
What would be a use for such functionality? Spoiler tag? I think the app should use true color then and not rely on a terminal app rendering. But the same color being invisible on the same color is fine, maybe VS Code is wrong on that one, but if there is a difference, it should be readable IMO.
it should be readable IMO.
I don't know how to implement it. 16x16 colors in some combinations will be hard to read:
This can only be done with the help of AI, which will analyze the compatibility of colors that the user has determined.
Tried implementing a naive proof-of-concept adjustment logic with HTML and TypeScript (Demo). Results are meh, but if anyone wants to try their skills in it: the repo is here, fork away!
Then I've looked into how VS Code does the adjustment and updated the OP with my findings. Please, give it a look!
Triaged! Also, thanks @Igonato for providing such great resources and a bug report. This is great!
#15283 will change this to look like this:
VS Code from OP for reference:
The black ●●● that randomly occur are a side effect from me cutting some corners. To be honest, I don't wish to adopt the approach VS Code has implemented. It doesn't understand that two colors of equal luminance, but vastly different chroma are easily distinguishable. This makes implement cursors with their algorithm a bit bothersome, but I want to use the same algorithm for this exact issue as well.
An inverted cursor on top of a #ff0000 red background in VS Code would look like this for instance:
This is how my approach handles it:
The example is a little contrived, but there's many more color combinations that would produce the same issue. It makes my cursors look a little "inconsistent". Color contrasting with Oklab is more expensive but works about as well. [^1] It can be made much cheaper with SIMD, which I'll do in a future PR.
[^1]: Relatively speaking. Even the non-SIMD variant is already faster than xterm.js' approach for sure, as I don't rely on powf or any other complex mathematical function in the fast path.
Note to future us: this line
https://github.com/microsoft/terminal/blob/1477c0d8bdfbc462d74038e411061c57fd262357/src/renderer/base/RenderSettings.cpp#L185
sets the delta for the contrast ratio. That's what we'd want to affect if we did want to add a knob for this setting. x-ref #3066, #12999
Note (lhecker): The value is a squared number because the parameter is the squared minimum distance. This is for performance reasons as it avoids a square root in the hot path.
I haven't found the place where background colors are adjusted (they are clearly darkened a bit).
I don't think vscode changes the background colors.
Some notes from my experience building the feature:
- You will get reports about pwsh colors not working, a lot of these were fixed by retaining the hue when moving luminance in the opposite direction which wasn't done initially. I also have a FAQ on the website to explain the issue which links to the design discussion as it's a common question
- We plan on applying 50% of the minimum contrast for the dim/faint flag, otherwise you may not be able to distinguish them from regular text https://github.com/xtermjs/xterm.js/issues/4262
- Faster is always good, but performance isn't particularly important here if you use a cache where the key is bg+fg and the value is the contrast color.
- xterm.js handles selection just like a regular background color, so the contrast automatically applies there as well
Could this feature be implemented to allow users to customize their contrast ratio/delta E? I've been encountering this issue lately.
My concern
What I'm aiming for is an easy way to obtain a comfortable foreground color from basic colors (e.g., #0000ff, #00000), thus preventing the need for fine-tuning each color individually. While the current results are satisfactory, I desire more personalized colors. However, achieving this currently requires modifying the source code and rebuilding the app or adjusting colors individually using a palette, which leads to a poor user experience.
For instance, current approach adjusts #990000 to #fa6c5b on #1e1e1e, resulting in a lighter color than my desire. VSCode, for example, changes the color to #ef5959, which is more visually appealing, and I could change the minimum contrast ratio to further enhance comfort.
My thoughts about the discussion
Developers think the invisible text should reamain invisible, but I think that should be decided by users. Even a program outputs invisible text (e.g. red on red), the text still exists, and some users may wish to see it.
Moreover, I fail to grasp why the current algorithm fg = ColorFix::GetPerceivableColor(fg, bg, 0.5f * 0.5f); relies on a hardcoded value 0.5f * 0.5f, which is considered bad programming practice, rather than making it configurable.
My user experience about color adjustment
Additionally, a notable terminal emulator for color adjustments I've used is Terminal.app on macOS, although it doesn't employ a minimum contrast ratio (the algorithm remains undisclosed).
On Terminal.app, with #1e1e1e background, #990000 appears as #d6492c, and #0000b2 is displayed as #6a42f6 (#4788ff on terminal and #7979ff on VSCode), which is more comfortable for me despite #6a42f6 on #1e1e1e falling below the WCAG 2.1 standard (3.0) for contrast ratio.
My hopes for future improvements
I hope the future version of terminal can:
- Implement features similar to color rendering on macOS.
- Alternatively, allow users to configure the minimum contrast ratio akin to VSCode (per-color configuration is preferable).
- Or allow adjustment of the delta E magic number (0.5f * 0.5f).
These expectations are for sparing users the hassle of modifying source code or individual colors.
Moreover, I fail to grasp why the current algorithm
I appreciate your insight on this feature request and that you've provided comparable terminal emulators. Thanks! However, this sort of language--while it's phrased as something you're doing or not doing--typically implies some incredulity that the person you're talking to or about would so audaciously miss something "obvious".
The incremental cost of adding and maintaining in perpetuity a new setting to control the delta-E coefficient was deemed higher than the benefit of shipping it as-was. That's all. This team generally operates under the principle of shipping the minimum viable thing to validate the need for a feature and open up avenues for exploration in the future. 🙂
I think we're leaning towards a configurable minimum contrast ratio, rather than exposing the dE coefficient directly to user control. That would allow us to switch up the nudging algorithm in the background if one were proven to be better/faster/generate less code/etc. without tying user settings to our specific implementation details.
The incremental cost of adding and maintaining in perpetuity a new setting to control the delta-E coefficient was deemed higher than the benefit of shipping it as-was. That's all. This team generally operates under the principle of shipping the minimum viable thing to validate the need for a feature and open up avenues for exploration in the future. 🙂
Thank you for the reply! I am a non-native speaker and there may be potential for misinterpretation in my expression. I do understand that developers may have their concerns regarding software maintenance and reasons about settings exposing.
In my perspective, offering detailed configurations and accessibility of features in an application oriented towards programmers can enhance its usability, even if it might lead to unforeseen issues.
Users who possess knowledge of how to configure these features can leverage the advantages of them and consider minor issues as acceptable. Conversely, those unfamiliar with the usage are likely to keep default settings.
Additionally, configuration in string format within a file suffices. This approach has no big impact on performance and memory usage, yet enables the program to extract specific parameters from it.
At least this approach allows me to avoid time-consuming tasks such as online searches, source code modifications and a rebuilt process. 😂
I eagerly anticipate future versions that incorporate a configurable minimum contrast ratio!
Just chiming in here to say that I found a need to be able to set a static contrast ratio.
The “Automatically adjust lightness of indistinguishable text” setting seems to perform a dynamic contrast adjustment that can overcompensate and neuter the visibility of multicolored terminal output such as progress bars (as noted in #18617).
There’s a good reason why TVs and monitors let users adjust parameters like brightness, color, contrast, sharpness, and tint with sliders and presets. Color perception is subjective and there is further variability added by the software and hardware due to differences in content and manufacturing. Similarly, there is a complex interplay between CLI programs, interpreters, terminals, OSes, and monitors that makes manual calibration essential.
Refactoring the automatic contrast setting to a user-adjustable float would let users fine-tune the contrast to their needs. W3C accessibility guidelines suggests a minimum of 4.5, which would be a sane default.
