8 ms·

Timg – Terminal Image Viewer

124 points by setra 10y ago

captn3m0 10y ago
2 npm modules I've relied on in the past for this: https://github.com/substack/picture-tube https://github.com/substack/picture-tube and https://github.com/switer/imaging https://github.com/switer/imaging
coleifer 10y ago
The terminal web browser w3m can display actual images pixel for pixel in the terminal. Ranger, a terminal file browser, leverages this to do image previews in the term. It's quite cool! More details, including other methods, are described here: https://github.com/ranger/ranger/wiki/image-previews https://github.com/ranger/ranger/wiki/image-previews
- a3n 10y ago
  Hey, that even works in the console (ctl-alt-F[1-6]). I guess I shouldn't be surprised, but I am. Delightfully.
  - digi_owl 10y ago
    As long as you use framebuffer consoles.
    - thom 10y ago
      As long as you're using a framebuffer, you might as well use netsurf-fb, which is a pretty modern browser.
      - digi_owl 10y ago
        On a lark i threw it at Reddit and found that it got the layout mostly right. But as it lacks JS support (no surprise there, JS is quite the beast) i could not do much beyond look at pretty pictures. Edit: Heh, threw it at HN and it worked fine for the most part. Trying to search just resulted in a blank page though. And throwing it at some news pages didn't exactly go "well" (and i reminded myself why i have no love for The Verge). Funny thing is that without all the JS and CSS to parse, even the biggest news sites came up in a matter of seconds.
- digi_owl 10y ago
  Best i understand you need to use a xterm derived terminal for this to work, because the sub-program used by w3m for this draws over the terminal window to make things happen. One more thing we can kiss bye bye with Wayland i guess.
  - mrkgnao 10y ago
    It's curious how we're prepared to replace X (with people writing tiling WMs and the like that support it) but somehow the move away from xtermy things (and backwards-compatibility-all-the-way-back-to-way-back-when) hasn't really caught on much, at least on the Linux side of things yet. Any exciting work in this area? I'm aware of Black Screen and some other work on the Electron/rewrite-everything-in-JS front (Hyper, I think, is another). I've been using Alacritty myself for a couple of weeks now. It's not too bad: the htop header bar won't render properly and catting random binary files crashes the terminal pretty quickly, but it's smooth and does everything a good "tmux VM" should do well. I understand iterm2 on macOS is a significantly improved experience?
    - digi_owl 10y ago
      Could be because as of yet the meat of terminal, the tty, happens in the kernel. And the kernel devs, as last as Torvalds remain in charge, is not as magpie about chasing the latest shinies. Note however that there exist effort towards moving the tty into user space. And one leading figure in that is currently involved with systemd. So i suspect it will happen, it is just a question of when...
    - JdeBP 10y ago
      The "catting binary files" problem largely goes away when you use a terminal emulator that doesn't implement ISO 2022 escape sequences, or where ISO 2022 support can be and has been turned off. The mosh people made a big deal about this approximately five years ago. Their claim that only mosh is like this, still present on their WWW site, is not in fact true now. I say "largely" because there are a couple of other nasty escape sequences, like (for example) OSC sequences to set window titles and terminal names, that binary files can also accidentally contain and that therefore have to be disabled. Removing ISO 2022 makes the problem far less likely to be hit, but doesn't quite eliminate it entirely.
- jdormit 10y ago
  Does anyone know how to make this work with tmux splits? I tried setting this up but the images would be displayed across splits as if w3m was taking up the whole terminal.
- knolax 10y ago
  For anyone interested, I wrote a standalone bash script wrapper for it a while back https://github.com/knolax/dotfiles/blob/master/scripts/image.sh https://github.com/knolax/dotfiles/blob/master/scripts/image....
FreeFull 10y ago
I have written something similar before here: https://github.com/FreeFull/termimage https://github.com/FreeFull/termimage . My program though is just a simple toy, since it doesn't even consider the size on the terminal, and doesn't play animated gifs. On the other hand, the source code for my image viewer almost completely fits on my screen (if you ignore its use of libraries for terminal handling and image reading).
saagarjha 10y ago
Those using iTerm should try out imgcat: https://www.iterm2.com/documentation-images.html https://www.iterm2.com/documentation-images.html
- stefco_ 10y ago
  Agreed. There is even a matplotlib backend called itermplot[0] that uses iterm's image display capabilities, which, combined with iterm's tmux integration, makes developing scientific code on remote servers a dream. [0] https://github.com/daleroberts/itermplot https://github.com/daleroberts/itermplot
  - saagarjha 10y ago
    Looks great! Now if only there was one for Mathematica…
  - daleroberts 10y ago
    Glad you like it :)
