[georgia_peach]

Sixel is kind of a mess. Many of the newer terminals (kitty, mintty, wezterm, iterm2, et. al) have a special escape for directly sending a base64-encoded gif/png/jpeg to the terminal for rendering. More colors & more efficient.

[cogburnd02]

The main advantage of sixel is probably the fact that it’s directly backward compatible with old DEC hardware, which I happen to like to use. I could have, say, a pdf reader that renders the pdf to the screen of an actual hardware VT330 by using sixels.

[wolrah]

The question there would be, it has that advantage but at what cost?

I'm not incredibly familiar with sixels, but my basic understanding is that they're in a format that was convenient for use with dot matrix printers and were later adapted to terminal use with color support and such. This means that interacting with them is not going to be straightforward for developers familiar with any sort of modern graphics APIs on either the software or terminal ends.

If the main advantage is compatibility with old terminals that only really matter to a niche subset of retrocomputer enthusiasts I'd argue that any efforts to add graphics to the Linux terminal should be focused on a more modern design such as the base64-encoded images supported by a few terminals.

[georgia_peach]

Since the article & the comment were about framebuffer terminals, in those cases, the base64 approach is superior: full color, built-in compression, no need to pre-rasterize. For <= 16 simultaneous colors (like in the original DEC terminals) sixel is A-OK, and in certain cases, even preferable! But when I see people today dither images to 256 colors just to be able to excrete them to a soft terminal with sixel, I cringe.

Something like Ascii85 or basE91 would have been even better, but beggars can't be choosers.