Console device is relabeling 24-bit SGR color values if they match a 16-color primary in the Windows color scheme. #7238

Closed
opened 2026-01-31 00:58:43 +00:00 by claunia · 2 comments
Owner

Originally created by @Undercat on GitHub (Apr 1, 2020).

Environment

Windows build number: 10.0.18363.0
Windows Terminal version (if applicable):

Any other software?

Steps to reproduce

Various example means of triggering are shown in issues libuv/libuv#2766 and mintty/mintty#981

Expected behavior

Truecolor ANSI SGR codes should never be relabeled as 16-color primary codes. Not all downstream consumers use colormaps that will render these values equivalently. (In fact, many environments have chosen markedly different RGB values for their SGR primaries.ref)

Actual behavior

All 24-bit SGR color sequences are remapped to shorter 16-color SGR primaries if the 24-bit RGB intensity values happen to match a primary’s RGB intensity values in the Windows color scheme.

For example, the value \e[48;2;118;118;118m gets relabeled \e[100m because the RGB intensities that Windows uses for "bright black" happen to match those given by the somewhat longer 24-bit ANSI string. But not all environments map "bright black" to the same 24-bit RGB intensity values; see screenshots in the mintty issue, referenced above.

Note: this applies to 8-bit SGR codes, too, if the canonical RGB values for the 8-bit color match what Windows has chosen for one of their primaries: \e[48;5;243m => \e[100m

Originally created by @Undercat on GitHub (Apr 1, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none Windows build number: 10.0.18363.0 Windows Terminal version (if applicable): Any other software? ``` # Steps to reproduce Various example means of triggering are shown in issues libuv/libuv#2766 and mintty/mintty#981 # Expected behavior Truecolor ANSI SGR codes should never be relabeled as 16-color primary codes. Not all downstream consumers use colormaps that will render these values equivalently. (In fact, many environments have chosen markedly different RGB values for their SGR primaries.<sup>[ref](https://en.wikipedia.org/wiki/ANSI_escape_code#3/4_bit)</sup>) # Actual behavior All 24-bit SGR color sequences are remapped to shorter 16-color SGR primaries if the 24-bit RGB intensity values happen to match a primary&rsquo;s RGB intensity values in the Windows color scheme. For example, the value `\e[48;2;118;118;118m` gets relabeled `\e[100m` because the RGB intensities that Windows uses for "bright black" happen to match those given by the somewhat longer 24-bit ANSI string. But not all environments map "bright black" to the same 24-bit RGB intensity values; see screenshots in the mintty issue, referenced above. Note: this applies to 8-bit SGR codes, too, if the canonical RGB values for the 8-bit color match what Windows has chosen for one of their primaries: `\e[48;5;243m => \e[100m`
claunia added the Resolution-Duplicate label 2026-01-31 00:58:43 +00:00
Author
Owner

@zadjii-msft commented on GitHub (Apr 1, 2020):

Thanks for the suggestion! This is actually already being tracked by another issue on our repo - please refer to #2661 for more discussion.

/dup #2661

@zadjii-msft commented on GitHub (Apr 1, 2020): Thanks for the suggestion! This is actually already being tracked by another issue on our repo - please refer to #2661 for more discussion. /dup #2661
Author
Owner

@ghost commented on GitHub (Apr 1, 2020):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Apr 1, 2020): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#7238