- daleroberts 10y ago
  If you are using iTerm2 and doing computer vision / machine learning on images or working with large images, my tool called 'bv' has even more features and supports TMUX as well: https://github.com/daleroberts/bv https://github.com/daleroberts/bv It uses GDAL as a backend.
michaelmior 10y ago
pxl is another nice option https://github.com/ichinaski/pxl https://github.com/ichinaski/pxl
- JdeBP 10y ago
  It makes an interesting comparison to the others mentioned here. timg and pixterm both hard-wire the ISO/IEC 8613-6 control sequences for 256x256x256 RGB colour. Neither of them, as I have already mentioned elsewhere, optimize their output at all. pxl employs a far more complete third party library for its terminal rendering, named termbox. This has ncurses-style double-buffering for no-op redraw suppression and redundant colour control sequence optimization. It does not optimize as far as BSD SCREEN did in the 1980s, which made use of several more tricks to reduce the need for emitting lengthy cursor motion control sequences (such as carriage return, line feed, and the various relative-motion control sequences; and not optimizing away writing a character if it is shorter to just re-output the next cell position than to move the cursor). The downside of termbox is that whilst it supports 8-colour and 256-colour terminal types, and reads the TERM environment variable and terminfo entry to determine colour capability, it does not support 256x256x256 RGB colour and hardwires the 8-colour and 256-colour control sequences to ECMA-48 and ISO 8613-6 indexed colour control sequences rather than employing the appropriate terminfo fields, even though it reads the terminfo database. timg, pxl, and pixterm also only display 2 pixels per character cell, because they all use the same single Unicode character for rendering (making termbox, with all of its worrying about character widths and replacement characters, overkill to an extent). As mentioned by its author on this page, tv uses a whole bunch of the box drawing and block graphic Unicode characters for increasing the number of pixels per character cell. But whilst tv does both 256-colour and 256x256x256 RGB colour, it does not do 8-colour or greyscale like pxl does, and it completely ignores the terminfo database and the TERM environment variable.
xuhu 10y ago
Does this or any of the mentioned alternatives work over ssh ?
- tedunangst 10y ago
  ssh doesn't really care about your terminals capabilities. (Yes.)
- JdeBP 10y ago
  There is no real reason that any of them would not, SSH not involving decoding and then reëncoding terminal control sequences. The more relevant concerns would be whether they worked with tmux, screen, and mosh, which do involve that; and whether the terminal emulator on the local end of one's SSH connection supports 256x256x256 RGB colour control sequences. That said, one of the issues on timg's issues list deals in the sheer amount of superfluous data that are generated and that that thus have to be transmitted across an SSH connection or a serial device. There is no optimization of the colour change control sequences at all. pixterm similarly does zero optimization, but no-one has pointed that out yet. * https://github.com/hzeller/timg/issues/13 https://github.com/hzeller/timg/issues/13 pxl, mentioned elsewhere on this page, does optimize colour control sequences and indeed uses an ncurses-style double-buffer mechanism to optimize re-drawing.
executesorder66 10y ago
This is great. Since we are all posting alternatives, here's another: https://github.com/withoutboats/notty https://github.com/withoutboats/notty
digi_owl 10y ago
https://github.com/saitoha/libsixel https://github.com/saitoha/libsixel
- FreeFull 10y ago
  Note that most commonly used terminals don't support sixel graphics (The readme for libsixel has a list of some terminals that do have support), while a lot more terminals support 24-bit colours (all terminals that use a new enough libvte in particular, and some others).
  - digi_owl 10y ago
    Same "problem" as the w3m solution mentioned in the top most comment right now...
