-
Notifications
You must be signed in to change notification settings - Fork 484
Intersted in picture or video rendering implementation? #143
Comments
Regarding, your two last examples I think those are high-res outputs are achieved using custom apis provided by some terminal emulators. Unless, one the backends in use within this crate supports it, it is unlikely that we will be able to reproduce them. |
It seems like sixel graphics are gaining in popularity as a way to display images in terminals, especially with the help of libsixel which even has a couple of rust api bindings. Sixel is already supported by a few terminals including xterm (with a compile time flag and some configuration), and there's an open issue for it in alacritty here. Someone has also been working on adding sixel support to termui here. |
I think the first of longwusha's two example images is the ranger file manager displaying with w3mimgdisplay. |
I'm actually very interested in being able to display arbitrary image data, mostly from the image crate. That would make this crate very useful to me. I think I'm going to try using termion for now. |
opened an issue in termion |
If you decide to implement sixel, then I wanted to pass on some things I've picked up recently, on the odd chance it could help. (Even if just by way of "go check out notcurses, it's really cool." ;) ) I implemented sixel output in my Java-language library in late 2018. For a while only xterm, RLogin, and yaft could handle the output without crashing. I reported on that work in a terminal emulators forum, and several folks reported bugs in a few terminals. Now there are at least 10-20 terminals and terminal widgets that work well. Last week I added translucent windows with images under/over, thanks in large part to some clues from notcurses. Some notes of that work are here: https://gitlab.com/klamonte/jexer/-/issues/88 . I also wrote down more details on my particular mixed image-and-text cell model here , with some narrative (and again the notcurses shoutouts) here. For encoding to sixel, check out notcurses' new octree implementation sometime. It's very likely the fastest and highest-quality anywhere right now, at least for xterm-type terminals. (libsixel was tested on real hardware, so that might give it an edge still in terms of compatibility.) Depending on how you choose to render, you may find that 256-bit colors per sixel could still result in close to 16-bit apparent visual bit depth on the actual screen, making the drive for non-sixel support a bit less crucial. (Note that the best bit depth for sixel is 19.97 bits: 101^3.) The screenshot link is my very naive median-cut encoder, which is much worse than notcurses' octree encoder -- but that's still good enough that you might not be able to tell when I'm using iTerm2+PNG vs sixel. Finally, and to my utter surprise, I may have encountered an actual xterm bug: https://gitlab.com/klamonte/jexer/-/issues/89 . Both foot and wezterm are doing quite well on sixel, and very nice options to have for testing. All in all, I'm pretty happy with the possibilities from plain old sixel: xterm_translucent_animations.mp4 |
Forgot to mention, I'm figuring out terminal dimensions by emitting an escape sequence ( |
You can also use CSI 16/18t to estimate the cell dimensions (# pixels / # cells). But it's unusual for a TE to support only one of 14/16/18 and not all of them. |
I found a trick to put sixel on the bottom row. It is standard, but some TEs don't do it right. https://gitlab.com/klamonte/jexer/-/issues/91 In practice you may be limited to bottom row cells that are within 1000x1000 pixels of the top left screen corner. |
I've been horrible with polluting that thread with references so will stop doing that, but do check out chafa's implementation too (issue 27 "sixel support" over there, start at June 22, 2020). It might be more readable / Rust-able, and today on some (maybe many?) image types it is the fastest known encoder. But notcurses is working hard to beat it, so who knows where the outcome will be. :) |
I have tried to render an image and the results look good.
I have submitted the relevant example code #141 .
Is there anyone else interested in rendering images or videos on the terminal? I think rendering at 240p resolution is feasible. If anyone else is interested in this topic, welcome to discuss and work towards this goal.
The text was updated successfully, but these errors were encountered: