9 ms·
VT330/VT340 Sixel Graphics
- kps 3y agoFor those who take the weekend off, yesterday's Sixel discussion: https://news.ycombinator.com/item?id=35936331 https://news.ycombinator.com/item?id=35936331
- tyingq 3y agoThe Tektronix vector graphics that are also built into xterm is an neat side journey if Sixel is interesting to you.
- YZF 3y agoI've used a few Tektronix terminals back in the day (1980's) with an IBM mainframe and some graphing library (the name escapes me). What's old is new again? We could build some pretty nice GUIs in the terminal maybe ;)
- ape4 3y agoThere are definitely lots of interesting uses once this reaches critical mass. A "high definition" progress bar, showing photos of course, thumbnails when doing an `ls`, graphical web browsing, plotting charts, nicer looking gtop, things we haven't even dreamed of.
- prmoustache 3y agoIf it had to reach critical mass, it would have done so ages ago. This is 45y old tech.
- wkat4242 3y agoWhen this tech was invented it was less relevant than it is now. For the following reasons: - It required special expensive terminals, the VT330 (mono) or VT340. Those were not ubiquitous, the VT320 was the bread and butter type. Later VTx20 models also didn't gain support for it (usually the lower range models got premium features from the previous ranges like multiple connections / pages but this one didn't 'trickle down'). So there wasn't so much incentive for developers to support it as the installed base was very low. - It required a long time to send all the information, because terminals were still on slow serial connections. The VT320 could only do up to 19200 bps which was not even super fast for text at 80x25! Sixel images would take ages to transfer. Even though we had different expectations of response speeds then, sixels were slow by the standard of the day. - Colour highlighting (or even monochrome "bold"/ultrabright) was not even common in most commandline tools back then, even LS. Hell, on HP-UX in the 90s I couldn't even use the cursor keys in the default shell for command history and line editing! Mod cons we take for granted now were yet to be invented then. - Thumbnail processing as the parent suggests would take a lot of space and processing speed. My quota at college was a few megabytes. In fact I hardly had any images. I think I had just one, a nice Enterprise-D render that I used as wallpaper. It's not like we had thousands of images to sift through like we do today. Of course the web changed that rapidly but at that time text terminals were already on the way out. Some apps used it for stuff that was worth the wait. Like the print preview in word perfect. But many apps didn't bother because the above constraints just made them infeasible. Sixels only really took off after their original terminals were long gone. And really in this day and age we should be able to come up with something better.
- kragen 3y agosixel was more relevant then than it is now because a vt340 was still cheaper than a pc with a vga in it and the cpu time to decompress even a gif with lzw required a quite noticeable wait; jpeg wasn't even in the picture now, if you want to display graphics from a remote server, your choices include webp over quic, jpeg over http, and h.264 over ssh, and raw pixels over x11, possibly lz77-compressed by forwarding over ssh -XC sixel is an obviously terrible choice compared to any of those except that it forms part of your shell window, which is a pretty big plus; but i agree with you that in this day and age we should be able to come up with something better
- wkat4242 3y agoI don't think a VT340 and a PC competed in the same category back then. A VT needed a serious minicomputer at the very least at a backend - PC-based Linux wasn't an option yet. It was just something dependent on a core choice of what kind of computing you wanted in your business (centralised minicomputer or distributed with PCs) The applications those ran were also not compatible at all.
- kragen 3y agoa pc running procomm plus made a pretty good terminal, and there were better emulators of the vt family than procomm if you needed that and then you could also use the pc for some other things, like it could edit a text file more responsively, and without causing context switches on your vax and slowing it down for other users. even if moving the files back and forth over kermit was a bit of a pain, and the keybindings for tpu or edt weren't compatible with wordstar or brief or whatever you used on the pc but yeah once you had pcs there was a strong temptation to move most of the computing onto them unless it wouldn't fit, even though prodos, ms-dos, system 7, etc., were diarrhea pie
- prmoustache 3y agoBut do we need to do everything in your shell window? I made an alias to be able to show pictures from my kitty terminal...and almost never use it. I have a photo viewer on my laptop, why would I use the terminal for that? If I want to show a single picture, it doesn't take longer to type eog <filename> [1] than my alias (icat), if I need to see thumbnails of more than one, it doesn't take longer to open my file manager. If the file is remote, the directory is mounted easily from my file manager or the command line. [1] eye of gnome in my case
- kevin_thibedeau 3y agoYou can already make detailed bars with Unicode block drawing.
- teddyh 3y agoI guess that Wayland users have to get their remote graphics somehow.
- rwmj 3y agoIf only Wayland worked like MGR and was just an extended set of graphics primitives sent over stdin/stdout!
- kragen 3y agothis would be wonderful
- kijiki 3y agoHuh? Does: waypipe ssh remotehost guicmd not work for you?
- teddyh 3y agoI cannot find waypipe in any package for the OS on the closest machine using Wayland.
- bravetraveler 3y agoWhich distribution? I just learned about waypipe and took a quick look I found it for Ubuntu, Fedora, Alpine, Arch, and Gentoo - the first two make extending availability elsewhere pretty simple. The specs covering the package managers for most derivatives are already written
- kragen 3y agounfortunately sixel seems to be seeing a kind of revival by retrocomputing enthusiasts who want sixel support to become ubiquitous excerpt from my comments yesterday at https://news.ycombinator.com/item?id=35940188 https://news.ycombinator.com/item?id=35940188: > some technologies, like the unix shell, smalltalk, and tcp/ip, make hard things easy and easy things possible. others, like retrocomputing, code golf, and malbolge, make easy things hard and hard things impossible. sixel makes easy things hard and hard things impossible, .... > that's a fun way to spend my time when i choose to (e.g., in https://asciinema.org/a/390271 https://asciinema.org/a/390271 i did real-time 3d graphics in a unicode terminal emulator with braille) but it's not how i want my primary user interface to my computer to work ... > sixel is oulipo programming; encoding your graphics in sixel is like writing a novel without the letter 'e'. btw, a wonderful article about oulipo programming is https://100r.co/site/working_offgrid_efficiently.html https://100r.co/site/working_offgrid_efficiently.html > sixel is an art project, not an engineering project
- flohofwoe 3y ago> unfortunately ... Is there a better alternative for pixel graphics in the terminal? If yes I'm all ears. The way Sixels encodes pixel data sucks, but currently it seems to be the only way to render pixels in the terminal (and that's implemented in more than one terminal application).
- kragen 3y agoyou seem to be attempting to define 'terminal' as 'vt100 emulator', which unfortunately condemns you to only unreliable solutions like sixel that are too inefficient to provide smooth graphical interaction and full of compatibility problems. you can plot a graph from a remote machine, sure, but if you want to use your mouse to zoom in on it, you just bought a one-way ticket to jank city but i've used graphical terminals like ncd x terminals since 01994, and they provided smooth graphical interactions even over shared 10-megabit ethernet. current xorg and xwayland do a great job of emulating those terminals, with most of their deficiencies fixed, and ssh has built-in support for transparently passing along the needed credentials xpra works even better, supporting h.264 compression and reattaching to applications you've detached from the big problem with x11 is that trying to write a program to do something simple like display an image or draw a bar graph ensnares you in five pages of bureaucracy to solve that problem i wrote yeso: https://gitlab.com/kragen/bubbleos/blob/master/yeso https://gitlab.com/kragen/bubbleos/blob/master/yeso here's a program to display a png with yeso: #include <yeso.h> int main(int argc, char **argv) { ypic img = yp_read_png(argv[1]); if (!img.p) return 1; ywin w = yw_open(argv[1], img.size, ""); yp_copy(yw_frame(w), img); yw_flip(w); for (;;) yw_wait(w, 0); } it also runs on the linux framebuffer without x-windows here's a color generalization of munching squares in yeso in python: import yeso def munch(t, fb): for y, p in enumerate(fb): for x in range(fb.size.x): p[x] = (t & 1023) - ((x ^ y) & 1023) if __name__ == '__main__': with yeso.Window(u"CPython μunching", (256, 128)) as w: t = 0 while True: with w.frame() as fb: munch(t, fb) t += 1 it uses python context managers so you don't forget to yw_flip() there's also a luajit binding the example programs above are non-interactive, like virtually everything sixel that isn't full-screen; here's a lua program to test mouse interaction: local yeso = require 'yeso' function bounds(a, b) if a < b then return a, b else return b, a end end yeso.Window("mΩuso", {256, 256}):run(function (w) local m, dragStart = {x=128, y=128} while true do for ev in w:events() do if ev.isMouse then m = ev.p if ev:button(1) and dragStart == nil then dragStart = {x=ev.p.x, y=ev.p.y} elseif not ev:button(1) then dragStart = nil end end end w:frame(function (f) f:fill(0x7f7f7f) if dragStart then local minX, maxX = bounds(dragStart.x, m.x) local minY, maxY = bounds(dragStart.y, m.y) f:sub({minX, minY}, {maxX-minX, maxY-minY}):fill(0x336699) end end) w:wait() end end) as for embedding interactive graphics in a text stream, i'm still trying to figure out the bubbleos solution to that. but i'll get there, and the result will be usable over ssh, while sixel probably hasn't gotten there even for low-bandwidth interactive localhost cases and probably never will
- CharlesW 3y agoHow is this proprietary standard designed for dot matrix printers a better choice than using standards-based image formats with their associated rich ecosystem of tools? In which use cases is converting a lossy JPEG image to Sixels considered a win? https://iterm2.com/documentation-images.html https://iterm2.com/documentation-images.html
- altairprime 3y agoWas this reply intended for a comment? The documentation page linked doesn’t make any claims about or comparisons to other solutions, to the best that I can determine, and so it’s unclear to me what statement this is in reply to.
- CharlesW 3y ago> Was this reply intended for a comment? No, I'm just asking why there's interest around Sixel when there are protocols (like iTerm's Inline Images Protocol) that use standards-based image formats. I'm not a heavy terminal user and don't see much value for images in my CLI, so one very possible explanation is that I don't understand the use cases where this "interesting" format (without a guaranteed pixel aspect ratio, as I understand it) shines.
- kps 3y agoTechnically it may not be, but xterm has supported it approximately forever, and xterm is the de-facto standard minimum terminal emulator.
- CharlesW 3y agoThat's very helpful to know, thanks! So Sixels are a reasonably-popular de facto standard already, which I did not understand.
- kps 3y agoThey date to DEC terminals of the early '80s. DEC was involved in developing X Windows (competing with other windows systems like Sun's NeWS) and xterm supports many of the DEC terminal extensions to ANSI X3.64.
- Per_Bothner 3y agoSixel has the one advantage of being mplemented in xterm and a modest number of other terminals. Otherwise, it's a pretty bad format: Inefficient. Unclear and inconsistently implemented specification. All images have to be a multiple fof 6 pixel rows, which may not align with either image height or character height. Some terminal implement some other protocols, but attempts to specify a standard have failed. There are some tricky issues, such as: When does an image or part of an image get erased? Can you write text on top of an image and if so how are they aligned? What happens if you write an image on top of existing text? On top of an existing image? How does scrolling affect things? What happens to the image on window resize or zoom? Can you reliably update part of an image? DomTerm (https://domterm.org https://domterm.org) supports images in two ways: For sixels, it creates a canvas element as an "underlay". As it is earlier in he rendering order, following text can be written on top of the image. DomTerm also supports general HTML, including IMG elements. (Of course it is safety-scrubbed.) This is quite flexible, but it doesn't overlap regular text (without some contortions). DomTerm allows different lines to have different height, which is beneficial for "printing" an image without having to pad the output to an integral number of rows. Neither of these DomTerm protocls are suitable for a portable protocol that can be widely implemented. Two other protocols that I'm aware of are the iTerm2 protocol and the Kitty protocol. Both are bit on the complicated side, but a subset of one of those might be an acceptable "standard".
- crispyambulance 3y agoI find it disappointing that an article about Terminal graphics, does not, you know, include an image of what it even looks like! Is that just uninteresting to people that might want to use it?
- msla 3y agoLibrary you can use to generate these images: https://github.com/saitoha/libsixel https://github.com/saitoha/libsixel Plenty of links to other projects.
- wkat4242 3y agoFunny thing, as popular as sixels are now, they were pretty useless back in the day. It would take ages for a picture to appear on a VT terminal with those slow serial speeds (VT320 doing 19200 baud max! - not sure about the 330/340). Especially with colour. I'm pretty sure the later ones (I have a VT520 myself) didn't even have it anymore! I know word perfect for Unix used it for the print preview but I don't know any other app from those days that used them at all. The same with the double width or height fonts the VT series offers. I've only ever seen them working when running vttest. They could be very useful, but in practice I've never seen them actually used for something other than testing. These days with pretty much unlimited speed sixels actually become useful. But they don't support full 24 bit colour so another technique is probably better for today's needs. For example it would be great to be able to define a terminal region and send images and video to it with full hardware acceleration and compression (H.264 or similar). I think there's still a good usecase for terminals, but holding on to sixel feels a bit too much of a kludge to me. If they were super abundant and popular, sure. But they never actually were. I think this is also why kitty chose to build a custom protocol instead of implementing sixel.
- JdeBP 3y agoI wonder about the popularity. There are a number of examples in the long Microsoft Terminal issue discussion about sixels, but very little of it seems to be day-to-day tasks. Whereas people are getting inventive with Unicode in the little ways, from clever progress bars and spinners to tiny but importantly everyday things like arrows in shell prompts. I just myself wrote a pseudo-window login dialogue (a replacement for the login(1) program for framebuffer terminal emulators that can do Unicode) using MouseText from the Apple IIc, which got added to Unicode version 13 in 2020. * https://tty0.social/@JdeBP/110373938216006335 https://tty0.social/@JdeBP/110373938216006335
- wkat4242 3y agoYes the spinners that are made of braille are nice. And graphs. But unicode support is pretty ubiquitous now. It works great. Despite advanced unicode (ligatures, emoji) not really playing nice with monospaced fonts, most terminals handle it very well.
- hello_computer 3y agoKitty / Wezterm / iTerm2 / mintty and a few others already support base64 encoded gif/jpg/png, which are more space efficient, and easier to splat as b64 blobs than to dither and sixel-encode. Sixel needs to die.
- bawolff 3y agoEveryone uses terminals to get away from complex graphics, then people reinvent (uncover? I know this is old tech) a way to do that but poorly...