3

I'm trying to understand exactly how colors are processed in my terminal emulator (iTerm2).

In iTerm2 I can configure my "base 16" color palette - in iTerm2 this is done using HSL, not 16-bit RGB values. The colors defined this way are native - they use the cocoa API and are not limited to the typical 256 color palette (they are rendered in true color).

X11'srgb.txt defines names for the colors in the 256 color palette.

In a shell, bash or zsh, I can print text using the 16bit 256 color palette with echo -e "\e[38;5;82mHello \e[38;5;198mWorld" (the third parameter is the xterm color code)

In vim (terminal not gui) the colors are utilized as a 'cterm' value when defining highlights (for example: :highlight Normal ctermfg=188 ctermbg=233 guifg=#e8e8d3 guibg=#151515), however as far as I can tell - there is no way to define a terminal color using an RGB code, so while I can display the base16 colors in truecolor, the rest of the colors are arbitrarily limited to the 256 color palette.

What I haven't been able to figure out is where rgb values are mapped to the xterm codes. It appears to be an arbitrary relationship (the xterm codes don't appear to have a functional relationship with the RGB values), so I assume there must be a mapping somewhere.

I believe that the colors can be redefined in .Xresources (here is an example), but I'm unsure about a couple things:

  1. .Xresources is specific to the xterm terminal emulator, and I'm using iTerm2, so (I believe) that this is irrelevant in my case. I've mucked around and iTerm2 doesn't seem to respect the .Xresources configuration. I was unable to find more documentation on this subject.
  2. I've read that xterm will approximate color definitions from .Xresources that are outside of the web-safe palette - I'm not sure if this is true or exactly how it's done, but I imagine that this is a historical limitation associated with the amount of bits being used to store the colors.

So at this point I believe way it works is:

  1. Terminal applications emit the xterm-compatible escape code sequence - and colors are always defined as an xterm color code (0-255).
  2. iTerm2 detects the escape sequence.
  3. iTerm2 uses an internal mapping that respects X11's rgb.txt to map the xterm color code to an HSL value.
  4. iTerm2 renders color using the cocoa API.

So, no other applications (X11 or anything else) are involved in the color mapping or conversion - it's straight from the terminal application to the terminal emulator.

This being the case, since iTerm2 only allows user to configure the "base 16 colors" users are free to use true color when rendering those only, but restricted to the web-safe palette for all other colors.

Is this correct?

nfarrar
  • 2,291
  • 4
  • 25
  • 33

1 Answers1

3

The default xterm palette is standard and expected to be the same in every xterm implementation. It is different from the more or less standard rgb.txt that is only used by GUI programs.

The first 16 colors, 0-15, have more or less standard names, "red", "darkgreen", etc. but all the others can only be referred to by their number, from 16 to 255.

The first 16 colors can usually be defined by the user (using CMYK, HSL, RGB or hexadecimal notation, it doesn't matter) so using "red" or "2" in a colorscheme is pretty much a shot in the dark as there's no guarantee whatsoever that "red" will actually be red. Solarized is an horrible example where the color traditionally referred to as "bright green" is actually a dark grey.

Most "modern" terminal emulators let you define those 16 colors with a GUI but other more "old school" emulators like xterm or rxvt use ~/.Xresources. That file is completely ignored by iTerm so you shouldn't waste your time on it.

It is possible to change the xterm palette but few people know about that which makes this practice very uncommon.

So…

  • terminal emulators don't use rgb.txt,
  • colors 0-15 are user-configurable,
  • colors 16-255 are restricted to the color chart in the first link,
  • colors 16-255 can be changed but it is rare,
  • iTerm doesn't use .Xresources.
romainl
  • 186,200
  • 21
  • 280
  • 313
  • 1
    Actually, the color values do differ between terminal emulators (see xterm FAQ http://invisible-island.net/xterm/xterm.faq.html#dont_like_blue) – Thomas Dickey Apr 02 '15 at 10:55
  • Indeed, the default colors can be altered. In my short experience I've seen more (subtle) variations from one `rgb.txt` to another than from one 16-255 palette to another. – romainl Apr 02 '15 at 11:42
  • Some of xterm's default colors use RGB, some use named colors - generally the 0-15 which are user-configurable. `rxvt` and other plain-X11 applications have the same comment. Gtk-based applications likely do not use `rgb.txt`. Any of xterm's colors can be changed at runtime - some by more than one method. – Thomas Dickey Apr 02 '15 at 21:23
  • Yeah, that mess is precisely because I recommend restrain. – romainl Apr 02 '15 at 21:36
  • People's tastes differ (I limit my recommendations to cases where techniques work or do not). By the way, the colorcoke page which you linked to appears inaccurate regarding urxvt (it has been able to modify the 256-color palette for a while). – Thomas Dickey Apr 02 '15 at 23:15
  • Dead link - mirrored at https://upload.wikimedia.org/wikipedia/commons/1/15/Xterm_256color_chart.svg – John P Mar 16 '17 at 16:08
  • AFAIK, xterm is the only terminal for which you can redefine the palette by sending it control sequences. – Johan Boulé Apr 20 '19 at 18:34
  • The linked chars are faulty (`df` should be `d7`, and there might be other mistakes). See the source at https://invisible-island.net/xterm/#download, file `256colres.pl`, which contains the formula for the sequence of color values used in xterm for each of the R/G/B components: (0=`00`, 95=`5f`, 135=`87`, 175=`af`, 215=`d7`, 255=`ff`). – Felix Rabe May 01 '19 at 13:42
  • For a nice (and hopefully correct) list, see also https://github.com/jonasjacek/colors. – Felix Rabe May 01 '19 at 13:45
  • ... plus https://gist.github.com/MicahElliott/719710#gistcomment-1442838 for a few lines of code for (xterm-based) rgb conversion. (Caution: macOS Terminal at least seems to use very different colors even for its 216 "RGB" values!) – Felix Rabe May 01 '19 at 13:50
  • @FelixRabe, no Terminal.app uses the exact same "xterm" palette. – romainl May 13 '19 at 15:12
  • @romainl Not on my system it doesn't seem. Not only did they look weird, I screenshotted and checked them, next to a Firefox tab containing the xterm palette. They are different. – Felix Rabe May 19 '19 at 12:42
  • @FelixRabe, make sure your display and your eye dropper use the same baseline profile ("Generic RGB", for example). With everything set to "Generic RGB" I get the exact same measures everywhere: Terminal.app, MacVim.app, and the SVG in Firefox. Different apps may use an internal profile and thus interact differently with any other profile currently in use elsewhere and those interactions are only exacerbated when using screenshots which come with their own profiles and so on. This must be taken into account when discussing colors on computer displays. – romainl May 21 '19 at 07:17