True Colour support in various terminals
gist.github.com
True Colour support in various terminals
1–10 of 28 posts
Re: True Colour support in various terminals
#2Serious question: will terminals ever support P3 color? Maybe that's too much to ask for?
https://webkit.org/blog/6682/improving-color-on-the-web/ https://webkit.org/blog-files/color-gamut/comparison.html
Re: True Colour support in various terminals
#3Serious question: will terminals ever support P3 color? Maybe that's too much to ask for? https://webkit.org/blog/6682/improving-color-on-the-web/ https://webkit.org/blog-files/color-gamut/comparison.html
It only improves images, no?
Re: True Colour support in various terminals
#4Serious question: will terminals ever support P3 color? Maybe that's too much to ask for? https://webkit.org/blog/6682/improving-color-on-the-web/ https://webkit.org/blog-files/color-gamut/comparison.html
It only improves images, no?
It's a wider color space. It improves the color range of everything, assuming the source hasn't been flattened to SRGB.
Re: True Colour support in various terminals
#5Earlier quoted context omitted.
It only improves images, no?
It's a wider color space. It improves the color range of everything, assuming the source hasn't been flattened to SRGB.
Well, yes, but what are the benefits for text over 24-bit colour? To have two even less different shades of a colour adjacent to each other? For images there's a very clear benefit, but for a text frame buffer I'd say not so much.
Re: True Colour support in various terminals
#6Sad infodrop: the main reason this is a nonevent is because ncurses encodes fg/bg colors in an unsigned int. :(
Re: True Colour support in various terminals
#7What I think is really interesting in this is not the possibility to use 16 millions colors per se, but rather the ability to directly specify the RGB components of the color to use.
The current approach used by terminfo and ncurses is to refer to an index within a palette, which has the drawback of giving little guarantees about the final shade of the color. (Look at the color table here [1] for a comparison among different terminals; here it is stated that xterm changed the RGB components of two shades of blue from one version to another!)
Allowing true colors in terminals would make curses programming very similar to what you do in HTML and CSS, where you directly specify the color you want. It would surely be a nice improvement.
Re: True Colour support in various terminals
#8Here is an image printing function for bash/zsh:
function img { for image in "$@"; do convert -thumbnail $(tput cols) "$image" txt:- | awk -F '[)(,]' '!/^#/{gsub(/ /,"");printf"\033[48;2;"$8";"$9";"$10"m "}'; echo -e "\e[0;0m"; done ;}
Re: True Colour support in various terminals
#9I use this fairly often, when working on the image parts of our API (image caching, map tiles etc).
I tweaked the "img" script linked from the article to download and display an image, so I don't need to leave the terminal.
img http://sipi.usc.edu/database/preview/misc/4.2.03.png
Re: True Colour support in various terminals
#10Here is an image printing function for bash/zsh: function img { for image in "$@"; do convert -thumbnail $(tput cols) "$image" txt:- | awk -F '[)(,]' '!/^#/{gsub(/ /,"");printf"\033[48;2;"$8";"$9";"$10"m "}'; echo -e "\e[0;0m"; done ;} Example: http://i.imgur.com/d5RzWAC.png
I think yours has stretched the image vertically, though it is simpler than the one linked in the article [1]. That uses "Upper Half Block" characters to give square pixels, and sets a foreground and background colour -- doing two rows at once.
With that, I see this: http://i.imgur.com/uqCHAmF.png
[1] https://git.gnome.org/browse/vte/tree/perf/img.sh?h=vte-0-36