Searched hist:"2610 c9f2b2449c968304f48bf73d1eef2f4be558" (Results 1 – 3 of 3) sorted by relevance
/freebsd/sys/teken/libteken/ |
H A D | teken.3 | diff 2610c9f2b2449c968304f48bf73d1eef2f4be558 Thu Mar 16 17:40:54 CET 2017 Bruce Evans <bde@FreeBSD.org> 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.
|
/freebsd/sys/teken/ |
H A D | teken.h | diff 2610c9f2b2449c968304f48bf73d1eef2f4be558 Thu Mar 16 17:40:54 CET 2017 Bruce Evans <bde@FreeBSD.org> 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.
|
H A D | teken.c | diff 2610c9f2b2449c968304f48bf73d1eef2f4be558 Thu Mar 16 17:40:54 CET 2017 Bruce Evans <bde@FreeBSD.org> 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.
|