glow
glow copied to clipboard
charmbracelet
Feature-request: Display images in terminal
In markdown you can display images using [name](/path/to/image).
It would be very cool to be able display them in the terminal with glow.
It could use many techniques to display images :
- Graphical libraries (sdl) in terminal
- Framebuffer
- Ascii art as done with bubbletea imgcat?
Would be great to have this feature. Lots of modern terminal support display image directly. Kitty, Iterm2 both support displaying arbitrary images in terminal. https://github.com/atanunq/viu A imgcat written in rust display image in terminal.
I'd go with viu, as Ueberzug would not work with Wayland, and viu seems to be more geared towards leveraging a wide set of backends to support wherever the image is being displayed.
For me, viu seems to only work in a non-tmux session in kitty; when I try in Alacritty (tmux or non-tmux), the image is pixelated
For me,
viuseems to only work in a non-tmux session inkitty; when I try in Alacritty (tmuxor non-tmux), the image is pixelated
The backend that it uses it dependant on a few things. It'll use Kitty's built-in image viewer when in Kitty, but this method is unfortunately not supported in tmux (the same issue arises with Ranger). It also has that pixelated block printer method, which is the only method in viu supported by Alacritty. The only actual graphical (not Chafa or blocks) method that Alacritty works with is ueberzug (not a part of viu), which draws a separate X window to display images and has quite a few limitations. viu also has Sixel support, though I've never messed with it before and Sixel support is no longer being built in to many terminal emulators. Hopefully this was semi-coherent :p
Very well explained @fort-ified , not an expert on ueberzug or other stuff, but I think one good advantage is that it works in all terminals (or at least the ones I've used :slightly_smiling_face: )
Ignoring the lack of Wayland support, I'd say the biggest issue would be that unlike Sixel or Kitty (I'm pretty sure w3m supports it too), ueberzug cannot have its images scroll with the terminal, as it's literally just a secondary window overlaying the terminal window. I suppose it'd work fine if the objective was just to be able to preview individual images, exiting out of the preview each time, but I think that it would be sub-optimal compared to the ability to display images in-line with text as if it were being viewed outside of the terminal.
Totally agree with you, in fact, I've faced a lot of issues with the images sticking to where they are and having to restart the terminal session etc.
I just wish there was a way to have high quality pictures in terminals other than kitty
Hi folks. Wrote charmbracelet/glamour#175 before seing this request. Some terminal emulators allow to embed images out-of-the-box. Displaying the real images in such terminal sessions is easy. Obviously this is not a universal answer to the request made here but is a quick win for macOS and Linux users.
Some terminal emulators allow to embed images out-of-the-box
I see that only iTerm2 is mentioned in charmbracelet/glamour#175, and I think that's MacOS specific, so it would only benefit those users
I think that's MacOS specific, so it would only benefit those users
This is not macOS specific. On macOS, it is iTerm2 specific. I have read about a) standardisation efforts and b) Linux terminal emulators supporting this.
From what I recall the standardisation effort was focusing on ANSI escape codes to download files from remote hosts to the user's local host (which is also implemented in iTerm2). Inlining images rather that saving them to disk was a byproduct of the standardisation.
I did this research some years ago when iTerm2 introduced the functionality and have not bookmarked my findings. Some research is required to enumerate the Linux terminal emulators supporting this. Unless someone has them handy :-)
Someone upthread was saying that 'Sixel support is no longer being built in to many terminal emulators.' That's kind of the opposite of what I perceive to be the trend, would you mind elaborating? Signed, a foot user :)
+1 for sixel. I know there is a fight with the kitty dude, but sixel is more future proof and implemented (or in the process of being implemented) in a lot of modern terminals (signed another happy foot user :) )
Viu and Ueberzug are unnecessary complications/dependencies. Ueberzug is better suited to adding images into terminals that don't support any image protocol.
Most of the image protocols are handled by the terminal natively via escape sequences, as long as it's a decently modern terminal. For example, wezterm supports all three protocols out of the box.
rasterm is a Go lib that can already go pretty far with cross-terminal support for iTerm2, kitty and sixel formats. It also has plenty of links for documentation and to learn more about the whole topic.
IMO, sixel is the least efficient and limited option of all. It has its place of course, and with something like rasterm there's no reason not to mix in support for it. I'm curious about the claim of it being more future proof than kitty... is there any context for that?
Of course supporting all of them with a lib is even better, but sixel is the only one I found that works on most of the terminal emulators (or is about to) and works on wayland. I didn't know about wezterm/rasterm.
As for kitty, it works mostly only with kitty, and I've seen several tentatives to push it outside, that all got dismissed, which is not surprising as I guess not a lot of people want to deal with the kitty maintainer.
swsnr/mdcat currently supports images. Would be great to have something similar.
Hi :wave: This is an excellent improvement, can I try to do it, is that okay?
Some thoughts on combining this with vhs
my project is @bevry/dorothy which is a dotfile ecosystem and has hundreds of commands to make terminal life easier. These commands have help documentation, which I'm considering converting to markdown to render with glow but also to render inside the project's documentation such as its README. I am also thinking it would be sweet if the help for each command, which already includes an example section, used vhs for a demo section, which glow could fallback to playing the actual vhs tape file.
I know I could probably do this (vhs tape for cli, vhs gif for readmes) with some effort, however I'm wondering if glow could handle this directly somehow.
