256/16 million color support about ansi-styles

[jbnicolai]

Just a quick note (I'm traveling atm) that I did something similair a while back. You can probably find the discussion under chalk's issues and see my implementation here: https://github.com/jbnicolai/ansi-256-colors

[Qix-]

@jbnicolai I stole the RGB -> ANSI 256 formula from there 😉 This proposal does something a little more than just that, though. If you wanted to, we could beef up the ansi-256-colors repository to do the color-to-ANSI-code conversions and then let this library use that? Though ansi-256-colors is a bit of a misnomer since we'd also be supporting truecolor as well.

[jbnicolai]

Nah, I'm perfectly happy retiring that repository and beefing up the chalk/ansi-styles/supports-color stack, although I'm starting to think we should maybe move this set of repositories to their own organisation.

How would you feel about that, @sindresorhus?

[Qix-]

http://github.com/chalk seems inactive. Github is pretty good about releasing inactive accounts. http://github.com/chalkjs is also unclaimed.

EDIT: @jbnicolai don't forget ansi-regex and strip-ansi.

[jbnicolai]

@Qix- yeah, completely agree those should probably come with as well. It's @sindresorhus' call though :)

[Qix-]

👍

[Qix-]

I'm looking at the existing code for this repo. It's pretty basic. It'd be pretty much a complete re-write.

[Qix-]

I've started a bit of a re-write as it is. Any thoughts on this @sindresorhus?

[sindresorhus]

I used up all my time today moving everything over to the chalk org. Will get back to this in a couple of days when I have more time. Tweeted about getting feedback on this, so we can hopefully get some more eyes on it.

[Qix-]

Sounds good 👍

[sunesimonsen]

My package https://github.com/sunesimonsen/magicpen supports 256 with backwards compatibility with 16 color terminals. Maybe that could be a source of inspiration, the ansi serializer is here: https://github.com/sunesimonsen/magicpen/blob/master/lib/AnsiSerializer.js

[Qix-]

@sunesimonsen and what of 16m colors? @jbnicolai already had a module that did something very similar. This proposal does something completely different.

[sunesimonsen]

@Qix- we don't support that yet, but I'm curious to see what you come up with.

[Qix-]

@sunesimonsen as in the original post here, we'd be using/working with full RGB values and degrading into their lower forms (truecolor -> 256 -> 16 colors).

[Qix-]

x-post: chalk/chalk#73

[Qix-]

Also, another question is: where should everything go?

We have a few moving parts here:

• Level detection
• Color manipulation functionality (hue shifting, lightness adjustments, RGB <-> HSV/HSL conversions, etc.)
• Degradation from truecolor to 256/basic values
• The fact we want to be able to map these to basic colors (i.e. rgb(255, 0, 0) should map to 31 instead of 38;2;255;0;0)
• Listing above combinations (and applying labels to them)
• Styles (bold, italic, underline, inverse, etc.)
• The API for stringing them together

Some of the above are obvious (i.e. stringing them together would occur in chalk proper), but the others?

As well, this has the potential to introduce a major performance hit if not done correctly (color modifications aren't nearly as quick as lookups). Memoization will be important here.

I propose the following:

• Level Detection: supports-color
• Color Manipulation: ansi-styles / new module (see note below)
• Degradation: ansi-styles / new module (see note below)
• Color Mapping: ansi-styles
• Map Labels: ansi-styles
• Styles: ansi-styles
• API: chalk

---

Color manipulation (lightness, hue, etc.) was originally going to happen with color-js. However, upon actually looking at the code, it doesn't look very performant / memory conscious. The code is under the BSD clause 2, which means we can use the algorithms with attribution and build our own structure around it.

But that's all up to @sindresorhus.

[Qix-]

Oh I'm not done.

Another consideration: if we go from high->low resolution on colors, the 16 color palette is going to be tricky.

There are a few ways we can interpret RGB values for the 16 color palette.

By the math, regular colors should be 0..127 and bright colors should be 128..255, though that's not necessarily true on all VGA systems. Do we enforce this idea? People usually have them re-mapped anyway.

Surprisingly, Windows XP gets it the closest.

[sunesimonsen]

@Qix- I also use full RGB values and degrading them to the 256 and 16 color palette. I wanted 256 colors to work in terminals that supports 256 colors but can't be detected as such, so we wrap the 256 color escape sequence in a 16 color escape sequence. Old terminals will ignore the 256 color escape sequence and fallback to the 16 color escape sequence. It is a bit hacky, but it works.

[Qix-]

@sunesimonsen Ehh I feel like that's a workaround that will backfire on some terminals. Plus that craps up the terminal with more data than it needs - TTY operations are expensive as it is. Cool hack, though. Never really thought about that.

[sunesimonsen]

@Qix- I'm not saying you should copy that, I'm just telling you what I have done.

[jbnicolai]

@sunesimonsen that's pretty awesome actually 😄 - although I don't suggest we copy that here

[Qix-]

The fact is the color operations will be easy, it's the API that's troublesome.

[Qix-]

I've made a PR for color-convert for ansi16/256 color degradation algorithms.

Qix-/color-convert#18

[MoOx]

PR as been merged and released as [email protected].

[Qix-]

Thank you @MoOx :)