Package

[schvabodka-man]

Are there any plans for making deb/rpm packages?

[atextor]

There are no immediate plans, although I think it would be great to provide packages. I probably won't have time to take a look at that for at least another few weeks, but if anyone is willing to send a pull request...

[suve]

icat is now available in the main Fedora repository.

[Bandie]

takes over the AUR
https://aur.archlinux.org/packages/icat/

[ottok]

I could maybe package this for Debian, but can you quickly brief how this is better than catimg?

https://manpages.debian.org/buster/catimg/catimg.1.en.html

[atextor]

Hi @ottok,
as far as I see it, both commands are fairly similar:

• Both use half-width unicode chars to match pixels (icat by default, for catimg a switch is required)
• Both can map to 256colors or use 24 bit color escapes (icat uses 265colors by default, catimg uses 24bit by default)
• Both automatically scale down large images
• Both can read images from stdin

The differences are:

• catimg can display gif animations, while icat can't
• icat has a switch to force no resize while catimg hasn't
• icat has switches for specifying x and y coordinates while catimg hasn't

If you don't consider the last two bullets "makes icat better than catimg" then it isn't :)
(FWIW, icat was first published may 2012 while catimg was first published december 2014...)

[ottok]

Thanks for the summary! Displaying animated gifs is pretty useless, it will just scroll the screen a lot and I can't come up with any productive use cases for that. Using 256colors seems like a more compatible approach and using unicode pixels by default sounds like a good idea.

[ottok]

Visually the 24bit output is identical, at least on my gnome-terminal.

How do I enable the unicode "pixels"?

[ottok]

I found icat via https://twitter.com/thingskatedid/status/1286559756967002113 - the unicode pixels visible in that image? Seems to me so, they are so small.

[atextor]

It think it's to be expected that both icat and catimg -- using the same unicode characters and the same color values -- display the image identically.
I've seen that Twitter thread and I assure you I was confused at first for two reasons: (1) The icat from this repository here can't do that, it only prints the characters ▀ and ▄ in the right colors. (2) There actually is a version of the icat from this repository here that can print actual pixels, you can see that in the last screenshot on this blog post: https://atextor.de/2012/04/20/the-quest-for-the-next-generation-power-user-interface.html
However, I never released it because it was horribly broken when the terminal scrolled, so how could they have used it in these screenshots?
The answer is simple: The icat from the thread is a totally different program that's just also called icat. It's a command that comes with the "kitty" terminal emulator: https://sw.kovidgoyal.net/kitty/ If you take a look at the "kittens" section (the name for their helper programs) you'll find their icat. It produces a non-standard escape sequence that only that terminal emulator will understand to display the image inline. That's not unlike Enlightenment's Terminlogy terminal emulator that also comes with its own image printing command: https://www.enlightenment.org/about-terminology.md
We had the whole "how can I print actual images in the terminal" discussion before, and there are some more options linked there, notably libsixel: #13 (comment)

Fun Fact 1: I originally wrote icat during the research leading to the above blog post, which was frustrating to say the least. It's now 8 years later and there still is no method widely supported by the most relevant terminal emulators (let's say gnome-terminal, konsole and urxvt). Personally I think kitty is technically the best option right now. As you see, this here icat predates all of catimg, kitty's icat and terminology. I never seriously pursued packacking and getting it into distro's repos because frankly, how useful are those pixelated images anyways? It's just the lowest common denominator that works in most terminal emulators (not even all, looking at you screen and $TERM).

Fun Fact 2: Kitty relies on OpenGL >3 for rendering, which is readily available unless you try to run it in VirtualBox because VirtualBox does not support that API, even for simple 2D applications. I know because I'm using Linux inside a VirtualBox at work.