lsix: ls for images • Hacker News Board

Re: lsix: ls for images

#71

Post by xzfc » Thu, Dec 27, 2018, 7:41 AM UTC

cyphar wrote: post #31

isomorphic wrote: post #22

Aside: Although iTerm2 (on macOS) doesn't appear to work with this, iTerm2 actually supports full-color inline images, and has an "imgls" script which does something similar. (There's also "imgcat".) https://www.iterm2.com/documentation-images.html

This is because iTerm2 doesn't support sixels (which is part of a VT standard I believe), and instead has its own custom version of the same thing.

Not quite the same. iTerm provides escape sequence to inline base64-encoded images in a common format (e.g. PNG)[1] whereas Sixel is an it's own image format.

I find iTerm's approach is more simple yet more powerful: better compression, thus faster; no dithering, thus better image quality; it's even have GIF support. Sixel is an 30 year protocol designed for matrix printers, i'm not sure why we should stick to it. I think terminal emulators should adopt iTerm escape sequence rather than Sixel.

Aside of iTerm, image inlining is supported in Terminology[2]. Not sure about compatability with iTerm however.

[1]: https://www.iterm2.com/documentation-images.html

[2]: https://www.enlightenment.org/about-terminology.md

Re: lsix: ls for images

#72

Post by pmarin » Thu, Dec 27, 2018, 7:56 AM UTC

gnachman wrote: post #60

geofft wrote: post #35

Earlier quoted context omitted.

hterm, the terminal emulator portion of the Chrome (OS) Secure Shell app, supports them. (Aside: I dislike the vagueness of the term "proprietary." I rarely hear anyone call the non-ANSI VT-100 or xterm sequences "proprietary," even though they got started in exactly the same way as iTerm2's.)

Some day they'll be standards and I'll change the documentation to say "perfectly normal" instead of "proprietary" :)

It's probably a matter of writing a proper RFC like document.

That is how standards should be made.

Re: lsix: ls for images

#73

Post by shocked-pikachu » Thu, Dec 27, 2018, 8:02 AM UTC

isomorphic wrote: post #22

Aside: Although iTerm2 (on macOS) doesn't appear to work with this, iTerm2 actually supports full-color inline images, and has an "imgls" script which does something similar. (There's also "imgcat".) https://www.iterm2.com/documentation-images.html

_imgcat_ example shows a dog

Re: lsix: ls for images

#74

Post by emmanueloga_ » Thu, Dec 27, 2018, 8:09 AM UTC

lbj wrote: post #6

How does the tech work? You have something like a 80x50 display and he's emitting 128x128px on that?

By now a lot of ppl have commented on the tech (sixel) but it really annoys me when projects don't explain in simple terms the overall workings in the readme:

"lsix is a shell script that uses ImageMagick convert tool to list images on a shell screen on terminals that support the Sixel format"

There, was that so hard?!? :-(

EDIT: oops, it does mention it, everywhere actually. 1) need to pay more attention but 2) I was just venting because of so many other repos I have to spelunk to have answers for when a few words in the readme would do :-)

Re: lsix: ls for images

#75

Post by quickthrower2 » Thu, Dec 27, 2018, 8:13 AM UTC

Nice, but by the time you want to do this, why not use a GUI file explorer with image thumbnails

Re: lsix: ls for images

#76

Post by bmn__ » Thu, Dec 27, 2018, 8:53 AM UTC

jchw wrote: post #67

a1369209993 wrote: post #66

Earlier quoted context omitted.

GIMP offers ASCII art as a target, and that's expected by line printers/teletypewriters; does that mean TXTs can be images?

Yeah, you just described how too. KDE used to thumbnail txt files with a portion of their actual text.

Still does.

Dolphin → Settings → Configure Dolphin… → General → Previews

Re: lsix: ls for images

#77

Post by laumars » Thu, Dec 27, 2018, 8:53 AM UTC

fouc wrote: post #33

isomorphic wrote: post #22

Aside: Although iTerm2 (on macOS) doesn't appear to work with this, iTerm2 actually supports full-color inline images, and has an "imgls" script which does something similar. (There's also "imgcat".) https://www.iterm2.com/documentation-images.html

>iTerm2 extends the xterm protocol with a set of proprietary escape sequences. I wonder if any other terminal uses the same escape sequences. If not, why not?

It’s worse than that, there’s other shells that support their own ANSI escape sequence for transferring base64 encoded images: kitty (not to be confused with KiTTY - the PuTTY fork) and Terminology (of enlightenment DE) each have their own “standard” and they differ from iTerm2’s. They all have their own CLI tools too.

Then there is sixel - which solved a problem back when TTYs were VDUs but aren’t really suitable for a modern era where it’s all terminal emulators running on (U)HD displays. I don’t think sixel support is all that widespread though but happy to be corrected there.

What we really need is one CLI tool to rule them all. One tool that will detect the shell you’re using and default to the best escape sequence for that shell; falling back to ASCII art when all else fails.

This is something I’ve been actively working on in some of my spare time but it’s not ready for public consumption, yet....

Re: lsix: ls for images

#78

Post by benj111 » Thu, Dec 27, 2018, 8:53 AM UTC

aasasd wrote: post #49

theoh wrote: post #5

Earlier quoted context omitted.

It uses various Imagemagick tools (Imagemagick supports sixel). Nobody manipulates binary files/pixel data in bash, do they?

> nobody That's a strong word you have there.

I'd like to think that it was a trap (that floating atoll at least fell in to).

This time next year we'll be reading about Bixel (free to use if you build it), the new hotness in binary and pixel editing.

Re: lsix: ls for images

#79

Post by osiutino » Thu, Dec 27, 2018, 8:57 AM UTC

xzfc wrote: post #71

cyphar wrote: post #31

Earlier quoted context omitted.

This is because iTerm2 doesn't support sixels (which is part of a VT standard I believe), and instead has its own custom version of the same thing.

Not quite the same. iTerm provides escape sequence to inline base64-encoded images in a common format (e.g. PNG)[1] whereas Sixel is an it's own image format. I find iTerm's approach is more simple yet more powerful: better compression, thus faster; no dithering, thus better image quality; it's even have GIF support. Sixel is an 30 year protocol designed for matrix printers, i'm not sure why we should stick to it. I…

I used the imgcat trick in my shell client project (https://github.com/u59u75u65/hkgbox-rs). I was looking for a cross platform solution, but by the time I worked on it I didn't know Sixels. One of the things that is cool about imgcat is that it handles GIF animation by default.

Re: lsix: ls for images

#80

Post by theoh » Thu, Dec 27, 2018, 9:05 AM UTC

floatingatoll wrote: post #55

aasasd wrote: post #49

Earlier quoted context omitted.

> nobody That's a strong word you have there.

They have a point - I can’t find any traces of a shell library implementing image parsing without calling out to a third-party tool written in not-shell. You also have a point - I’m seriously debating if I can write one in an evening solely to say that one now exists. (I lost the debate with myself, sadly.) EDIT: I mean “source language bash”, not “target language bash”, my emscripten friends.

There are problems with the manipulation of binary data in bash, as discussed here: https://unix.stackexchange.com/questions/278639/how-can-i-wo...

In particular, the value 0 can't be stored in a bash variable, which almost completely rules out the possibility of byte-by-byte processing of general binary data. It's probably possible with absurd hacks.

Quite apart from that, error handling in bash is an awkward chore which few scripts get right. It's a very unappealing language for writing anything more than a five-line script. https://www.davidpashley.com/articles/writing-robust-shell-s...