[noergl]

Imho there is some misconseption here, how the sixel protocol works for the colors part. It is not about any bit-depth of an image, as it is paletted. But other than most standard paletted formats, it can redefine its colors on-the-fly, which basically makes it supporting an infinite amount colors (it is still limited to 101³ colors in RGB space).

Now the actually tricky parts: The spec states (DEC STD 070), that the palette should be of size 256 at least on decoder side, and an encoder should not create more than 256 colors, and any higher palette index gets mapped back (not specced out, but mostly done with modulo). Older devices (old DEC printers or VTs) were even more limited in palette regards, from monochrome like VT240 to 16 colors on a VT340 for screen output. Thats what xterm does with `-ti 340` and it is totally right about it - it emulates what a VT340 was capable to do. What mlterm started to do (and others followed) - well it did not care for strict VT340 emulation, and increased the palette to 256 colors. Furthermore it applied "printer-behavior" (note - sixel was developed as printer protocol) deviating from DECs VT behavior by immediately applying colors to pixels. While DEC's sixel capable VTs always were bound to the fixed palette. That terminal vs printer behavior distinction is important, as it opens sixel to actually use more colors than the palette has room for by redefining color slots on the fly.

Hope this helps to get some details straight.

[speeddemon]

I figured something like that was the case, thank you for the explanation. Still that seems like a bad hack that terminals are not going to implement because it goes off-spec. It seems as if iTerm or kitty protocols (or anything else designed for a real screen and not a printer) would be a much better choice for a terminal trying to choose.

[noergl]

Well it is not that bad, imho all newer terminal implementations, that dont try to strictly emulate a VT340, do sixel this way. libsixel even propagates this as "highcolor". But again, sixel is still limited to ~1M colors in RGB and ~3M colors in HSL, even with that implementation trick.

The sixel format has much bigger issues beside its reduced color resolution - no alpha channel, need for really expensive quantization and printer head movements serialization, with bad cache locality due to its 6-pixel offset in y direction. Its compression is lousy. All that said, encoding/decoding sixels is a mainly CPU-bound resource hungry task with high bandwidth needs - all for worse quality compared to modern formats. With modern hardware, where beefy GPUs exist, it is really a shame to insist on using this format (which was effectively dead for >20ys).

On terminal side there are more issues about sixels and how they relate to cursor advance and the terminal grid, but going into these details will only bore ppl in a rant thread.