Refine customization around text color adjustment #19475

@237dmitry commented on GitHub (Mar 2, 2023):

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.

@237dmitry commented on GitHub (Mar 2, 2023): > 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.

claunia commented

@Igonato commented on GitHub (Mar 2, 2023):

I would be happy with tweakable 162 color combinations, 👍 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.

@Igonato commented on GitHub (Mar 2, 2023): 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.

claunia commented

@237dmitry commented on GitHub (Mar 3, 2023):

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.

@237dmitry commented on GitHub (Mar 3, 2023): > it should be readable IMO. I don't know how to implement it. 16x16 colors in some combinations will be hard to read: ![ArcoLinux_2023-03-03_12-12-49](https://user-images.githubusercontent.com/78153320/222680176-014cf889-171c-4a9c-8ce0-2218db41597a.png) _This can only be done with the help of AI, which will analyze the compatibility of colors that the user has determined._

claunia commented

@Igonato commented on GitHub (Mar 6, 2023):

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!

@Igonato commented on GitHub (Mar 6, 2023): Tried implementing a naive proof-of-concept adjustment logic with HTML and TypeScript ([Demo](https://igonato.github.io/terminal-colors-adjustment-poc/)). Results are meh, but if anyone wants to try their skills in it: [the repo is here](https://github.com/Igonato/terminal-colors-adjustment-poc), 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!

claunia commented

@carlos-zamora commented on GitHub (Mar 8, 2023):

Triaged! Also, thanks @Igonato for providing such great resources and a bug report. This is great!

@carlos-zamora commented on GitHub (Mar 8, 2023): Triaged! Also, thanks @Igonato for providing such great resources and a bug report. This is great!

claunia commented

@lhecker commented on GitHub (May 3, 2023):

#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. ¹ It can be made much cheaper with SIMD, which I'll do in a future PR.

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. ↩︎

@lhecker commented on GitHub (May 3, 2023): #15283 will change this to look like this: ![image](https://user-images.githubusercontent.com/2256941/236027514-3ff2e409-91e8-4734-b268-46dd28d3a970.png) VS Code from OP for reference: ![image](https://user-images.githubusercontent.com/788609/222312982-0c6619f8-5e51-4459-ad36-19bd6a5967f6.png) 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: ![image](https://user-images.githubusercontent.com/2256941/236032609-c15ed320-2498-4811-86f4-96c374b24ec6.png) This is how my approach handles it: ![image](https://user-images.githubusercontent.com/2256941/236032884-fa490b95-eb02-4906-851b-877db719ceec.png) 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.

claunia commented

1477c0d8bd/src/renderer/base/RenderSettings.cpp (L185)

@zadjii-msft commented on GitHub (May 4, 2023):

Note to future us: this line

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.

@zadjii-msft commented on GitHub (May 4, 2023): 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.

claunia commented

@Tyriar commented on GitHub (May 30, 2023):

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

@Tyriar commented on GitHub (May 30, 2023): > 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](https://code.visualstudio.com/docs/terminal/appearance#_why-are-the-colors-in-the-terminal-not-correct) 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 ![image](https://github.com/microsoft/terminal/assets/2193314/d9c5a560-08a3-47c0-9af8-48d5fb296552)

claunia commented

@universetraveller commented on GitHub (Jun 10, 2024):

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.

@universetraveller commented on GitHub (Jun 10, 2024): 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.

claunia commented

@DHowett commented on GitHub (Jun 10, 2024):

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.

@DHowett commented on GitHub (Jun 10, 2024): > 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.

claunia commented

@universetraveller commented on GitHub (Jun 10, 2024):

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!

@universetraveller commented on GitHub (Jun 10, 2024): > 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!

claunia commented