digi_owl 10y ago
Just reminded myself of another option: https://github.com/cacalabs/libcaca https://github.com/cacalabs/libcaca
- JdeBP 10y ago
  The downside of libcaca is that it makes several presumptions that aren't necessarily true outwith the world of IBM PC Colour Graphics Adapter compatibility. For example, it has a tendency to abuse boldface black on black as a way to get a dark grey colour, making it not work so well on terminals where boldface really is a switch to a boldface font rather than brightening the foreground colour. On such terminals, black on black text is invisible, boldfaced or no. Sadly, it actually works internally in terms of a 4x16x16x16 ARGB colour system, and could work quite well with 88-colour or 256-colour terminals, and very well with terminals that have 256x256x256 RGB, were it not for the fact that most of the information in the internal colour representation is thrown away by the ncurses and CGA-like layers that are built on top of it.
iaml 10y ago
What's the difference with tv[0]? [0] https://github.com/daleroberts/tv https://github.com/daleroberts/tv
- daleroberts 10y ago
  Tv pushes the rendering further by using more unicode characters. It also uses GDAL as a backend which allows subsampling of massive images and access to many scientific image formats (GeoTiff, NetCDF, JPEG2000, etc)
  - JdeBP 10y ago
    Some other differences are given at https://news.ycombinator.com/item?id=13906483 https://news.ycombinator.com/item?id=13906483 . One problem that all of these programs share is something that you cannot really do much about absent user-supplied information, since it is something that isn't exposed in the abstraction of a POSIX General Terminal Device. It is probably more acute for tv than for the others, albeit that as I have mentioned I couldn't get tv to actually run without error to see what the effect is. This problem is that there is a baked-in assumption about the glyphs of the characters. This is not the usual concern that glyphs are different shapes in different fonts. That's not really much of a concern for box drawing and block graphic characters. The baked-in assumption is that glyphs are rectangular, with a 1:2 aspect ratio. This is the assumption that underpins the idea that U+2580 is two square pixels, one atop the other. But this is not true even for 9x15 fonts, which yield a slight distortion with all of these programs, let alone for yet squarer fonts. Barack Obama looks very odd indeed when U+2580 is actually a 16x16 or 32x32 square, as it sometimes is. (http://fileformat.info/info/unicode/char/2580/fontsupport.htm http://fileformat.info/info/unicode/char/2580/fontsupport.ht... shows several square appearances, and it is square in one of the fonts that I use here.) tv, with the way that it already works, is probably best placed to incorporate user-supplied information about the font's character cell aspect ratio. pxl could probably be extended fairly simply, too. The others including timg, I suspect would be harder. Interestingly, M. Zeller has had an open issue about this for timg since 2016. * https://github.com/hzeller/timg/issues/4 https://github.com/hzeller/timg/issues/4
