FFmpeg-SIXEL VS notcurses

Also:

https://github.com/saitoha/libsixel

contains img2sixel, which lets you dump images to the terminal. It can also do animated GIFs.

Video:

https://github.com/saitoha/FFmpeg-SIXEL

GUI apps:

https://github.com/saitoha/SDL1.2-SIXEL

and more, linked from the libsixel repository.

> I don’t see why sixels couldn’t work.

Sixels will work: they are fast enough to allow youtube video playback !!!

https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/README.md

But the problem is NOT THE FORMAT, the problem is the lack of tooling. links and w3m are among the rare text browsers that can display images in the console.

It's just a matter of the browser sending the image to something in some format, but if that hasn't be thought about as a possibility (say, for text reflow issues) it's going to be far more complicated than just adding a new format, as you will have to work both on say the text reflow issues (ex: how do you select the size of the placeholder, when expressed in characters?), and the picture display.

Personally, I do not care much about sixels, kitty or iterm format - all I want is to see some kind of support.

Yes, it would be better if that support was for the option that has the greatest chance of succeeding, but even that is a second concern: in the worst case, we can write transcoders to whatever format people prefer!

But when there is no "input" to transcode, you have a much bigger problem!

> an off the shelf ASCII plotting library probably involves less custom tooling

With a terminal like msys2 or xterm, no custom tooling is required: just use the regular gnuplot after doing the export for the desired resolution, font, and font size.

gnuplot is far more standard than plotting library that often require special Unicode fonts on top of requiring you to use their specific format.

> The only reason we don't have animation frameworks for the terminal is because it's not possible

https://nick-black.com/dankwiki/index.php/Notcurses

Notcurses. Install it and run notcurses-demo to be suitably impressed.

Same for me, I would be much more motivated if there was something like textual for Rust. Given the capability of terminal emulators now I think Rust is lacking behind in the TUI field. Just checkout what can be done with something like notcurses

On the application side of rendering, see notcurses, it is at the leading edge: https://github.com/dankamongmen/notcurses

Other TUI libraries of note: https://github.com/dankamongmen/notcurses/blob/master/doc/OT...

The broader world probably knows him best for the terminal handling library Notcurses[1] and a lot of telling terminal emulator authors to get their shit together.

I’ve had his grad-school project libtorque[2] (HotPar ’10), an event-handling and scheduling library, on my to-read list for years, but I can’t seem to figure out how it accomplishes the interesting things it does.

[1] https://nick-black.com/dankwiki/index.php/Notcurses, https://github.com/dankamongmen/notcurses/

[2] https://nick-black.com/dankwiki/index.php/Libtorque

In XTerm, this (rightly) makes no difference. In Foot and Contour however, you still end up a line resp. a screen below where you started, if now with the correct horizontal position.

So it seems to me like what you want should work by default, except it doesn’t.

It should be possible to instead just treat the whole thing as a graphical overlay (by computing or directly asking for the character cell size, as Kirill Panov rightly admonishes me is possible with XTWINOPS) without touching the cursor; that’s what the “sixel scrolling” setting (DECSDM) is supposed to do. Then you can just manually move the cursor forward however many positions after you’re done drawing.

Except apparently the DEC manual (the VT330/340 one above) and DEC hardware contradict each other as to which setting of DECSDM (set or reset) corresponds to which scrolling state (enabled or disabled), and XTerm has implemented it according to the manual not the VT3xx[1,2,3]—then most other emulators followed suit[4]—then XTerm switched to following the hardware[5,6] (unless you and that’s what I’m seeing on my machine right now. So now you need to check if you’re on XTerm ≥ 369 or not[7]. If I’m reading the Notcurses code right, other terminals have followed suit[8].

Again, ouch.

P.S. It seems DEC had an internal doc for how their terminals should operate (DEC STD 070) [9]. It does not document DECSDM at all.

[1] https://github.com/wez/wezterm/issues/217#issuecomment-86449...

[2] https://github.com/hackerb9/lsix/issues/41

[3] https://github.com/dankamongmen/notcurses/issues/1782

[4] https://github.com/arakiken/mlterm/pull/23

[5] https://invisible-island.net/xterm/xterm.log.html#xterm_369

[6] https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-T...

[7] https://github.com/dankamongmen/notcurses/commit/0918fa251e2... (the correct version cutoff is 369 not 359, the patch contains a now-fixed bug)

[8] https://github.com/dankamongmen/notcurses/blob/master/src/li... (look for mentions of invertsixel)

[9] http://www.bitsavers.org/pdf/dec/standards/EL-SM070-00_DEC_S...

And there's also the notcurses library: