True (24-bit) color

[HalosGhost]

Is there any chance of libsixel supporting true color (i.e., 24-bit color) in the future? If it managed to get this feature, we could have incredibly high-quality images on-terminal.

I know this might be a significant undertaking, but it would be incredible if it happened!

[saitoha]

@HalosGhost SIXEL format supports RGB or HLS color format. but these resolution are less than 24bit.
RGB: 100 * 100 * 100 = 1,000,000 colors
HLS: 100 * 100 * 360 = 3,600,000 colors
(see ftp://ftp.cs.utk.edu/pub/shuford/terminal/all_about_sixels.txt)

In addition, most terminal implementations can not represent colors more than its number of color registers (up to 256).
Only mlterm and RLogin don't have this restriction. They accept up to 3,600,000 colors in principle.
For above 2 terminals, img2sixel command provides -I (--high-color) option.
It can represent 15bit color.
Isn't it enough for you?

[HalosGhost]

Actually, if I understand correctly, a variety of TEs these days support 24-bit true color.

The --high-color option looks great and I still need to experiment with it more; but, the notion of having perfect color reproduction supported is an attractive one (imho).

[saitoha]

SIXEL is a palette-based imaging format. So Its colors should be up to about 256 colors from the viewpoint of efficiency.
I also know 24-bit true color SGR feature (Konsole's 3-byte color mode) well because I am also an maintainer of some terminal emulators.
For my opinion on this, see here.
http://lists.suckless.org/dev/1410/23938.html

[crocket]

Yo, st and alacritty support true colors.

[meh]

@crocket sixels are unrelated to 24-bit SGR, I think I talked to @saitoha about an extension for 24-bit sixels that my terminal emulator supports, but then I didn't care enough to push it.

[ghost]

I am interested in adding a "mostly" true-color RGB option for the existing sixel encoding in my windowing library. Looking at the manual on sixel, it doesn't look too promising. But I'm wondering how this scheme would work for terminals vs real hardware:

1. Encode up to palette-size pixels as color + pixel.
2. When out of palette entries, start re-using color registers.

I expect real hardware would produce garbage on screen, with whatever the last register color set being used for every instance of that color register being used (and those colors possibly impacting all sixel images on screen, not just the last one sent). Or possibly not displaying an image at all, if registers are allowed to be set only once.

But for terminals (e.g. Xterm), they might not care that registers are being repeated.

The other question is the RGB/HSL parsing: is it generic enough in real hardware to accept additional parameters? If this was sent to real hardware, would any pixels come out? "#1;1;100;100;100;100#1ttt" If so, then one could append alpha to RGB/HSL and still have graceful fallback to opaque. EDIT: I just tried this against xterm, and the result is that no pixels come out. So RGBA is out for sixel.

[crocket]

RGBA is 32bit, not 24bit.