daleroberts 10y ago
TV gives even more interesting results as it uses more unicode 9.0 characters: http://www.github.com/daleroberts/tv http://www.github.com/daleroberts/tv
- JdeBP 10y ago
  But unfortunately for Debian 8 users, it is not compatible with the python3-gdal provided in Debian 8 and fails to work with a runtime error. Traceback (most recent call last): File "./tv", line 82, in <module> SAMPLING = {'nearest': gdal.GRIORA_NearestNeighbour, AttributeError: 'module' object has no attribute 'GRIORA_NearestNeighbour' * https://packages.debian.org/jessie/python3-gdal https://packages.debian.org/jessie/python3-gdal timg built and ran as-is on Debian 8 with the libraries that it needs.
  - daleroberts 10y ago
    Thanks for telling me, it looks like Debian is using GDAL v1...
msollami 10y ago
gpicview anyone?
taeric 10y ago
For emacs users, you can get a similar thing with iimage-mode and eshell. Kind of cool to have "$ cat SomeImage.png" do what I would expect and put it in the terminal.
Klasiaster 10y ago
Some time ago a Rust version of these kind of programmes was presented here: https://github.com/nabijaczleweli/termimage https://github.com/nabijaczleweli/termimage A useful additional script: #!/bin/bash for i in `find $@` ; do termimage --size 150x33 $i ; done
LeicaLatte 10y ago
Currently using pixterm which works on any ANSI terminal. https://github.com/eliukblau/pixterm https://github.com/eliukblau/pixterm
- JdeBP 10y ago
  No, it does not. Like timg here, it only works on terminals that have 256x256x256 RGB colour, for which it hardwires the control sequences; and this is explained up-front in its doco. An "ANSI" terminal need only support ECMA-48, which has 8 colours; as can be seen from the terminfo entry for the "ansi" terminal type. "true colour" is ISO/IEC 8613-6. * http://unix.stackexchange.com/a/289871/5132 http://unix.stackexchange.com/a/289871/5132
frabbit 10y ago
FYI: "catimg" is available as a Fedora rpm.

124 points by setra 10y ago

2 npm modules I've relied on in the past for this: https://github.com/substack/picture-tube https://github.com/substack/picture-tube and https://github.com/switer/imaging https://github.com/switer/imaging

coleifer 10y ago

The terminal web browser w3m can display actual images pixel for pixel in the terminal. Ranger, a terminal file browser, leverages this to do image previews in the term. It's quite cool! More details, including other methods, are described here: https://github.com/ranger/ranger/wiki/image-previews https://github.com/ranger/ranger/wiki/image-previews

a3n 10y ago
Hey, that even works in the console (ctl-alt-F[1-6]). I guess I shouldn't be surprised, but I am. Delightfully.
- digi_owl 10y ago
  As long as you use framebuffer consoles.
  - thom 10y ago
    As long as you're using a framebuffer, you might as well use netsurf-fb, which is a pretty modern browser.
    - digi_owl 10y ago
      On a lark i threw it at Reddit and found that it got the layout mostly right. But as it lacks JS support (no surprise there, JS is quite the beast) i could not do much beyond look at pretty pictures. Edit: Heh, threw it at HN and it worked fine for the most part. Trying to search just resulted in a blank page though. And throwing it at some news pages didn't exactly go "well" (and i reminded myself why i have no love for The Verge). Funny thing is that without all the JS and CSS to parse, even the biggest news sites came up in a matter of seconds.
digi_owl 10y ago
Best i understand you need to use a xterm derived terminal for this to work, because the sub-program used by w3m for this draws over the terminal window to make things happen. One more thing we can kiss bye bye with Wayland i guess.
- mrkgnao 10y ago
  It's curious how we're prepared to replace X (with people writing tiling WMs and the like that support it) but somehow the move away from xtermy things (and backwards-compatibility-all-the-way-back-to-way-back-when) hasn't really caught on much, at least on the Linux side of things yet. Any exciting work in this area? I'm aware of Black Screen and some other work on the Electron/rewrite-everything-in-JS front (Hyper, I think, is another). I've been using Alacritty myself for a couple of weeks now. It's not too bad: the htop header bar won't render properly and catting random binary files crashes the terminal pretty quickly, but it's smooth and does everything a good "tmux VM" should do well. I understand iterm2 on macOS is a significantly improved experience?
  - digi_owl 10y ago
    Could be because as of yet the meat of terminal, the tty, happens in the kernel. And the kernel devs, as last as Torvalds remain in charge, is not as magpie about chasing the latest shinies. Note however that there exist effort towards moving the tty into user space. And one leading figure in that is currently involved with systemd. So i suspect it will happen, it is just a question of when...
  - JdeBP 10y ago
    The "catting binary files" problem largely goes away when you use a terminal emulator that doesn't implement ISO 2022 escape sequences, or where ISO 2022 support can be and has been turned off. The mosh people made a big deal about this approximately five years ago. Their claim that only mosh is like this, still present on their WWW site, is not in fact true now. I say "largely" because there are a couple of other nasty escape sequences, like (for example) OSC sequences to set window titles and terminal names, that binary files can also accidentally contain and that therefore have to be disabled. Removing ISO 2022 makes the problem far less likely to be hit, but doesn't quite eliminate it entirely.
jdormit 10y ago
Does anyone know how to make this work with tmux splits? I tried setting this up but the images would be displayed across splits as if w3m was taking up the whole terminal.
knolax 10y ago
For anyone interested, I wrote a standalone bash script wrapper for it a while back https://github.com/knolax/dotfiles/blob/master/scripts/image.sh https://github.com/knolax/dotfiles/blob/master/scripts/image....

FreeFull 10y ago

I have written something similar before here: https://github.com/FreeFull/termimage https://github.com/FreeFull/termimage . My program though is just a simple toy, since it doesn't even consider the size on the terminal, and doesn't play animated gifs. On the other hand, the source code for my image viewer almost completely fits on my screen (if you ignore its use of libraries for terminal handling and image reading).

saagarjha 10y ago

Those using iTerm should try out imgcat: https://www.iterm2.com/documentation-images.html https://www.iterm2.com/documentation-images.html

stefco_ 10y ago
Agreed. There is even a matplotlib backend called itermplot[0] that uses iterm's image display capabilities, which, combined with iterm's tmux integration, makes developing scientific code on remote servers a dream. [0] https://github.com/daleroberts/itermplot https://github.com/daleroberts/itermplot
- saagarjha 10y ago
  Looks great! Now if only there was one for Mathematica…
- daleroberts 10y ago
  Glad you like it :)
