Displaying images

[cwqt]

Would be cool to be able to display images in the CLI (think displaying graphs with a higher resolution than ASCII characters) - this kind of thing has been implemented in projects like neofetch using various image backends (see https://sw.kovidgoyal.net/kitty/kittens/icat/ for example)

[mistakenelf]

Not that this is exactly what you are looking for, but, in https://github.com/knipferrc/fm I render the images as a string. Its not super high quality, but a little nicer than ASCII characters

[AutumnMeowMeow]

You may find this list of bitmap protocols and supporting terminal emulators of use: https://www.reddit.com/r/linux/comments/t3m7zm/quick_roundup_of_bitmap_graphics_availability_in/

[jficz]

For quick'n'dirty partial support two things might be enough to support Kitty graphics protocol (and sixel, too):

1. detect image APCs here and don't truncate lines containing them (and also make sure it is rendered fully if it is a multiline APC (sixel) - that doesn't always work (probably) because of the terminal height detection but I didn't do any in-depth debugging there yet.
2. make sure they're rendered properly (not sure how to do that with Kitty graphics)

Sixel graphics is usually displayed correctly by bubbletea if not truncated (i.e. short images or properly newlined images) but kitty graphics is not displayed even when the APC code is not (apparently) mangled by the rendering engine. Kitty graphics is much more powerful but the rendering is also a bit more complex so this may actually be a problem with how termenv is used but this is just a speculation on my side at this point.

[BominRahmani]

Is there any updates/plans on this enhancement? @jficz @bashbunni @cwqt

[bashbunni]

Hey @BominRahmani no plans at the moment to bring image support to Bubble Tea. It's just not adopted by enough terminal emulators right now for us to offer official support for it. Compatibility is super important to us

[meowgorithm]

Just to add some more context here, native terminal images (like sixel and so on) are functionally impossible to handle in TUIs because they can't be redrawn in the same way text can.

That said, a half-block implementation would work (like the way @mistakenelf did it) and I could see us adding support for that in Lip Gloss at some point.

[AutumnMeowMeow]

Just to add some more context here, native terminal images (like sixel and so on) are functionally impossible to handle in TUIs because they can't be redrawn in the same way text can.

Native terminal images can and have been done inside TUIs smoothly, though not supportable on every terminal. The TUI side is indeed much harder than the terminal side, but some good discussion and notes for doing images inside TUI were collected in the zellij issue for this. Zellij also did a really cool thing their sixel encoder/decoder, such that they did not need to solve the palette generation problem. (Unlike jexer where different image formats are converted internally to 32-bit ARGB and then re-encoded to whatever it detects the terminal can support.)

On the terminal side, there are quite a few now supporting sixel, either in mainline or with a patch: https://www.arewesixelyet.com/ ; and also more are supporting iTerm2 and kitty protocols.

Whether you choose to implement or not, hope you always have fun coding. 😀

💗

[meowgorithm]

I stand corrected. In that, I wouldn't mind seeing experimental support for images — though it's not a priority for us internally at the moment. That said, PRs on Lip Gloss as a starting place are welcome — I'd use viuer as a general reference.

[julez-dev]

Hey I want to use kittys terminal graphics protocol in my project to display twitch emotes. I made a small proof of concept using unicode placeholders, sadly it does not work with the WithAltScreen settings enabled, but it works without.

Any hints/tips how I can hack image support into bubbletea for my use case? 😀

[aschey]

ratatui-image would be another good reference (supports redrawing and resizing).

[codr1]

Windows Terminal (preview) now supports sixel since 1.22. So all WSL users are now on the table. Between iterm and Windows terminal I would say that a good majority of the users now have graphics support.

[CannibalVox]

I looked into this last night and this morning and there are a few issues that might complicate rolling this out just yet (these will hopefully be addressed soon). Basically, a ton of terminals are now claiming support, but support is currently buggy or inconsistent.

The biggest problem is that where the cursor ends up after printing a sixel image, despite being fairly clearly defined in the spec, seems to deviate in the two terminals I've tried (and none of them are actually in line with the spec). I have submitted issues to Windows Terminal and iTerm2 about this issue.

Additionally, tmux currently has a bunch of random support issues regardless of what terminal it runs in, but those appear to have been corrected already and the fixes will go out in the next public release.

Overall, sixel support is coming together rapidly but it's about 3% from being the sort of thing you can assume support for in a library like charm.