It's okay for low-color/solid-run images, terrible for everything else. Nachman's image mime blobs (iTerm2 style) is the superior approach. mintty/mlterm/rlogin/wezterm already support it. Kitty has an (incompatible) variant--same idea, but delivered in chunks.
> when when run chat programs inside electron apps, does it really matters?
From a dev perspective, it's a lot easier to base64 an image you already have, with a base64 that's already in your stdlibs, than to scour github for a passable sixel library to pre-rasterize that jpeg & reformat it as sixel. I say this as someone who's written a sixel conversion library.
> competing formats
It's not a very old format, yet already supported on 4-5 terminals last I checked.
Or you could just use the libsixel package. Downloading libraries isn't unknown to developers (thinking about `apt-get install libncurses5-dev libsixel-dev` or the like.) Or sysadmins: `apt-get install libncurses5` or `apt-get install libsixel`.
I do everything I can to help popularize sixels - it could be a default fallback format: sixel-tmux could "rewrite" on the fly sixel sequences into kitty iterm2 or whatever
Sixels are compatible with cursor positioning escape sequences, so I can position the image on the screen. I wasn't able to do this with term2. Very possible I just didn't see how to do it though. If you have a pointer to docs for making that work, I'd love to play around with it.
Last time I evaluated this, sixel & base64 image placement relative to re-positioned cursor had slightly different behaviors across different implementations. I think the only one with well-defined placement/dimensions behavior was the Kitty format--which is unfortunately Kitty-only.
If the goal is to hot-patch graphics into existing TUIs, Kovid is probably on the right track with this. It needs to be something richer than what sixel or iTerm2 provide--with pixel placement, play/pause, scaling, etc. Though for a do-over of piping a UI over a (relatively) low-bandwidth wire, I think something like Sun NeWS would have been a simpler & more feature-complete approach.
Been using Wezterm for about a year now and I'm a very satisfied user. Beats any others I've ever used - iTerm2 comes close but it's Mac only. Every other terminal emulator in my experience has been problematic. Wezterm has not been. Just works.
Yeah, I don't see the point in trying to resurrect a dead standard that isn't very efficient or widely supported. Backwards compatibility is important, but sixels aren't even that well supported nowadays†, so there's not much to be compatible with. Better to just push for new de facto standards for images in the terminal; trying to resurrect sixels is an exercise in retrocomputing.
† xterm and iTerm2 are the only widely-used terminal emulators nowadays that support sixels. Few Linux users use plain old xterm nowadays due to lack of desktop integration, and iTerm2 is not the OS default terminal (and it supports a better image format anyway). Also note that no popular Windows terminal emulators (conhost.exe, conemu, Microsoft Terminal) support sixels at all.
sixel works fine, and is better supported than a "new de facto standard" the doesn't even exist yet. It's not at all true that no popular windows s/w supports it - mintty/wsltty supports it just fine and is widely used.
