support for 24bit color
cage2 opened this issue · 6 comments
Hi McParen,
i would like to use the 24bit RGB color on my application but i think the library coerce the 8 bit color to 6 bit color even if the terminal support color specified as 8 bit per channel.
I wonder if checking if a terminal support 24bit color and bypass the conversion 8bit to 6bit could suffice.
I have found this document to checks if a terminal support 24bit colors
https://gist.github.com/XVilka/8346728#true-color-detection
it is not perfect but should not give false positive, at least.
What do you think?
Bye!
C.
Hello,
ncurses does as far as I know not limit the depth of single colors that can be used. You can address any 24bit color by redefining colors in the standard 256color palette.
What ncurses does not allow is passing the RGB components directly, as can be done with the ansi escape sequences 38;2;R;G;Bm and 48;2;R;G;Bm on some terminals. You still have to use the "color numbers", but since ncurses 6.1 4byte int can be used for colors and color pairs (allowing for millions of simultaneously used) instead of signed short which was the default till ncurses 6.1, where you were limited to at max 32768 color pairs.
So if you do not need the 16 millions colors at the same time, the extended colors interface sounds sufficient.
Edit: the extended functions are not yet part of the high-level interface, you have to access the ncurses wrappers directly.
You do not have to use attron and other low-level color routines to actually use and display the colors, just to redefine the color numbers in the standard palette. After the individual colors are redefined, you use them just as you would use the predefined colors, i.e. you can use the high level interface for that.
In the high level interface, the palette color numbers can be passed as a name like :black or as a list list (:number 0) to directly pass its color number, see for example the test t20c.
Since the first 8 (or 16 in the 265 color mode) colors are named, it makes no sense to redefine them, because at the moment the names cant be easily reassigned, but the colors above that can be redefined as needed.
In the long run, I want to be able to pass any color as simply as giving its hex code, either as a string "#FF0000" or as a lisp integer #xff0000, but I've yet to work on that.
Edit: My bad, thats how it would work if you do not use the extended interface. If you do want to use more color numbers than the conventional short int interface supports, you need to use the new extended functions directly, and that means using attr_on instead of attron
int attron(int attrs);
int attr_on(attr_t attrs, void *opts);
then passing the extended color nomber to the opts pointer instead of the attrs attribute.
It is a mess, but I havent found the time yet to work on wrapping it in a more pleasent API in Lisp.
Hello, I had to edit my previous comment. To some degree, you are right, but as long as you can limit yourself to roughly 16000 colors that fit into a signed short int, you dont have to use the extended functions.