A terminal image and video viewer.
In this release, there have been dedicated renderers for SVG and PDF added, based on librsvg and poppler.
If compiled-in, these provide higher quality rendering than the default, which falls back to graphicsmagick. On terminals with high-resolution output, this now allows to nicely read PDFs (on a large terminal, reading whole papers with -U --grid=3x1 --auto-crop is very readable). Thanks to @lromor for re-adding --auto-crop for PDFs.
SVGs are now also shown in the highest resolution as the vector format is rendered into the available space. With -U, you get crisp, large renderings.
We're getting closer to timg being a universal document and image viewer.
Note, the app-image in the release files is a minimal build that does not include SVG and PDF rendering. For that, compile timg yourself or use it as provided from your OS distribution.
TIOCGWINSZ completely and don't emit ws_xpixel and ws_ypixel, but happen to implement terminal esccape code \e[16t. This means that showing animations and columns in these terminals now work (this was the case for the VSCode terminal, but maybe others).(Note, the provided AppImage only contains a build without video decoding to keep it small. For a fully-featured timg, use the binary provided by your distribution or compile it yourself)
No functional change
High resolution image support in tmux (#95). On the Kitty terminal with tmux (>= version 3.3) it is now possible to show images in the terminal multiplexer (works on Kitty 0.28.1, but avoid 0.29.0 due to a bug).
timg --help is now an integrated manpage. This will allow AppImage users to see the documentation without the installed manpage. If you have not looked at the manual page yet, now is a good time to discover it :)
The file list allows to read image filenames from a file. This is very useful if you want to give timg more filenames on the command line than the shell allows you :). This feature has been around for a while, but it now comes in two flavors that determine how relative paths are treated in these files. A relative path is one that is not originating from the root of the filesytems, e.g. img/foo.jpg. There are two options -f and -F that influence that behavior.
-f filenames are resolved relative to your current directory. So just like if you invoked timg img/foo.jpg
-F filenames are resolved relative to the directory the file list is in. So so if you have a file list in some directory and it contains filenames of the form img/foo.jpg, these files will be resolved relative to that directory, not wherever your current shell currently is.Note, this changed from before: There was no -F option, and -f was behaving like -F is now. But since -F is confusing unless explicitly chosen, this backward incompatible change had to be introduced.
And finally: there is an timg AppImage now in the release section to quickly test out new versions (#103). AppImage is a package format that allows to use an application on almost all Linux distributions out-of-the-box.
The AppImage is meant to be small and has not everything compiled in, e.g. it does not contain full video decoding or all image imports that ImageMagick does support (Otherwise, the binary would be more than 100MiB large). But even with that, most common tasks work well (*.png, *.jpg, animated gifs, *.qoi,...) and is a good starting point to decide if you want to install it with your regular distribution package manager; some of them packagae timg regularly.
This release adds sixel support, it can be selected with --pixelation=sixel or, short -ps.
The sixel support has been tested with xterm (invoke with option -ti vt340), mlterm, xfce4-terminal (compiled with latest vte that allows for sixels) and alacritty-sixel.
Typically, you'd need to provide the -ps option if you want to test sixel output as auto-detection is currently only supported for xterm and mlterm.
Other than that, some few refinements here and there, faster compression for --pixelation=kitty and --pixelation=iterm2.
In this maintenance release, the QOI image format has been added. Also a few bug fixes, such as handling SVG transparency properly.
No functional updates, just improving compilation with latest ffmpeg.
%f-filename, %b-basename, %w-image width, %h-image height #67No code changes, just more fine-grained cmake choices.
No code changes since 1.4.0, just updates to cmake files (being able to work with older cmake versions) and documentation.