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