[_kst_]

> emulating a vt340+ like xterm does gives you the first six of these, which is a big reason why people keep writing new programs for that platform, but totally flunks the last one; you can't even display text in a proportional font, much less a photo or a video

xterm supports sixel graphics.

"sixel" is an image file format; the ImageMagic "convert" command can convert other formats to it. Just cat a sixel file to stdout in an xterm and it's displayed in the window.

The implementation is not 100% solid (for example, there's a size limit), but it does work. And tmux can be build with sixel support, so you can display sixel images in tmux under xterm.

    convert foo.png sixel:-

or

    convert -geometry 600x600 large.png sixel:-

https://en.wikipedia.org/wiki/Sixel

No, there's no video support (unless I've missed something).

[its-summertime]

iterm's protocol can display gifs, could use a streaming method via that, Kitty's protocol supports manual animating, though I have a feel it wouldn't be able to do video.

mpv supports both sixel and kitty's method for doing video

[follower]

Based on my (limited) understanding of Kitty's image protocol[0] (a.k.a the "Terminal graphics protocol") video support could be potentially implemented via multiple approaches, including at least:

(1) Draw image repeatedly using the "don't move cursor" cursor movement policy[1a][1b].

(2) Draw image replacing an existing image with the same id.

(3) Use animation configured to use "loading mode"[2] ("in this mode when reaching the last frame, instead of looping, the terminal will wait for the arrival of more frames").

An actual terminal graphics/image protocol enables some IMO[3] pretty cool possibilities:

* A while back I implemented a proof-of-concept that displayed a simple interactive egui (a Rust immediate mode GUI project) GUI within WezTerm via the protocol.

* Later I discovered someone had gone as far as making a port[5] of the OpenGL gears demo to kitty terminal graphics protocol.

* And there's even a "full graphical web browser for Kitty terminal with mouse and keyboard support"[6][7].

---- footnotes ----

(Content advisory for links: Kitty terminal graphics protocol spec includes a sample image whose subject has requested that the image no longer be used for such purposes.)

[0] https://sw.kovidgoyal.net/kitty/graphics-protocol/#terminal-...

[1a] https://sw.kovidgoyal.net/kitty/graphics-protocol/#controlli...

[1b] This approach appears to be the method used by the mpv implementation: https://github.com/mpv-player/mpv/commit/874e28f4a41a916bb56...

[2] https://sw.kovidgoyal.net/kitty/graphics-protocol/#controlli...

[3] I'm aware that not everyone will think static or dynamic image display is something a terminal "should do" but to me it seems better to have actual image support in terminals rather than use (already currently used) existing "hacks" that provide a poor facsimile of support[4].

[4] Then again, I'm also of the opinion[4a] that perhaps terminals should support actual graphical UIs rather than the poor facsimile of them delivered by TUIs. *cough* :D

[4a] Motivated by the thought that at the current point in time perhaps the "essence" of a "terminal" is its linear "chronological" presentation of input/interaction/output history rather than its use of "text". (See also: "lab notebooks" & some tiling window manager features.)

[5] https://github.com/michaeljclark/glkitty

[6] https://github.com/chase/awrit

[7] Which I imagine DEC is turning in its grave about. :)

[kragen]

i think the kitty protocol is a great deal less detestable than sixel ;)

it's unfortunate that it's still only six bits per byte, but at least it supports png and 24-bit color