6 ms·

I did write a very fast SIXEL back-end [0] with adaptative quantizing and GPU acceleration, but most emulators have a very inefficient implementation unfortunat

by fathyb 4y ago

I did write a very fast SIXEL back-end [0] with adaptative quantizing and GPU acceleration, but most emulators have a very inefficient implementation unfortunately. For example iTerm converts the SIXEL data to PNG, writes it to tmpdir, and displays it as an image you can drag and drop. I’m still exploring it thought, but as a separate program to run any X apps through SSH. [0]: https://news.ycombinator.com/item?id=34288262 https://news.ycombinator.com/item?id=34288262

deleted 4y ago
[deleted]
david2ndaccount 4y ago
There’s also the kitty graphic protocol: https://sw.kovidgoyal.net/kitty/graphics-protocol https://sw.kovidgoyal.net/kitty/graphics-protocol
- csdvrx 4y ago
  Not a huge fan TBH
  - david2ndaccount 4y ago
    What's wrong with it?
    - csdvrx 4y ago
      Too much complexity. At least it allows in-band, but generally not a fan. Read https://sw.kovidgoyal.net/kitty/graphics-protocol/ https://sw.kovidgoyal.net/kitty/graphics-protocol/ Then read about the sixel format, and decide which one you think is the easiest to support.
      - aumerle 4y ago
        What nonsense, it takes literally 15 lines of code without using anything beyonf the standard library to write a client for the kitty graphics protocol. I challenge you to match that for sixel. https://sw.kovidgoyal.net/kitty/graphics-protocol/#a-minimal-example https://sw.kovidgoyal.net/kitty/graphics-protocol/#a-minimal...
        csdvrx 4y ago
        Sixels are pixels and enjoy a wide support due to how old this VT240 format is. The Kitty protocol starts with multiple formats: >> The terminal emulator must understand pixel data in three formats, 24-bit RGB, 32-bit RGBA and PNG. Different tools for different needs, but if you are going for a wide support you want something simple that doesn't also have 5 different types you have to separately implement and test: >> d: Direct (the data is transmitted within the escape code itself) >> f: A simple file (regular files only, not named pipes or similar) >> t: A temporary file, the terminal emulator will delete the file after reading the pixel data. For security reasons the terminal emulator should only delete the file if it is in a known temporary directory, such as /tmp, /dev/shm, TMPDIR env var if present and any platform specific temporary directories and the file has the string tty-graphics-protocol in its full file path. >> s: A shared memory object, which on POSIX systems is a POSIX shared memory object and on Windows is a Named shared memory object. The terminal emulator must read the data from the memory object and then unlink and close it on POSIX and just close it on Windows. > What nonsense, it takes literally 15 lines of code without using anything beyond the standard library to write a client Conveniently taking a preencoded PNG and assuming away the necessary queries of supported protocol: >> Since a client has no a-priori knowledge of whether it shares a filesystem/shared memory with the terminal emulator, it can send an id with the control data, using the i key (which can be an arbitrary positive integer up to 4294967295, it must not be zero). > I challenge you to match that for sixel Challenge accepted. There are many libraries for many languages. Let's look at this one in perl: https://github.com/saitoha/libsixel/tree/master/perl https://github.com/saitoha/libsixel/tree/master/perl use Image::LibSIXEL; $encoder = Image::LibSIXEL::Encoder->new(); $encoder->setopt("w", 400); $encoder->setopt("p", 16); $encoder->encode("images/egret.jpg"); and some print($encoder) to print the output, and this works on all the terminals listed on https://www.arewesixelyet.com/ https://www.arewesixelyet.com/ Compared to kitty: "As of April 2022, kitty and WezTerm are the only terminal emulators to support this graphics protocol completely, with Konsole and wayst having partial support" There are many nice things about the kitty protocol, but I think it's ultimately too complicated for the task. It's a Homer Mobile: https://www.wired.com/2014/07/homer-simpson-car/ https://www.wired.com/2014/07/homer-simpson-car/ If we want graphics in the terminal, first we need graphics in the terminal (using sixels is the simplest way, and you get access to many tools) then you can do more if you still want to - but you're likely to realize by then that all the extra things Kitty supports is YAGNI: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it?useskin=vector https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it?use...
