6 ms·

Chafa: Terminal Graphics for the 21st Century

97 points by graderjs 4y ago

iso8859-1 4y ago
How does this compare to using an existing video player with caca? https://en.wikipedia.org/wiki/Libcaca https://en.wikipedia.org/wiki/Libcaca
- Maursault 4y ago
  I'm not sure chafa works with video like, say, mplayer built with aalib and libcaca will convert movie files to color or B&W ASCII on the command line (iirc w/ audio only on the host machine). Similarly, on PPC Macs, there was QuickASCII,[1] which lacks audio. I have used tiv,[2] (available with MacPorts) which works very well with images, not video. There was a way to configure the browser links (not lynx) to use tiv to browse the web on cli with converted images. [1] http://quickascii.sourceforge.net/ http://quickascii.sourceforge.net/ [2] https://github.com/radare/tiv https://github.com/radare/tiv
  - csdvrx 4y ago
    > mplayer built with aalib and libcaca will convert movie files to color or B&W ASCII on the command line I'm not sure why people expose themselves to something as bad and ugly in this day and age. Even in 2016 you could use ffmpeg on a sixel-aware terminal like mintty or xterm: check https://www.youtube.com/watch?v=IkUTkqctP28 https://www.youtube.com/watch?v=IkUTkqctP28
    - Maursault 4y ago
      Let's see you try that over ssh. The subject is command line graphics and video. What you have liked to is nothing of the sort, those are not terminal graphics but rather conventional GPU graphics and merely opening a graphic window within the command prompt on a local machine to play the video. Why bother to do that when you're sitting locally at the machine with access to the GUI and all the GUI media applications? ffmpeg is a dependency of mplayer, but ffmpeg on it's own can't transcode or reinterpret video as ASCII. The reason for the exercise is only to show that video and graphics can be displayed on the command line within the limitations of the command line, namely, text only.
      - csdvrx 4y ago
        > Let's see you try that over ssh I do that everyday lol > What you have liked to is nothing of the sort and merely opening of a window within the command prompt on a local machine I don't think you understand: sixels work IN BAND, meaning ssh will transmit the full video flux "after" it's converted into sixels (it's a little more complicated than that, but I'm trying to say don't expect a SYN/ACK outside of ssh own), which will then be rendered on the remote terminal into pictures upon reception. It's just like doing 'cat' on a remote file: the content will be transmitted regardless, just at different speeds depending on your available bandwith > Why bother to do that when you're sitting locally at the machine with access to all the GUI applications? I prefer the terminal, it's more efficient.
        Maursault 4y ago
        >>Let's see you try that over ssh >I do that everyday lol Unconvincing. lol If you tried to transmit video using the sixel protocol over ssh, you will experience bandwidth issues and immediately fail. >>What you have liked to is nothing of the sort and merely opening of a window within the command prompt on a local machine >I don't think you understand: sixels work IN BAND, meaning ssh will transmit the full video flux after it's converted into sixels, which will then be rendered on the remote terminal into pictures upon reception. It's just like doing 'cat' on a remote file This will not work. "Sixel is broken because the emulation behavior depends on the font size, thus theoretically can't be supported by terminals that don't have the concept of pixel size (e.g. a detached tmux). Sixel is broken because it cannot be supported by tmux with side-by-side panes. Sixel's palette-based approach is also a terrible legacy, practically unable to transfer photos."[1] [1] https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/26 https://gitlab.freedesktop.org/terminal-wg/specifications/-/...
        anthk 4y ago
        False. I could open sixels images over SSH with an XTerm.
        csdvrx 4y ago
        > If you tried to transmit video using the sixel protocol over ssh, you will experience bandwidth issues and immediately fail. Even abstracting away your incomplete understanding of how sixels work, have you considered the possibility I may have access to way more bandwidth than you? (and I most likely do) > This will not work. Yes it does. I have written lots of sixel code (I've yet to see any of yours), tried to explain you the failure in your reasoning, yet you still don't believe me, then you deny the reality of my lived sixel experience with... a biased quote? Whatever. Have it your way. I'm out.
- csdvrx 4y ago
  Far far better than caca. But if you want a picture-perfect quality try instead mpv with a sixel output The subset of usable characters (glyphs) roughly defines how accurate the picture can be represented: if all you have is - and _ and you want to represent an horizontal pipe, it'll be ugly. Of course it's more complicated than that, but caca uses ascii, while chafa uses a larger unicode range. The example is illustrated in picture on https://github.com/csdvrx/derasterize https://github.com/csdvrx/derasterize where the left is the original basicidea.c using only unicode halfblocks, and the right has more candidate of different shapes. Derasterize lets you select the width of the range you want to use, to improve encoding time say for video - but ideally, you would be able to test that whatever font you are using contains the glyphs you want.
  - spijdar 4y ago
    The few times I've ever used libcaca/mplayer to try and play videos, it was on Linux consoles with no working X server, or when I had broken the X server, or I was just amused to try it. The thing about sixel is it's only supported on old DEC glass terminals, xterm with a non-default configuration, mintty, and several emulators that are fairly unlikely to be preinstalled anywhere. So I struggle to imagine a scenario outside of the novelty of playing video media in a terminal where you'd use sixel for playing video over either a dedicated streaming API (raw video stream, networked X, VNC, waypipe) or accessing media over a networked filesystem (e.g. sshfs, which I regularly use to watch videos). Images are a different matter, where the compromise makes more sense. Juxtaposing images with terminal output is a nifty feature. But the (IMO limited) utility of programs like caca and chafa is being "universal enough" that I can write a script that vomits a jpeg to some vague common denominator standard and it'll probably work for all my coworkers using a smorgasbord of emulators.
    - csdvrx 4y ago
      > The thing about sixel is it's only supported on old DEC glass terminals, xterm with a non-default configuration, mintty, and several emulators that are fairly unlikely to be preinstalled anywhere Uh, no? Just start xterm (say from another xterm) with the correct flag. Sixels are also supported on the BSD console. The lack of support in the likes of gnome-terminal is a willful and ugly political decision that I've already documented. > Images are a different matter, where the compromise makes more sense. Indeed, I love to do remote gnuplots > I can write a script that vomits a jpeg to some vague common denominator standard and it'll probably work for all my coworkers using a smorgasbord of emulators. This is the idea of tmux-sixel https://github.com/csdvrx/sixel-tmux https://github.com/csdvrx/sixel-tmux : intercept sixels sequences and, if your terminal doesn't support it (or if you use the scrollback buffer, to save or RAM), render a unicode representation instead (like Chafa), but if it does, pass through the original sixel sequence.
- thanatos519 4y ago
  There's a patch out there to use chafa as output for ffmpeg.
leephillips 4y ago
If you want to see pictures in your terminal but don’t want to install something just for this, the kitty terminal can do it, including over an ssh connection.
- ungamed 4y ago
  In the article, the author goes over exactly this.
- jeffbee 4y ago
  Surely xterm is the mode widely installed terminal emulator with a graphics mode. It emulates the Tektronix 4014 and has done that for decades.
dang 4y ago
Related: Chafa 1.8: Terminal graphics with a side of everything - https://news.ycombinator.com/item?id=28548120 https://news.ycombinator.com/item?id=28548120 - Sept 2021 (23 comments)
hericium 4y ago
Just a gif? Where's the presentation? I'm spoiled by the awesome notcurses one[1]. [1] https://www.youtube.com/watch?v=dcjkezf1ARY https://www.youtube.com/watch?v=dcjkezf1ARY
- ranger_danger 4y ago
  I aspire to forget even half the stuff this guy knows. Nick is insanely talented beyond my comprehension... and I have 20 years experience in programming. I can't even wrap my head around trying to in-place rotate a bitmap in C without pulling my hair out. This guy must do it in his sleep.
albertzeyer 4y ago
I think it is possible to avoid the flickering via double-buffering, right? I don't exactly remember how that works. There is the alternate screen buffer: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-The-Alternate-Screen-Buffer https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-T... Maybe there was also a special sync terminal escape code or so.
- dbttdft 4y ago
  Short of swapping in a new image during the vertical blanking interval, you will never have a "flicker" free image. Any "flicker" that can happen from no double buffer can happen because of no vsync. This begs the question why you would ever want to show graphics in the terminal in the first place. I might be wrong, but in my experience most terminal emulators do not look like they can update the full screen 60 times per second. If everyone started doing graphics in the terminal, we will have to find what method can actually output fast enough, or create it and standardize it, and soon we will have a new graphics API that all terminal emulators must conform to or not, and a way for applications to detect whether the terminal supports it.
  - albertzeyer 4y ago
    I just found this, the synchronized updates spec from iTerm2: https://gitlab.com/gnachman/iterm2/-/wikis/synchronized-updates-spec https://gitlab.com/gnachman/iterm2/-/wikis/synchronized-upda... Googling for it, it seems some other terminals implement this as well.
poisonarena 4y ago
chafa in mexican spanish means crappy/cheap
- anthk 4y ago
  Chafar in Iberian Spanish means to smash/crash down. Also, to break something.
  - hpjansson 4y ago
    I was going for Mexican Spanish, but both interpretations work, cf. cramming symbols together into a lo-fi semblance of the input. Although this might not apply to the kitty/sixel/iterm modes, depending on how you look at it :-)
    - edgyquant 4y ago
      I'm learning spanish now and these language differences are confusing. My (mexican) girlfriend has (more than once) told me a word she thought meant one thing that ended up being an insult pretty much everywhere but Mexico.
      - wudangmonk 4y ago
        makes sense, a lot of non-mexican spanish speakers are prone to get offended easily by words that are obviously not an insult.
