3 ms·

because pixel-perfect display of images is nowhere nearly as important as people think it is, and because implementing a terminal which can display both images

because pixel-perfect display of images is nowhere nearly as important as people think it is, and because implementing a terminal which can display both images and text is much easier if you let go of the idea that pixels need to be displayed perfectly by the terminal. Pixel aspect ratios are not always 1:1. Fonts have character height to width ratios which are all over the place and a terminal which must adapt any character cell to any region of an image pixel perfectly is way more difficult than it needs to be. Unless you're Casey Muratori, probably. then there are things like display scaling, which, ideally, the terminal application itself shouldn't need to know anything about in order to render correctly. What good is a terminal that renders pixels exactly if the OS can then magnify the window so that you lose the pixel "perfection"? I don't like the Kitty protocol described in this post, either. The Windows Terminal people are thinking about this, believe it or not, and they are the ones that convinced me that existing methods are insufficient. We need yet another standard for doing this. One that can adapt to video display technology of the 1990s, at least.

rbanffy 3y ago
The only protocol I mentioned that expects pixel-perfect images is the sixel one (which is, essentially, what a DEC printer would print on paper, but on the screen). ReGIS, while it is traditionally rendered as pixels, doesn't really care about how many pixels the screen has. DPS doesn't care much about pixels, and Tektronix doesn't even have the concept of pixels, just coordinates in an x-y plane (because Tektronix terminals didn't even have pixels). > I don't like the Kitty protocol described in this post, either. The Windows Terminal people are thinking about this I've been part of these discussions (mostly from the VTE side). I agree sixel, ReGIS, and Tek are "legacy" and have been implemented in such ways it's a miracle that they ever worked, and what you see on one brand of terminal is entirely dependent on the positions of the planets when the code was written and when the image is rendered and might not resemble at all what you'd see on another brand unless by coincidence ;-P. Which is kind of why I brought up DPS - it's the only one that takes pure geometry and generates pixels (Tektronix does so as well, but it's very limited, and doesn't really like to be anchored to the text screen).
- naikrovek 3y ago
  Display PostScript makes sense to me, as well. It's almost as if it designed for this exact problem. Very different from VT100-compatible communication, though, but maybe it can be encoded to fit that mold.
  - rbanffy 3y ago
    The time-honored tradition of escape sequences can deal with this. Unfortunately, we might need some new escape sequences as the current ones are already taken with the traditional protocols.
sime2009 3y ago
Synthetic images like generated graphs with fine lines and text (i.e. not photographs), need pixel perfect rendering otherwise they look terrible. This is likely to be a far more common and useful use case for images in a terminal than showing photos.
- rbanffy 3y ago
  For images with fine lines we have both ReGIS and Tek4014. ReGIS specifies pixel values (and became somewhat of a pain when DEC terminals with more than 240 scanlines appeared) but Tektronix graphics work with (IIRC) a coordinate space of 4096x4096 addressable points. It's not too amenable to extensions and has very little functionality besides drawing straight lines in various styles and monospaced text in a couple (3, IIRC) sizes.

rbanffy 3y ago

The only protocol I mentioned that expects pixel-perfect images is the sixel one (which is, essentially, what a DEC printer would print on paper, but on the screen). ReGIS, while it is traditionally rendered as pixels, doesn't really care about how many pixels the screen has. DPS doesn't care much about pixels, and Tektronix doesn't even have the concept of pixels, just coordinates in an x-y plane (because Tektronix terminals didn't even have pixels). > I don't like the Kitty protocol described in this post, either. The Windows Terminal people are thinking about this I've been part of these discussions (mostly from the VTE side). I agree sixel, ReGIS, and Tek are "legacy" and have been implemented in such ways it's a miracle that they ever worked, and what you see on one brand of terminal is entirely dependent on the positions of the planets when the code was written and when the image is rendered and might not resemble at all what you'd see on another brand unless by coincidence ;-P. Which is kind of why I brought up DPS - it's the only one that takes pure geometry and generates pixels (Tektronix does so as well, but it's very limited, and doesn't really like to be anchored to the text screen).

naikrovek 3y ago
Display PostScript makes sense to me, as well. It's almost as if it designed for this exact problem. Very different from VT100-compatible communication, though, but maybe it can be encoded to fit that mold.
- rbanffy 3y ago
  The time-honored tradition of escape sequences can deal with this. Unfortunately, we might need some new escape sequences as the current ones are already taken with the traditional protocols.

sime2009 3y ago

Synthetic images like generated graphs with fine lines and text (i.e. not photographs), need pixel perfect rendering otherwise they look terrible. This is likely to be a far more common and useful use case for images in a terminal than showing photos.

rbanffy 3y ago
For images with fine lines we have both ReGIS and Tek4014. ReGIS specifies pixel values (and became somewhat of a pain when DEC terminals with more than 240 scanlines appeared) but Tektronix graphics work with (IIRC) a coordinate space of 4096x4096 addressable points. It's not too amenable to extensions and has very little functionality besides drawing straight lines in various styles and monospaced text in a couple (3, IIRC) sizes.