
Timg – Terminal Image Viewer - setra
https://github.com/hzeller/timg
======
coleifer
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)

~~~
digi_owl
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
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
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...

------
saagarjha
Those using iTerm should try out imgcat:
[https://www.iterm2.com/documentation-
images.html](https://www.iterm2.com/documentation-images.html)

~~~
stefco_
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
Looks great! Now if only there was one for Mathematica…

------
daleroberts
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
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
Thanks for telling me, it looks like Debian is using GDAL v1...

------
digi_owl
Just reminded myself of another option:

[https://github.com/cacalabs/libcaca](https://github.com/cacalabs/libcaca)

~~~
JdeBP
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.

------
executesorder66
This is great.

Since we are all posting alternatives, here's another:

[https://github.com/withoutboats/notty](https://github.com/withoutboats/notty)

------
digi_owl
[https://github.com/saitoha/libsixel](https://github.com/saitoha/libsixel)

~~~
FreeFull
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
Same "problem" as the w3m solution mentioned in the top most comment right
now...

------
FreeFull
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).

------
iaml
What's the difference with tv[0]?

[0] [https://github.com/daleroberts/tv](https://github.com/daleroberts/tv)

~~~
daleroberts
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
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.ht...](http://fileformat.info/info/unicode/char/2580/fontsupport.htm)
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)

------
captn3m0
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)

------
Klasiaster
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
Currently using pixterm which works on any ANSI terminal.
[https://github.com/eliukblau/pixterm](https://github.com/eliukblau/pixterm)

~~~
JdeBP
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)

------
taeric
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.

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

~~~
JdeBP
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.

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

------
michaelmior
pxl is another nice option

[https://github.com/ichinaski/pxl](https://github.com/ichinaski/pxl)

~~~
JdeBP
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.

------
msollami
gpicview anyone?

