If you're on MacOS an imgcat tool pairs well with an imgpbcopy tool like this:

https://github.com/williamcotton/dotfiles/blob/master/bin/im...

Then create a shell function like:

  imgc() {
    tee >(imgcat "$@") >(impbcopy -) > /dev/null
  }

So you can:

  cat image.png | imgc

Which will then show the image in the console, and if you switch over to another app you can simply paste in the image. And if you create a new file in Preview it will be the image in the paste buffer!

You could get better resolution in some terminals by using sixels: https://en.wikipedia.org/wiki/Sixel

I think there's some other methods in particular terminals for displaying images, but I don't remember them.

I was making a similar library (paired with a cli app) in Go a while back with some fun results -- it lead me down a rabbit hole trying to render animated gifs, which has interesting results depending on the terminal being used. I also implemented the resizing of the images to properly scale for the terminal as well. I never actually got around to uploading the repo, but will try to get around to that tonight.

Some videos of it in action: https://youtu.be/L2LTPKW6EPw https://youtu.be/b0CYZyuKLr8 https://youtu.be/_VnV96l5Xkc

I've been using viu, which is also written in Rust: https://github.com/atanunq/viu

How does imgcatr compare?

Viu was last updated 5 months ago, imgcatr 3 months ago, not a significant difference. imgcatr is a longer name than viu, requiring more keystrokes to type.

timg is a really nice similar tool that does pixel graphics in the terminal window if supported, falling back to character graphics if not.

The big plus is that it supports SVG images.

https://github.com/hzeller/timg

And it is available via brew/apt/etc.

While not CLI, I always look for cross platform image viewers and found https://github.com/woelper/oculante.

Had a few woes compiling it due to my laptops configuration, but once compiled it works with everything I would reasonably throw at it.

I've made one years ago, supporting gif

https://github.com/hsfzxjy/i2a-rs

I loved those image2text ever since I learned about libcaca http://caca.zoy.org/wiki/libcaca

I tried this two years ago when I was still actively 'learning' Rust: https://github.com/Dirout/depi

I love seeing how many people wrote one of these. I've written 2:

One to learn golang that plays gifs - https://github.com/moshen/gotermimg

And one in perl - https://github.com/moshen/Image-Term256Color

Terminology (part of Enlightenment) is a fantastic terminal and has image support.

https://www.enlightenment.org/about-terminology.md

It doesn't seem to work in macos terminal, but it's likely my term environment vars aren't set correctly.

I just get a whole pile of random colour, some of which are flashing.

If you use the kitty terminal you can use:

kitten icat image.jpeg

IMO the best results out there are with chafa right now. https://hpjansson.org/chafa/gallery/

It also has some basic ffmpeg support.

And yeah, there are sixels and native rendering of graphics in terminals, but I still find this handy if I'm a couple of tmux sessions deep on a remote server and I need to figure out which graphic is which.

I do a lot of work in the terminal. And every few weeks I'm wishing for something like "cat for images".

"I should write it!". And then realize it already exists and is on my machine. I presume most OSes and distro's have some simple image viewer. Mine, Ubuntu, comes with `eog`.

Very rarely, am I on a machine that has no display, and I still need to view some images that live there. Then the workflow becomes convoluted: transfer images to a local machine, or put them in some http-accessible place. For those cases, I think imgcatr would be great. But then it's not available on these machines, so that kindof defeats the purpose again.

It would be better if the images were more clear.

> cargo install imgcatr

I feel very uncomfortable seeing cargo being used as a tool to distribute software.

Cargo is a package manager.

It should build software.

I suppose it’s arguable that it should be able to install developer tooling to help you build things.

However, I feel uncomfortable seeing this type of thing.

Is the installed binary sandboxed? It is namespaced? Is it shared between projects? What causes it to be updated?

Can building a crate update the globally installed version of “foo” by “cargo install” installing a different crate that happens to have a binary with the same name? (Yes, via build.rs, but just as a dependency?)

How would I even know?

There are so many things wrong with this imo.

Building a crate should generally be sandboxed, but this (cargo install as a concept, not this particular app) feels like the goal is the opposite of a sandbox, instead it’s a shared arbitrary named tool that goes into your path by default and gets updated an unknown times.

I feel like this is going to bite the rust community in the foot at some point.

[dead]

[flagged]

[flagged]