4 ms·

> 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

by _kst_ 2y ago

> 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 https://en.wikipedia.org/wiki/Sixel No, there's no video support (unless I've missed something).

its-summertime 2y ago
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 2y ago
  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-graphics-protocol https://sw.kovidgoyal.net/kitty/graphics-protocol/#terminal-... [1a] https://sw.kovidgoyal.net/kitty/graphics-protocol/#controlling-displayed-image-layout 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/874e28f4a41a916bb567a882063dd2589e9234e1#diff-e4884a311f1d61878e2a10df788482908cbd3b5a705410f897b1b1c05c51de58R75-R76 https://github.com/mpv-player/mpv/commit/874e28f4a41a916bb56... [2] https://sw.kovidgoyal.net/kitty/graphics-protocol/#controlling-animations 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 https://github.com/michaeljclark/glkitty [6] https://github.com/chase/awrit https://github.com/chase/awrit [7] Which I imagine DEC is turning in its grave about. :)
  - kragen 2y ago
    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

by _kst_ 2y ago

its-summertime 2y ago

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 2y ago
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-graphics-protocol https://sw.kovidgoyal.net/kitty/graphics-protocol/#terminal-... [1a] https://sw.kovidgoyal.net/kitty/graphics-protocol/#controlling-displayed-image-layout 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/874e28f4a41a916bb567a882063dd2589e9234e1#diff-e4884a311f1d61878e2a10df788482908cbd3b5a705410f897b1b1c05c51de58R75-R76 https://github.com/mpv-player/mpv/commit/874e28f4a41a916bb56... [2] https://sw.kovidgoyal.net/kitty/graphics-protocol/#controlling-animations 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 https://github.com/michaeljclark/glkitty [6] https://github.com/chase/awrit https://github.com/chase/awrit [7] Which I imagine DEC is turning in its grave about. :)
- kragen 2y ago
  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