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.

> terrible for everything else

Define terrible. Wasteful, yes. But when we run chat programs inside electron apps, does it really matters?

> is the superior approach

My idea of superiority is linked to availability and support. Multiple competing formats are often a problem

> Kitty has an (incompatible) variant

Indeed, the multiple competing formats might each have some specific technical advantages, but networks effect makes your life harder.

> 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`.

&& find out how to get it on OSes that aren't debian-based

&& find a decent FFI wrapper if my app isn't in C-land

&& read the docs

&& static link hassles so I don't have to sort-out dynamic-link hassles for every platform

|| round-up a collection of dynamic libsixel libs & figure out how to bundle them with my script if I'm not using a compile-to-machine-code language

vs

   b64 := base64.Encode(myImg)
   fmt.Printf("\x1b]1337;inline=1;size=%d:%s\n", len(b64), b64)

If it's a feature request where I'm really only handling it to shut a few people up, which route am I going to take?

> Indeed, the multiple competing formats might each have some specific technical advantages, but networks effect makes your life harder.

Any hope for standardization?

> Any hope for standardization?

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.

https://sw.kovidgoyal.net/kitty/graphics-protocol/

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.

wezterm supports the kitty image protocol (as well as sixel and iterm2), and runs on all major platforms.

(disclaimer: I'm the wezterm guy)

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.

a mighty fine terminal sir

Thanks, will try this. Wish xterm was on the list, but mlterm is OK.

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.

The idea here is you can get graphics via a ssh connection. You don't need to setup a web interface to collect and process metrics.

It's useful cause you don't have to take your fingers off the keyboard to get graphical information.

And yeah. I would be just as happy to use NAPLPS, but Sixel support is what we have.

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.

No, a better standard does exist: https://iterm2.com/documentation-images.html

In fact, mintty already supports it. Only xterm doesn't. Sixel really is just retrocomputing at this point.

Xterm integrates perfectly in fvwm. And it does not need GB of RAM to render text.