This is why right now I'm working on a terminal emulator that implements escape codes that allows a subset of "byte compiled" OpenGL commands to run directly in the terminal window. You now can render a complex 3D scene just by cat'ing a file without any boiler plate code. I think there are many potential use cases for this. It allows for example remote graphics accelerated applications running on another machine via ssh. Once all the textures are uploaded to the GPU RAM the bandwidth required for the display commands is rather low even for interactive games.
And low bandwidth is useful when doing SSH: I posted this quick example of what I use everyday as a reply "ROSshow: ASCII art visualizations for robot sensor data" (https://news.ycombinator.com/item?id=19519165) by ssh'ing to my remote host (which does not have a GPU) from my laptop (which doesn't have a GPU either).
I wanted to share something that you can use right now, and that works reliably even in non optimal conditions.
Notice how my loadavg is above 10, and how I'm using a mlterm binary downloaded straight from mlterm.sf.net/bin.html
The same will work with a vanilla msys2 installation, or with the in-kernel console of "old powerless machines" as noted on https://saitoha.github.io/libsixel/#sayaka-chan
I ran into this issue while writing a shell. All shells use wcwidth() to determine the width of a unicode character. I think all terminals need that information too, and they would also need the analogous information for unknown escapes.
If the concern is the speed of the scrollback on device rendering the content, wouldn't adding GPU support to say mlterm be enough?
Anyway, if someone has a desperate need of graphical output inside a terminal, this is an actual solution working with little risks and default tools: I only recompiled gnuplot with the proper compile-time flag, exported the GNUTERM variable, and voila!!
Yes, but still a throwback to 3 decades past+
Sixel has lots of overhead compared to ascii/Unicode braille art.
Using sixel to transmit decent images over ssh is very data-demanding
I'm working on embedded software for some industrial equipment the runs over a serial port, and I'm running into all kinds of annoying problems.
I use Linux, customer uses Windows.
In Linux (Ubuntu 16), I found that large paste to Xterm does not work (I know for sure that this used to work in the past). It seems to discard data when Xon/Xoff flow control kicks in, or when a buffer is too large. I've tried minicom, PL2303, FTDI, picocom, my own serial program, XTerm and Gnome terminal. I'm pretty sure the problem is X or Unity (a C program that transfers data out the serial port works just fine). On the other hand, Xterm supports Sixel, so the embedded software can display graphs.
[Followup: I just traced this problem to "picocom", but it has been fixed in a newer version].
The idea is that I should be able to select calibration data from a spreadsheet and paste it into the terminal emulator connected to my device.
In Windows, embarrassingly, large paste works just fine, for example from TeraTerm. But Putty and TeraTerm do not support Sixel.
I suppose XTerm in Cygwin might work, but it would better to have a native Windows program.
I've not tried Mac, but nobody in the industrial world uses them.
On linux, just adding sixel to gnome-terminal and libvte would go a long way.
FYI, I picked up sixel because it's the closest thing to a standard, and because technically I saw it as good enough for most cases.
> I use Linux
I use Windows :-)
> Do any free native windows terminal emulators support Sixel?
mintty on msys2 and mlterm do. I prefer mintty, it feels faster. I'm eagerly waiting for conpty and hopefully even better consoles in Windows!
Most people are using tty apps because they don't want more crap that breaks when opengl (read, drivers) misbehaves.
However serialized graphics does not seem a project goal of either kitty or alacritty.
libsixel is not supported by urxvt, alacritty, any VTE-based terminals as far as I know.
iTerm2 has a custom base64-encodig based image format.
there are even more: https://github.com/dylanaraps/neofetch/wiki/Image-Backends
I wish VTE and gnome-terminal would add sixel support
It'd be nice to have an agreed-upon simple standard for graphics in terminals. At the same time, Unicode 13 will add 2x3 graphics blocks from ITU T.100 and T.101 standards and a couple fonts will start supporting them from the start, so some lower resolution graphics will be immediately useful.
I'm not sure if sixels will work under tmux or screen - someone mentioned they do, but I'm not sure how: the same problem we have with double-width and double-height (I wanted VTW to support them) and we all agreed it'd make tmux and screen essentially unusable.
I added screenshots of gnuplot running under both tmux and screen, using msys2 and mlterm
A vectorial support would be nice, but adding svg and a custom format like for iterm may better: Tektronix 4010 graphics is not as widely supported as sixel, and it may be a better start from scratch.
I saw this video of an actual VT-320 terminal displaying sixel graphics: https://www.youtube.com/watch?v=0SasrQ7pnbA. Someone should check what the behavior is under tmux and screen (at least).
The person also has REGIS and 4014: https://www.youtube.com/watch?v=afNuDH7QpYA and https://www.youtube.com/watch?v=kIF0sXQn0RI
I did not say it ironically! Tektronix is super-cool! It could be could be realistically rendered as sgv, and easily extended to add colors and stuff.
Some 3270 terminals also support vector graphics. I don't remember if x3270 implemented them.
And you'd have to translate the text from ASCII to EBCDIC.
iterm's image handling  is superior: it just encodes a modern and more efficient image format and sends it inbound to be decoded by the terminal. png was always at least equal if not more efficient than sixel at indexed colormaps. You can send jpegs for drastically more efficient true-color images.
The "OSC1337" is not unique to iterm. mlterm also supports it, and I do remember a few others as well. You can use "ranger" to have image previews on a remote server without having to jump through hoops.
Also, what if I use an OS where they don't work? (Windows 10?)
But when developing a new program that wants to output graphics to the terminal, OSC1337 is damn easy (you'll likely not need any new dependency or image handling routines), while for sixel you'd probably need libsixel or write your own encoder.
As a developer, I vastly edge towards iterm's handling.
(and to be honest, as a user as well. png encoding is faster too!)
cat /etc/debian_version /etc/debian_version shows the file twice
Shockingly, cat sixel1.six sixel2.six sixel3.six or img2sixel file1.jpg file2.jpg file3.jpg works in the exact same way: cf https://github.com/csdvrx/sixel-testsuite/blob/master/3-sixe...
Simply screenshot and edit the result when you are done.
But if you want to create another tool, for example to trim white boarders and concatenate, by all means please do!
Follow the example of https://github.com/hackerb9/lsix who wrote a great tool!
Already emailed, unfortunately it's too late to be included in the next release!
But you are welcome to apt-get build-deb and do that by yourself if you don't trust my binaries or my memory :-)