[HN Gopher] Chafa: Terminal Graphics for the 21st Century
___________________________________________________________________
Chafa: Terminal Graphics for the 21st Century
Author : graderjs
Score : 91 points
Date : 2022-09-11 07:57 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| leephillips wrote:
| 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.
| jeffbee wrote:
| Surely xterm is the mode widely installed terminal emulator
| with a graphics mode. It emulates the Tektronix 4014 and has
| done that for decades.
| ungamed wrote:
| In the article, the author goes over exactly this.
| sreevisakh wrote:
| 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 wrote:
| Yes, kitty has a series of VTE terminal 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://codeberg.org/dnkl/foot/issues/319
| albertzeyer wrote:
| 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-T...
|
| Maybe there was also a special sync terminal escape code or so.
| dbttdft wrote:
| 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 wrote:
| I just found this, the synchronized updates spec from iTerm2:
| https://gitlab.com/gnachman/iterm2/-/wikis/synchronized-
| upda...
|
| Googling for it, it seems some other terminals implement this
| as well.
| hericium wrote:
| Just a gif? Where's the presentation? I'm spoiled by the awesome
| notcurses one[1].
|
| [1] https://www.youtube.com/watch?v=dcjkezf1ARY
| poisonarena wrote:
| chafa in mexican spanish means crappy/cheap
| anthk wrote:
| Chafar in Iberian Spanish means to smash/crash down. Also, to
| break something.
| hpjansson wrote:
| 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 wrote:
| 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 wrote:
| makes sense, a lot of non-mexican spanish speakers are
| prone to get offended easily by words that are obviously
| not an insult.
| dang wrote:
| Related:
|
| _Chafa 1.8: Terminal graphics with a side of everything_ -
| https://news.ycombinator.com/item?id=28548120 - Sept 2021 (23
| comments)
| iso8859-1 wrote:
| How does this compare to using an existing video player with
| caca?
|
| https://en.wikipedia.org/wiki/Libcaca
| thanatos519 wrote:
| There's a patch out there to use chafa as output for ffmpeg.
| csdvrx wrote:
| 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 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 wrote:
| 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 wrote:
| > 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 : 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.
| anthk wrote:
| >BSD console.
|
| Which one? Stop putting every BSD as a single entity.
| Maursault wrote:
| 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/
|
| [2] https://github.com/radare/tiv
| csdvrx wrote:
| > 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
| Maursault wrote:
| 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 wrote:
| > 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 wrote:
| >>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/-/...
| anthk wrote:
| False. I could open sixels images over SSH with an XTerm.
| csdvrx wrote:
| > 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.
| Maursault wrote:
| Extraordinary claims require extraordinary evidence.
|
| For sixels to be displayed, the terminal must have
| support for them, and most terminals don't support
| sixels, like Windows Terminal. xterm has some support,
| but only 16 colors. But xterm is otherwise an
| exceptionally feature-poor terminal. I don't think anyone
| uses xterm unless there is no other option.
|
| While sixels are a very old standard, lack of significant
| adoption and a code base that is notoriously buggy means
| that more often than not, the ability to display sixels
| just isn't there, and on the rare occasion that it is,
| artifacts are extremely common.
|
| ASCII, otoh, is supported by all terminals. Now, granted,
| no one wants to watch a video converted into text, but
| this isn't the point, which is merely a method to display
| _something_ on the command line, and in the case of
| ASCII, _every_ command line, every terminal, everywhere
| and always. mplayer is not dependent on the client, so
| any remote client can run it remotely from the server.
| sixel support is the opposite; the client must have
| support for sixels to be displayed.
|
| > I'm not sure why people expose themselves to something
| as bad and ugly in this day and age.
|
| > I don't think you understand
|
| > Even abstracting away your incomplete understanding of
| how sixels work
|
| > I have written lots of sixel code (I've yet to see any
| of yours)
|
| > tried to explain you the failure in your reasoning
|
| FWIW, all these arguments are ad hominem fallacies
| indicating invalid and otherwise faulty reasoning.
___________________________________________________________________
(page generated 2022-09-13 23:02 UTC)