daleroberts 10y ago
If you are using iTerm2 and doing computer vision / machine learning on images or working with large images, my tool called 'bv' has even more features and supports TMUX as well: https://github.com/daleroberts/bv https://github.com/daleroberts/bv It uses GDAL as a backend.

michaelmior 10y ago

pxl is another nice option https://github.com/ichinaski/pxl https://github.com/ichinaski/pxl

JdeBP 10y ago
It makes an interesting comparison to the others mentioned here. timg and pixterm both hard-wire the ISO/IEC 8613-6 control sequences for 256x256x256 RGB colour. Neither of them, as I have already mentioned elsewhere, optimize their output at all. pxl employs a far more complete third party library for its terminal rendering, named termbox. This has ncurses-style double-buffering for no-op redraw suppression and redundant colour control sequence optimization. It does not optimize as far as BSD SCREEN did in the 1980s, which made use of several more tricks to reduce the need for emitting lengthy cursor motion control sequences (such as carriage return, line feed, and the various relative-motion control sequences; and not optimizing away writing a character if it is shorter to just re-output the next cell position than to move the cursor). The downside of termbox is that whilst it supports 8-colour and 256-colour terminal types, and reads the TERM environment variable and terminfo entry to determine colour capability, it does not support 256x256x256 RGB colour and hardwires the 8-colour and 256-colour control sequences to ECMA-48 and ISO 8613-6 indexed colour control sequences rather than employing the appropriate terminfo fields, even though it reads the terminfo database. timg, pxl, and pixterm also only display 2 pixels per character cell, because they all use the same single Unicode character for rendering (making termbox, with all of its worrying about character widths and replacement characters, overkill to an extent). As mentioned by its author on this page, tv uses a whole bunch of the box drawing and block graphic Unicode characters for increasing the number of pixels per character cell. But whilst tv does both 256-colour and 256x256x256 RGB colour, it does not do 8-colour or greyscale like pxl does, and it completely ignores the terminfo database and the TERM environment variable.

xuhu 10y ago

Does this or any of the mentioned alternatives work over ssh ?

tedunangst 10y ago
ssh doesn't really care about your terminals capabilities. (Yes.)
JdeBP 10y ago
There is no real reason that any of them would not, SSH not involving decoding and then reëncoding terminal control sequences. The more relevant concerns would be whether they worked with tmux, screen, and mosh, which do involve that; and whether the terminal emulator on the local end of one's SSH connection supports 256x256x256 RGB colour control sequences. That said, one of the issues on timg's issues list deals in the sheer amount of superfluous data that are generated and that that thus have to be transmitted across an SSH connection or a serial device. There is no optimization of the colour change control sequences at all. pixterm similarly does zero optimization, but no-one has pointed that out yet. * https://github.com/hzeller/timg/issues/13 https://github.com/hzeller/timg/issues/13 pxl, mentioned elsewhere on this page, does optimize colour control sequences and indeed uses an ncurses-style double-buffer mechanism to optimize re-drawing.

executesorder66 10y ago

This is great. Since we are all posting alternatives, here's another: https://github.com/withoutboats/notty https://github.com/withoutboats/notty

digi_owl 10y ago

https://github.com/saitoha/libsixel https://github.com/saitoha/libsixel

FreeFull 10y ago
Note that most commonly used terminals don't support sixel graphics (The readme for libsixel has a list of some terminals that do have support), while a lot more terminals support 24-bit colours (all terminals that use a new enough libvte in particular, and some others).
- digi_owl 10y ago
  Same "problem" as the w3m solution mentioned in the top most comment right now...

digi_owl 10y ago

Just reminded myself of another option: https://github.com/cacalabs/libcaca https://github.com/cacalabs/libcaca

