Add teken_256to16() to convert xterm-256 256-color codes to xterm 16-color

codes.  This will be used to fix bright colors.

Improve teken_256to8().  Use a lookup table instead of calculations.  The
calculations were inaccurate since they used indexes into the xterm-256
6x6x6 color map instead of actual xterm colors.  Also, change the threshold
for converting to a primary color: require the primary's component to be
2 or more higher instead of just higher.  This affects about 1/5 of the
table entries and gives uniformly distributed colors in the 6x6x6 submap
except for greys (35 entries each for red, green, blue, cyan, brown and
magenta, instead of approx. only 15 each for the mixed colors).  Even
more mixed colors would be better for matching colors, but uniform
distribution is best for preserving contrast.

For teken_256to16(), bright colors are just the ones with luminosity >=
60%.  These are actually light colors (more white instead of more
saturation), while xterm bright colors except for white itself are
actually saturated with no white, so have luminosity only 50%.

These functions are layering violations.  teken cannot do correct
conversions since it shouldn't know the color maps of anything except
xterm.  Translating through xterm-16 colors loses information.  This
gives bugs like xterm-256 near-brown -> xterm-16 red -> VGA red.
This commit is contained in:
bde 2017-03-16 16:40:54 +00:00
parent d61fb3f505
commit 4402e6b59b
3 changed files with 211 additions and 47 deletions

View File

@ -24,7 +24,7 @@
.\"
.\" $FreeBSD$
.\"
.Dd May 9, 2011
.Dd Mar 13, 2017
.Dt TEKEN 3
.Os
.Sh NAME
@ -57,6 +57,8 @@
.Ft const char *
.Fn teken_get_sequence "teken_t *t" "unsigned int id"
.Ft teken_color_t
.Fn teken_256to16 "teken_color_t color"
.Ft teken_color_t
.Fn teken_256to8 "teken_color_t color"
.Ft void
.Fn teken_get_defattr_cons25 "teken_t *t" "int *fg" "int *bg"
@ -163,10 +165,22 @@ This library also provides a set of functions that shouldn't be used in
any modern applications.
.Pp
The
.Fn teken_256to16
function converts an xterm-256 256-color code to an xterm 16-color code
whose color with default palettes is as similar as possible (not very
similar).
The lower 3 bits of the result are the ANSI color and the next lowest
bit is brightness.
Other layers (hardare and software) that only support 16 colors can use
this to avoid knowing the details of 256-color codes.
.Pp
The
.Fn teken_256to8
function converts a color code to one of the 8 primary colors, allowing
the terminal to be rendered on graphics hardware that only supports 8 or
16 colors (e.g. VGA).
function is similar to
.Fn teken_256to16
except it converts to an ANSI 8-color code.
This is more accurate than discarding the brigtness bit in the result of
.Fn teken_256to16 .
.Pp
The
.Fn teken_get_defattr_cons25

View File