sreevisakh 4y ago
I was hoping to see a more modern alternative to the VTE terminal protocol and its derivatives. Does anybody have any good suggestions and possible implementations?
- j-james 4y ago
  Yes, kitty has a series of VTE terminal protocol extensions: https://sw.kovidgoyal.net/kitty/protocol-extensions/ https://sw.kovidgoyal.net/kitty/protocol-extensions/ The intention is to document them well enough that other terminal emulators can implement them (which some have). Among those is a graphics protocol, which is actually (optionally) used by chafa. Another is a keyboard protocol extension: which has been implemented by a number of editors and other terminals: notably neovim, kakoune, helix, wezterm, and foot. https://github.com/wez/wezterm/issues/986 https://github.com/wez/wezterm/issues/986 https://codeberg.org/dnkl/foot/issues/319 https://codeberg.org/dnkl/foot/issues/319

97 points by graderjs 4y ago

How does this compare to using an existing video player with caca? https://en.wikipedia.org/wiki/Libcaca https://en.wikipedia.org/wiki/Libcaca

Maursault 4y ago
I'm not sure chafa works with video like, say, mplayer built with aalib and libcaca will convert movie files to color or B&W ASCII on the command line (iirc w/ audio only on the host machine). Similarly, on PPC Macs, there was QuickASCII,[1] which lacks audio. I have used tiv,[2] (available with MacPorts) which works very well with images, not video. There was a way to configure the browser links (not lynx) to use tiv to browse the web on cli with converted images. [1] http://quickascii.sourceforge.net/ http://quickascii.sourceforge.net/ [2] https://github.com/radare/tiv https://github.com/radare/tiv
- csdvrx 4y ago
  > mplayer built with aalib and libcaca will convert movie files to color or B&W ASCII on the command line I'm not sure why people expose themselves to something as bad and ugly in this day and age. Even in 2016 you could use ffmpeg on a sixel-aware terminal like mintty or xterm: check https://www.youtube.com/watch?v=IkUTkqctP28 https://www.youtube.com/watch?v=IkUTkqctP28
  - Maursault 4y ago
    Let's see you try that over ssh. The subject is command line graphics and video. What you have liked to is nothing of the sort, those are not terminal graphics but rather conventional GPU graphics and merely opening a graphic window within the command prompt on a local machine to play the video. Why bother to do that when you're sitting locally at the machine with access to the GUI and all the GUI media applications? ffmpeg is a dependency of mplayer, but ffmpeg on it's own can't transcode or reinterpret video as ASCII. The reason for the exercise is only to show that video and graphics can be displayed on the command line within the limitations of the command line, namely, text only.
    - csdvrx 4y ago
      > Let's see you try that over ssh I do that everyday lol > What you have liked to is nothing of the sort and merely opening of a window within the command prompt on a local machine I don't think you understand: sixels work IN BAND, meaning ssh will transmit the full video flux "after" it's converted into sixels (it's a little more complicated than that, but I'm trying to say don't expect a SYN/ACK outside of ssh own), which will then be rendered on the remote terminal into pictures upon reception. It's just like doing 'cat' on a remote file: the content will be transmitted regardless, just at different speeds depending on your available bandwith > Why bother to do that when you're sitting locally at the machine with access to all the GUI applications? I prefer the terminal, it's more efficient.
      - Maursault 4y ago
        >>Let's see you try that over ssh >I do that everyday lol Unconvincing. lol If you tried to transmit video using the sixel protocol over ssh, you will experience bandwidth issues and immediately fail. >>What you have liked to is nothing of the sort and merely opening of a window within the command prompt on a local machine >I don't think you understand: sixels work IN BAND, meaning ssh will transmit the full video flux after it's converted into sixels, which will then be rendered on the remote terminal into pictures upon reception. It's just like doing 'cat' on a remote file This will not work. "Sixel is broken because the emulation behavior depends on the font size, thus theoretically can't be supported by terminals that don't have the concept of pixel size (e.g. a detached tmux). Sixel is broken because it cannot be supported by tmux with side-by-side panes. Sixel's palette-based approach is also a terrible legacy, practically unable to transfer photos."[1] [1] https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/26 https://gitlab.freedesktop.org/terminal-wg/specifications/-/...
        anthk 4y ago
        False. I could open sixels images over SSH with an XTerm.
        csdvrx 4y ago
        > If you tried to transmit video using the sixel protocol over ssh, you will experience bandwidth issues and immediately fail. Even abstracting away your incomplete understanding of how sixels work, have you considered the possibility I may have access to way more bandwidth than you? (and I most likely do) > This will not work. Yes it does. I have written lots of sixel code (I've yet to see any of yours), tried to explain you the failure in your reasoning, yet you still don't believe me, then you deny the reality of my lived sixel experience with... a biased quote? Whatever. Have it your way. I'm out.
csdvrx 4y ago
Far far better than caca. But if you want a picture-perfect quality try instead mpv with a sixel output The subset of usable characters (glyphs) roughly defines how accurate the picture can be represented: if all you have is - and _ and you want to represent an horizontal pipe, it'll be ugly. Of course it's more complicated than that, but caca uses ascii, while chafa uses a larger unicode range. The example is illustrated in picture on https://github.com/csdvrx/derasterize https://github.com/csdvrx/derasterize where the left is the original basicidea.c using only unicode halfblocks, and the right has more candidate of different shapes. Derasterize lets you select the width of the range you want to use, to improve encoding time say for video - but ideally, you would be able to test that whatever font you are using contains the glyphs you want.
- spijdar 4y ago
  The few times I've ever used libcaca/mplayer to try and play videos, it was on Linux consoles with no working X server, or when I had broken the X server, or I was just amused to try it. The thing about sixel is it's only supported on old DEC glass terminals, xterm with a non-default configuration, mintty, and several emulators that are fairly unlikely to be preinstalled anywhere. So I struggle to imagine a scenario outside of the novelty of playing video media in a terminal where you'd use sixel for playing video over either a dedicated streaming API (raw video stream, networked X, VNC, waypipe) or accessing media over a networked filesystem (e.g. sshfs, which I regularly use to watch videos). Images are a different matter, where the compromise makes more sense. Juxtaposing images with terminal output is a nifty feature. But the (IMO limited) utility of programs like caca and chafa is being "universal enough" that I can write a script that vomits a jpeg to some vague common denominator standard and it'll probably work for all my coworkers using a smorgasbord of emulators.
  - csdvrx 4y ago
    > The thing about sixel is it's only supported on old DEC glass terminals, xterm with a non-default configuration, mintty, and several emulators that are fairly unlikely to be preinstalled anywhere Uh, no? Just start xterm (say from another xterm) with the correct flag. Sixels are also supported on the BSD console. The lack of support in the likes of gnome-terminal is a willful and ugly political decision that I've already documented. > Images are a different matter, where the compromise makes more sense. Indeed, I love to do remote gnuplots > I can write a script that vomits a jpeg to some vague common denominator standard and it'll probably work for all my coworkers using a smorgasbord of emulators. This is the idea of tmux-sixel https://github.com/csdvrx/sixel-tmux https://github.com/csdvrx/sixel-tmux : intercept sixels sequences and, if your terminal doesn't support it (or if you use the scrollback buffer, to save or RAM), render a unicode representation instead (like Chafa), but if it does, pass through the original sixel sequence.
thanatos519 4y ago
There's a patch out there to use chafa as output for ffmpeg.

leephillips 4y ago

If you want to see pictures in your terminal but don’t want to install something just for this, the kitty terminal can do it, including over an ssh connection.

ungamed 4y ago
In the article, the author goes over exactly this.
jeffbee 4y ago
Surely xterm is the mode widely installed terminal emulator with a graphics mode. It emulates the Tektronix 4014 and has done that for decades.

dang 4y ago

Related: Chafa 1.8: Terminal graphics with a side of everything - https://news.ycombinator.com/item?id=28548120 https://news.ycombinator.com/item?id=28548120 - Sept 2021 (23 comments)

hericium 4y ago

Just a gif? Where's the presentation? I'm spoiled by the awesome notcurses one[1]. [1] https://www.youtube.com/watch?v=dcjkezf1ARY https://www.youtube.com/watch?v=dcjkezf1ARY

ranger_danger 4y ago
I aspire to forget even half the stuff this guy knows. Nick is insanely talented beyond my comprehension... and I have 20 years experience in programming. I can't even wrap my head around trying to in-place rotate a bitmap in C without pulling my hair out. This guy must do it in his sleep.

albertzeyer 4y ago

I think it is possible to avoid the flickering via double-buffering, right? I don't exactly remember how that works. There is the alternate screen buffer: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-The-Alternate-Screen-Buffer https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-T... Maybe there was also a special sync terminal escape code or so.

dbttdft 4y ago
Short of swapping in a new image during the vertical blanking interval, you will never have a "flicker" free image. Any "flicker" that can happen from no double buffer can happen because of no vsync. This begs the question why you would ever want to show graphics in the terminal in the first place. I might be wrong, but in my experience most terminal emulators do not look like they can update the full screen 60 times per second. If everyone started doing graphics in the terminal, we will have to find what method can actually output fast enough, or create it and standardize it, and soon we will have a new graphics API that all terminal emulators must conform to or not, and a way for applications to detect whether the terminal supports it.
- albertzeyer 4y ago
  I just found this, the synchronized updates spec from iTerm2: https://gitlab.com/gnachman/iterm2/-/wikis/synchronized-updates-spec https://gitlab.com/gnachman/iterm2/-/wikis/synchronized-upda... Googling for it, it seems some other terminals implement this as well.

poisonarena 4y ago

chafa in mexican spanish means crappy/cheap

anthk 4y ago
Chafar in Iberian Spanish means to smash/crash down. Also, to break something.
- hpjansson 4y ago
  I was going for Mexican Spanish, but both interpretations work, cf. cramming symbols together into a lo-fi semblance of the input. Although this might not apply to the kitty/sixel/iterm modes, depending on how you look at it :-)
  - edgyquant 4y ago
    I'm learning spanish now and these language differences are confusing. My (mexican) girlfriend has (more than once) told me a word she thought meant one thing that ended up being an insult pretty much everywhere but Mexico.
    - wudangmonk 4y ago
      makes sense, a lot of non-mexican spanish speakers are prone to get offended easily by words that are obviously not an insult.

sreevisakh 4y ago

I was hoping to see a more modern alternative to the VTE terminal protocol and its derivatives. Does anybody have any good suggestions and possible implementations?

j-james 4y ago
Yes, kitty has a series of VTE terminal protocol extensions: https://sw.kovidgoyal.net/kitty/protocol-extensions/ https://sw.kovidgoyal.net/kitty/protocol-extensions/ The intention is to document them well enough that other terminal emulators can implement them (which some have). Among those is a graphics protocol, which is actually (optionally) used by chafa. Another is a keyboard protocol extension: which has been implemented by a number of editors and other terminals: notably neovim, kakoune, helix, wezterm, and foot. https://github.com/wez/wezterm/issues/986 https://github.com/wez/wezterm/issues/986 https://codeberg.org/dnkl/foot/issues/319 https://codeberg.org/dnkl/foot/issues/319