csdvrx 4y ago
> most emulators have a very inefficient implementation unfortunately Try mintty (from msys2), xterm or mlterm (multiplatform)
KirillPanov 4y ago
You definitely want to use alacritty-sixel: https://github.com/chrhasse/alacritty-sixel It is crazyfast. Alacritty will merge it someday, but they have very very high standards and allowing graphics is a major change. So it's taking a lot of time.
- fathyb 4y ago
  Oh nice, I used Alacritty but didn't know about this fork. Thank you!

by fathyb 4y ago

deleted 4y ago

[deleted]

david2ndaccount 4y ago

There’s also the kitty graphic protocol: https://sw.kovidgoyal.net/kitty/graphics-protocol https://sw.kovidgoyal.net/kitty/graphics-protocol

csdvrx 4y ago
Not a huge fan TBH
- david2ndaccount 4y ago
  What's wrong with it?
  - csdvrx 4y ago
    Too much complexity. At least it allows in-band, but generally not a fan. Read https://sw.kovidgoyal.net/kitty/graphics-protocol/ https://sw.kovidgoyal.net/kitty/graphics-protocol/ Then read about the sixel format, and decide which one you think is the easiest to support.
    - aumerle 4y ago
      What nonsense, it takes literally 15 lines of code without using anything beyonf the standard library to write a client for the kitty graphics protocol. I challenge you to match that for sixel. https://sw.kovidgoyal.net/kitty/graphics-protocol/#a-minimal-example https://sw.kovidgoyal.net/kitty/graphics-protocol/#a-minimal...
      - csdvrx 4y ago
        Sixels are pixels and enjoy a wide support due to how old this VT240 format is. The Kitty protocol starts with multiple formats: >> The terminal emulator must understand pixel data in three formats, 24-bit RGB, 32-bit RGBA and PNG. Different tools for different needs, but if you are going for a wide support you want something simple that doesn't also have 5 different types you have to separately implement and test: >> d: Direct (the data is transmitted within the escape code itself) >> f: A simple file (regular files only, not named pipes or similar) >> t: A temporary file, the terminal emulator will delete the file after reading the pixel data. For security reasons the terminal emulator should only delete the file if it is in a known temporary directory, such as /tmp, /dev/shm, TMPDIR env var if present and any platform specific temporary directories and the file has the string tty-graphics-protocol in its full file path. >> s: A shared memory object, which on POSIX systems is a POSIX shared memory object and on Windows is a Named shared memory object. The terminal emulator must read the data from the memory object and then unlink and close it on POSIX and just close it on Windows. > What nonsense, it takes literally 15 lines of code without using anything beyond the standard library to write a client Conveniently taking a preencoded PNG and assuming away the necessary queries of supported protocol: >> Since a client has no a-priori knowledge of whether it shares a filesystem/shared memory with the terminal emulator, it can send an id with the control data, using the i key (which can be an arbitrary positive integer up to 4294967295, it must not be zero). > I challenge you to match that for sixel Challenge accepted. There are many libraries for many languages. Let's look at this one in perl: https://github.com/saitoha/libsixel/tree/master/perl https://github.com/saitoha/libsixel/tree/master/perl use Image::LibSIXEL; $encoder = Image::LibSIXEL::Encoder->new(); $encoder->setopt("w", 400); $encoder->setopt("p", 16); $encoder->encode("images/egret.jpg"); and some print($encoder) to print the output, and this works on all the terminals listed on https://www.arewesixelyet.com/ https://www.arewesixelyet.com/ Compared to kitty: "As of April 2022, kitty and WezTerm are the only terminal emulators to support this graphics protocol completely, with Konsole and wayst having partial support" There are many nice things about the kitty protocol, but I think it's ultimately too complicated for the task. It's a Homer Mobile: https://www.wired.com/2014/07/homer-simpson-car/ https://www.wired.com/2014/07/homer-simpson-car/ If we want graphics in the terminal, first we need graphics in the terminal (using sixels is the simplest way, and you get access to many tools) then you can do more if you still want to - but you're likely to realize by then that all the extra things Kitty supports is YAGNI: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it?useskin=vector https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it?use...

csdvrx 4y ago

> most emulators have a very inefficient implementation unfortunately Try mintty (from msys2), xterm or mlterm (multiplatform)

KirillPanov 4y ago

You definitely want to use alacritty-sixel: https://github.com/chrhasse/alacritty-sixel It is crazyfast. Alacritty will merge it someday, but they have very very high standards and allowing graphics is a major change. So it's taking a lot of time.

fathyb 4y ago
Oh nice, I used Alacritty but didn't know about this fork. Thank you!