@ -452,55 +452,203 @@ teken_state_numbers(teken_t *t, teken_char_t c)
return (0);
}
#define k TC_BLACK
#define b TC_BLUE
#define y TC_BROWN
#define c TC_CYAN
#define g TC_GREEN
#define m TC_MAGENTA
#define r TC_RED
#define w TC_WHITE
#define K (TC_BLACK | TC_LIGHT)
#define B (TC_BLUE | TC_LIGHT)
#define Y (TC_BROWN | TC_LIGHT)
#define C (TC_CYAN | TC_LIGHT)
#define G (TC_GREEN | TC_LIGHT)
#define M (TC_MAGENTA | TC_LIGHT)
#define R (TC_RED | TC_LIGHT)
#define W (TC_WHITE | TC_LIGHT)
/**
* The xterm-256 color map has steps of 0x28 (in the range 0-0xff), except
* for the first step which is 0x5f. Scale to the range 0-6 by dividing
* by 0x28 and rounding down. The range of 0-5 cannot represent the
* larger first step.
*
* This table is generated by the follow rules:
* - if all components are equal, the result is black for (0, 0, 0) and
* (2, 2, 2), else white; otherwise:
* - subtract the smallest component from all components
* - if this gives only one nonzero component, then that is the color
* - else if one component is 2 or more larger than the other nonzero one,
* then that component gives the color
* - else there are 2 nonzero components. The color is that of a small
* equal mixture of these components (cyan, yellow or magenta). E.g.,
* (0, 5, 6) (Turquoise2) is a much purer cyan than (0, 2, 3)
* (DeepSkyBlue4), but we map both to cyan since we can't represent
* delicate shades of either blue or cyan and blue would be worse.
* Here it is important that components of 1 never occur. Blue would
* be twice as large as green in (0, 1, 2).
*/
static const teken_color_t teken_256to8tab[] = {
/* xterm-16+ 8 dark colors: */
0, r, g, y, b, m, c, w,
/* xterm-16+ 8 light colors: */
0, R, G, Y, B, M, C, W,
/* Red0 submap. */
k, b, b, b, b, b,
g, c, c, b, b, b,
g, c, c, c, b, b,
g, g, c, c, c, b,
g, g, g, c, c, c,
g, g, g, g, c, c,
/* Red2 submap. */
r, m, m, b, b, b,
y, k, b, b, b, b,
y, g, c, c, b, b,
g, g, c, c, c, b,
g, g, g, c, c, c,
g, g, g, g, c, c,
/* Red3 submap. */
r, m, m, m, b, b,
y, r, m, m, b, b,
y, y, w, b, b, b,
y, y, g, c, c, b,
g, g, g, c, c, c,
g, g, g, g, c, c,
/* Red4 submap. */
r, r, m, m, m, b,
r, r, m, m, m, b,
y, y, r, m, m, b,
y, y, y, w, b, b,
y, y, y, g, c, c,
g, g, g, g, c, c,
/* Red5 submap. */
r, r, r, m, m, m,
r, r, r, m, m, m,
r, r, r, m, m, m,
y, y, y, r, m, m,
y, y, y, y, w, b,
y, y, y, y, g, c,
/* Red6 submap. */
r, r, r, r, m, m,
r, r, r, r, m, m,
r, r, r, r, m, m,
r, r, r, r, m, m,
y, y, y, y, r, m,
y, y, y, y, y, w,
/* Grey submap. */
k, k, k, k, k, k,
k, k, k, k, k, k,
w, w, w, w, w, w,
w, w, w, w, w, w,
};
/*
* This table is generated from the previous one by setting TC_LIGHT for
* entries whose luminosity in the xterm256 color map is 60% or larger.
* Thus the previous table is currently not really needed. It will be
* used for different fine tuning of the tables.
*/
static const teken_color_t teken_256to16tab[] = {
/* xterm-16+ 8 dark colors: */
0, r, g, y, b, m, c, w,
/* xterm-16+ 8 light colors: */
0, R, G, Y, B, M, C, W,
/* Red0 submap. */
k, b, b, b, b, b,
g, c, c, b, b, b,
g, c, c, c, b, b,
g, g, c, c, c, b,
g, g, g, c, c, c,
g, g, g, g, c, c,
/* Red2 submap. */
r, m, m, b, b, b,
y, K, b, b, B, B,
y, g, c, c, B, B,
g, g, c, c, C, B,
g, G, G, C, C, C,
g, G, G, G, C, C,
/* Red3 submap. */
r, m, m, m, b, b,
y, r, m, m, B, B,
y, y, w, B, B, B,
y, y, G, C, C, B,
g, G, G, C, C, C,
g, G, G, G, C, C,
/* Red4 submap. */
r, r, m, m, m, b,
r, r, m, m, M, B,
y, y, R, M, M, B,
y, y, Y, W, B, B,
y, Y, Y, G, C, C,
g, G, G, G, C, C,
/* Red5 submap. */
r, r, r, m, m, m,
r, R, R, M, M, M,
r, R, R, M, M, M,
y, Y, Y, R, M, M,
y, Y, Y, Y, W, B,
y, Y, Y, Y, G, C,
/* Red6 submap. */
r, r, r, r, m, m,
r, R, R, R, M, M,
r, R, R, R, M, M,
r, R, R, R, M, M,
y, Y, Y, Y, R, M,
y, Y, Y, Y, Y, W,
/* Grey submap. */
k, k, k, k, k, k,
K, K, K, K, K, K,
w, w, w, w, w, w,
W, W, W, W, W, W,
};
#undef k
#undef b
#undef y
#undef c
#undef g
#undef m
#undef r
#undef w
#undef K
#undef B
#undef Y
#undef C
#undef G
#undef M
#undef R
#undef W
teken_color_t
teken_256to8(teken_color_t c)
{
unsigned int r, g, b;
if (c < 16) {
/* Traditional color indices. */
return (c % 8);
} else if (c >= 244) {
/* Upper grayscale colors. */
return (TC_WHITE);
} else if (c >= 232) {
/* Lower grayscale colors. */
return (TC_BLACK);
}
return (teken_256to8tab[c % 256]);
}
/* Convert to RGB. */
c -= 16;
b = c % 6;
g = (c / 6) % 6;
r = c / 36;
teken_color_t
teken_256to16(teken_color_t c)
{
if (r < g) {
/* Possibly green. */
if (g < b)
return (TC_BLUE);
else if (g > b)
return (TC_GREEN);
else
return (TC_CYAN);
} else if (r > g) {
/* Possibly red. */
if (r < b)
return (TC_BLUE);
else if (r > b)
return (TC_RED);
else
return (TC_MAGENTA);
} else {
/* Possibly brown. */
if (g < b)
return (TC_BLUE);
else if (g > b)
return (TC_BROWN);
else if (r < 3)
return (TC_BLACK);
else
return (TC_WHITE);
}
return (teken_256to16tab[c % 256]);
}
static const char * const special_strings_cons25[] = {

View File

@ -56,6 +56,7 @@ typedef unsigned char teken_color_t;
#define TC_CYAN 6
#define TC_WHITE 7
#define TC_NCOLORS 8
#define TC_LIGHT 8 /* ORed with the others. */
typedef struct {
teken_unit_t tp_row;
@ -203,6 +204,7 @@ void teken_set_8bit(teken_t *);
void teken_set_cons25(teken_t *);
/* Color conversion. */
teken_color_t teken_256to16(teken_color_t);
teken_color_t teken_256to8(teken_color_t);
#endif /* !_TEKEN_H_ */