JdeBP 10y ago
The downside of libcaca is that it makes several presumptions that aren't necessarily true outwith the world of IBM PC Colour Graphics Adapter compatibility. For example, it has a tendency to abuse boldface black on black as a way to get a dark grey colour, making it not work so well on terminals where boldface really is a switch to a boldface font rather than brightening the foreground colour. On such terminals, black on black text is invisible, boldfaced or no. Sadly, it actually works internally in terms of a 4x16x16x16 ARGB colour system, and could work quite well with 88-colour or 256-colour terminals, and very well with terminals that have 256x256x256 RGB, were it not for the fact that most of the information in the internal colour representation is thrown away by the ncurses and CGA-like layers that are built on top of it.

iaml 10y ago

What's the difference with tv[0]? [0] https://github.com/daleroberts/tv https://github.com/daleroberts/tv

daleroberts 10y ago
Tv pushes the rendering further by using more unicode characters. It also uses GDAL as a backend which allows subsampling of massive images and access to many scientific image formats (GeoTiff, NetCDF, JPEG2000, etc)
- JdeBP 10y ago
  Some other differences are given at https://news.ycombinator.com/item?id=13906483 https://news.ycombinator.com/item?id=13906483 . One problem that all of these programs share is something that you cannot really do much about absent user-supplied information, since it is something that isn't exposed in the abstraction of a POSIX General Terminal Device. It is probably more acute for tv than for the others, albeit that as I have mentioned I couldn't get tv to actually run without error to see what the effect is. This problem is that there is a baked-in assumption about the glyphs of the characters. This is not the usual concern that glyphs are different shapes in different fonts. That's not really much of a concern for box drawing and block graphic characters. The baked-in assumption is that glyphs are rectangular, with a 1:2 aspect ratio. This is the assumption that underpins the idea that U+2580 is two square pixels, one atop the other. But this is not true even for 9x15 fonts, which yield a slight distortion with all of these programs, let alone for yet squarer fonts. Barack Obama looks very odd indeed when U+2580 is actually a 16x16 or 32x32 square, as it sometimes is. (http://fileformat.info/info/unicode/char/2580/fontsupport.htm http://fileformat.info/info/unicode/char/2580/fontsupport.ht... shows several square appearances, and it is square in one of the fonts that I use here.) tv, with the way that it already works, is probably best placed to incorporate user-supplied information about the font's character cell aspect ratio. pxl could probably be extended fairly simply, too. The others including timg, I suspect would be harder. Interestingly, M. Zeller has had an open issue about this for timg since 2016. * https://github.com/hzeller/timg/issues/4 https://github.com/hzeller/timg/issues/4

daleroberts 10y ago

TV gives even more interesting results as it uses more unicode 9.0 characters: http://www.github.com/daleroberts/tv http://www.github.com/daleroberts/tv

JdeBP 10y ago
But unfortunately for Debian 8 users, it is not compatible with the python3-gdal provided in Debian 8 and fails to work with a runtime error. Traceback (most recent call last): File "./tv", line 82, in <module> SAMPLING = {'nearest': gdal.GRIORA_NearestNeighbour, AttributeError: 'module' object has no attribute 'GRIORA_NearestNeighbour' * https://packages.debian.org/jessie/python3-gdal https://packages.debian.org/jessie/python3-gdal timg built and ran as-is on Debian 8 with the libraries that it needs.
- daleroberts 10y ago
  Thanks for telling me, it looks like Debian is using GDAL v1...

msollami 10y ago

gpicview anyone?

taeric 10y ago

For emacs users, you can get a similar thing with iimage-mode and eshell. Kind of cool to have "$ cat SomeImage.png" do what I would expect and put it in the terminal.

Klasiaster 10y ago

Some time ago a Rust version of these kind of programmes was presented here: https://github.com/nabijaczleweli/termimage https://github.com/nabijaczleweli/termimage A useful additional script: #!/bin/bash for i in `find $@` ; do termimage --size 150x33 $i ; done

LeicaLatte 10y ago

Currently using pixterm which works on any ANSI terminal. https://github.com/eliukblau/pixterm https://github.com/eliukblau/pixterm

JdeBP 10y ago
No, it does not. Like timg here, it only works on terminals that have 256x256x256 RGB colour, for which it hardwires the control sequences; and this is explained up-front in its doco. An "ANSI" terminal need only support ECMA-48, which has 8 colours; as can be seen from the terminfo entry for the "ansi" terminal type. "true colour" is ISO/IEC 8613-6. * http://unix.stackexchange.com/a/289871/5132 http://unix.stackexchange.com/a/289871/5132

frabbit 10y ago

FYI: "catimg" is available as a Fedora rpm.