Request for sixel support for image previews, to support multiplexers

[AndydeCleyre]

While the terminal app I use supports the kitty image protocol, I am always in tmux, which decidedly will never support it.

There is however a fork of tmux for sixel support tmux now supports sixel, and sixel support is imminent for zellij zellij supports sixel as well, which may be able to supplant tmux in my case eventually. Zellij, too, has no plans to ever support the kitty image protocol.

---

Another option to support multiplexers is the ueberzug x11 stuff ueberzugpp 🤷🏼.

[BluishHumility]

I wanted to +1 this request for Sixel support.

I have really been enjoying Broot. It is featureful and intuitive, and is out of the box better than I was able to get some other TUI file explorers even after hours of patching and hacking around in config files. The only place it falls down for me is browsing image folders; the pixelated image previews are not enough for certain things. At the moment I typically escape from Broot into the normal terminal to run lsix (https://github.com/hackerb9/lsix) in order to view proper image thumbnails.

Adding Sixel support to Broot would massively expand the number of terminals that support previewing higher-resolution images. Here is a list (scooped off of the lsix site linked above):

SIXEL compatible terminals

• XTerm (tested)
• MLterm (tested)
• foot (tested)
• Wezterm (tested)
• Contour (tested)
• iTerm2 for Apple MacOS (tested)
• Konsole (reported)
• yakuake (reported)
• WSLtty for Microsoft Windows (reported)
• MinTTY for Cygwin (Microsoft Windows) (reported)
• Yaft for Linux framebuffer (tested)
• VTE (special compilation, reported)
• sixel-tmux (fork of tmux, reported)
• ttyd (reported)

I see this request is already nearly six months old, but I thought I would speak up and say there is still interest in having Sixel support in Broot. I really think it would be a valuable addition to this great project.

[Canop]

I see this request is already nearly six months old, but I thought I would speak up and say there is still interest in having Sixel support in Broot.

You did well. I maintain many projects and there are many many open issues. Users being interested in a issue is the main reason for me to consider working on it.

[Canop]

If somebody finds either a Rust code, something portable, or a precise specification for producing sixel escape codes from an image buffer, this would help this issue.
I don't want to import another native library like libsixel, and I'll only consider maintainable code.

[likewhatevs]

If somebody finds either a Rust code, something portable, or a precise specification for producing sixel escape codes from an image buffer, this would help this issue.

I think this function is exactly that, it's in this crate.

The key difference from the ideal (buffer in, escape codes out) is that it accepts Vec<String> and buffer instead of dimensions and buffer (i.e., it gets dimensions from Vec<String> and resizes accordingly).

Looking at kitty support, and that function in onefetch, I see all the components there (i.e. take things from image crate, resize to X lines, return a string of escape codes).

[Canop]

Thanks @likewhatevs, this is actually helpful!

[Canop]

Adding Sixel support to Broot would massively expand the number of terminals that support previewing higher-resolution images

Not sure about that. On linux, is there even a usable terminal supporting sixel and not supporting the kitty protocol too (xterm can hardly count as it needs you to compile it yourself to add sixel support) ?

edit: found one, mlterm (not sure it's being used much)

[BluishHumility]

On linux, is there even a usable terminal supporting sixel and not supporting the kitty protocol too

I use Foot on Wayland machines, which was what motivated me to chime in on the thread. I guess how "usable" is defined here is relevant, but for what it's worth Foot is the default terminal for the Sway window manager.

I will admit I did not consider some of the Sixel-compatible terminals would also support the Kitty protocol, so it is likely I overstated the impact Sixel support will have.

[Efreak]

On linux, is there even a usable terminal supporting sixel and not supporting the kitty protocol too (xterm can hardly count as it needs you to compile it yourself to add sixel support)

There's many terminals with sixel support, though I can't vouch for whether or not they support Kitty protocol. See https://www.arewesixelyet.com

[AndydeCleyre]

On linux, is there even a usable terminal supporting sixel and not supporting the kitty protocol too

Yes: any terminal that supports sixel and is running tmux.

Original comment, outdated

This is not a strong answer, because tmux doesn't support either, and the sixel-support tmux fork is not super maintained, but for me the answer is tmux. If broot supported sixel I would use the tmux fork...

Again, I see how this is not a strong answer.

EDIT: bookmarking here the latest tmux-sixel option I see:

• mention
• repo
• Note from the mention:

you need to enable allow-passthrough in the config

[NathNLM]

+1 to this, it would be really nice to preview on high-res in foot

[Canop]

Note that I have nothing against supporting sixel, but right now there's no clear description of the protocol, and there's nothing reasonably clean and easy to port (and no pure Rust complete implementation).

[AndydeCleyre]

I think it's worth linking ueberzugpp here now:

Überzug++ is a command line utility written in C++ which allows to draw images on terminals by using X11/wayland child windows, sixels, kitty and iterm2..

This project intends to be a drop-in replacement for the now defunct [ueberzug](https://github.com/seebye/ueberzug) project. If some tool doesn't work,
feel free to open an issue.

Advantages over w3mimgdisplay and ueberzug:

- support for wayland (sway and hyprland only) and MacOS
- no race conditions as a new window is created to display images
- expose events will be processed, so images will be redrawn on switch workspaces
- tmux support on X11, sway and hyprland
- terminals without the WINDOWID environment variable are supported
- chars are used as position - and size unit
- No memory leak (usage of smart pointers)
- A lot of image formats supported (through opencv and libvips).
- GIF and animated WEBP support on X11, Sixel, Sway and hyprland
- Fast image downscaling (through opencv and opencl)
- Cache resized images for faster viewing

[markus-bauer]

AFAIK, kitty now also supports placing images with unicode placeholders, which should work in tmux:
https://sw.kovidgoyal.net/kitty/graphics-protocol/#unicode-placeholders
See also:
ranger/ranger#2856

I haven't tested it though.

[wyndon]

+1

[n0bra1n3r]

How feasible would it be to support a "preview" verb? My idea is that this verb would be automatically called upon selection of a preview-able file in broot, allowing the execution of an external command to preview the file:

[[verbs]]
  invocation = "preview"
  external = 'nvim --server $NVIM --remote-send "<C-\><C-N>:e {file}<CR>"'
  apply_to = "file"

I use broot in neovim as my file explorer, and this feature would allow me to show a file selected in broot as a vim buffer in the same instance. This would essentially allow broot to support all filetypes, highlighting and previews that vim supports.

I would set it up so that broot and the preview buffers appear in a single instance of neovim, but I imagine a similar setup could also be done with a combination of broot, tmux, and vim.

[BluishHumility]

Note that I have nothing against supporting sixel, but right now there's no clear description of the protocol, and there's nothing reasonably clean and easy to port (and no pure Rust complete implementation).

I am not sure if it is reasonably clean or easy to port, but aside from a little bit of Lua the Yazi file manager is written in Rust, and they have incorporated Sixel support for image previewing in there somehow.

Understanding the code is significantly beyond my skill set, but grepping through the repo for "sixel" turns up this file: https://github.com/sxyazi/yazi/blob/main/yazi-adaptor/src/adaptor.rs and this one: https://github.com/sxyazi/yazi/blob/main/yazi-adaptor/src/lib.rs

I apologize if that is not helpful or relevant; like I mentioned I am not really sure what I am looking at but I thought I might mention it in case it is useful. I am still holding out hope for this feature! 🤞

[gustavo-hms]

Hi! Sorry for the late quoting, but may be it can contribute to the discussion:

On linux, is there even a usable terminal supporting sixel and not supporting the kitty protocol too (xterm can hardly count as it needs you to compile it yourself to add sixel support) ?

Yes! Konsole is one such terminal. And given that it's the default terminal of KDE Plasma, shipped by default in many distros and also in Steam Deck, it alone makes the sixel protocol much more widely available to the general public than Kitty's protocol.

I understand that implementing that protocol isn't an easy task, and I'm OK if you decide to not do that. But I'd argue that you should at least take a closer look at it, since sixel offers a more out-of-the-box experience to the user due to being implemented by a wider number of terminals, including a mainstream terminal like Konsole.

[BluishHumility]

Yes! Konsole is one such terminal.

No, Konsole is not an example of such a terminal because it also supports the kitty protocol.

[AndydeCleyre]

I posted this on the wrong issue at first:

---

I just learned that official tmux can now be built with sixel support!

https://www.arewesixelyet.com/#tmux

---

So the answer to the question

On linux, is there even a usable terminal supporting sixel and not supporting the kitty protocol too

is now yes: any terminal that supports sixel and is running tmux.