Live data from Hacker News

Show HN: Sixel-tmux displays graphics even if your terminal has no Sixel support

github.com

71–80 of 89 posts

Re: Show HN: Sixel-tmux displays graphics even if your terminal has no Sixel support

#71

Earlier quoted context omitted.

https://saitoha.github.io/libsixel/ Looks to me like the limited pallete is mostly as XTerm limitation, but a limitation of the protocol.

From reading the protocol "spec" I do not see how it could be used to transmit 32 bit color (or higher). The spec describes 8 bit indices into a palette. I have seen no sixel tools that are able to output 32 bit color, or any sixel terminals that can display 32 bit color. But I could be misreading it. I haven't dug through all the code so if someone could show how this could be done, then we could start to change tho…

> I do not see how it could be used to transmit 32 bit color (or higher)

You are pushing the goalpost. I was talking about 24 bit color (2^24= 16 millions).

Now you are saying the lack of 32 bit color support is an issue?

Maybe let's start with 24 bit color, which is far more than what the human eye can discern anyway (about 10 million) even if we'd then have to talk about color spaces, and how 32 bit may be better for some specific applications)

Re: Show HN: Sixel-tmux displays graphics even if your terminal has no Sixel support

#72
post #69

Your rant and the issues around keeping an ecosystem pinned to a mess of incompatible tech reminds me of the time that mpng support was pulled/not merged into Firefox because it added too size of the binary. Which was then obviated by the first download of an animated gif. Petabytes in bandwidth and disk storage wasted because FF decided saving a couple hundred K on the png animation code. By not supporting sixels, i…

> Petabytes in bandwidth and disk storage wasted because FF decided saving a couple hundred K on the png animation code

Indeed, penny wise but pound foolish... and I guess they were proud of themselves!

> You are fighting the good fight.

Thanks, hopefully due to kicking the ant nest with my rants and now sixel-tmux, VTE will be forced to deliver something, anything really, even if it may be 6 years too late and not enabled by default (!!)

At least Linux distributions would have the possibility to compile it in?

But at this point, even that I can't believe. I think they will weasel out at the last minute with some half-baked more or less plausible excuse, like your example about firefox code increasing by a few kb.

My hopes for gnome are extremely low, so "I'll believe it when I can see it" and not before, say when it's shipping in Ubuntu.

Re: Show HN: Sixel-tmux displays graphics even if your terminal has no Sixel support

#73
post #60
post #12

Earlier quoted context omitted.

> Any insight into how this one compares to Alacritty and Kitty? In terms of customization and configuration, I'd say foot falls between Alacritty and Kitty with Kitty being the most customizable and configurable while Alacritty being the least. One of the things I really like about Alacritty and foot is that they don't enforce italic and bold monospace variants while Kitty does. I despise italic variants of monospac…

Hey; what do you mean by "force"? I mean, to me this reads like you don't want to see italic nor bold font in the terminal (due to lag of monospace support in that regard maybe). But I think having the possibility of italic, bold, bold+italic in the TE is a very good thing. And if you do not want that I think Kitty allows you to just use another font then; please correct me here, but I think that is configurable. Bol…

> And if you do not want that I think Kitty allows you to just use another font then

Do you really believe that's reasonable? That I should stop using my favorite monospace fonts just because a terminal emulator doesn't let me disable italic variants of that font when other terminal emulators like Alacritty and foot do?

I don't think that's reasonable and so I stopped using Kitty. And no, I'm not gonna resort to fontconfig hacks or manually delete the italic otf/ttf files. I'd rather use a terminal that gives me choice rather than imposes it.

Re: Show HN: Sixel-tmux displays graphics even if your terminal has no Sixel support

#74
post #70

Earlier quoted context omitted.

https://vt100.net/docs/vt3xx-gp/chapter14.html#T14-1 Am I reading this incorrectly? It seems I was wrong, it supports 8-bit color, not 6-bit color. But that's still terrible, and every Sixel implementation I've ever used has spit out dithered images. The only terminal that is able to display full color images for me is iTerm, using the iTerm escape sequences, which are different escape sequences from sixel. So again,…

> Am I reading this incorrectly? Yes > It seems I was wrong, it supports 8-bit color, not 6-bit color. Good. A positive first step is knowing when to admit error. > But that's still terrible, and every Sixel implementation I've ever used has spit out dithered images OMG, I spoke too fast, there you go again! I've given you a step-by-step guide to try the best terminal there is. > So again, please help out with fixing…

Imho there is some misconseption here, how the sixel protocol works for the colors part. It is not about any bit-depth of an image, as it is paletted. But other than most standard paletted formats, it can redefine its colors on-the-fly, which basically makes it supporting an infinite amount colors (it is still limited to 101³ colors in RGB space).

Now the actually tricky parts: The spec states (DEC STD 070), that the palette should be of size 256 at least on decoder side, and an encoder should not create more than 256 colors, and any higher palette index gets mapped back (not specced out, but mostly done with modulo). Older devices (old DEC printers or VTs) were even more limited in palette regards, from monochrome like VT240 to 16 colors on a VT340 for screen output. Thats what xterm does with `-ti 340` and it is totally right about it - it emulates what a VT340 was capable to do. What mlterm started to do (and others followed) - well it did not care for strict VT340 emulation, and increased the palette to 256 colors. Furthermore it applied "printer-behavior" (note - sixel was developed as printer protocol) deviating from DECs VT behavior by immediately applying colors to pixels. While DEC's sixel capable VTs always were bound to the fixed palette. That terminal vs printer behavior distinction is important, as it opens sixel to actually use more colors than the palette has room for by redefining color slots on the fly.

Hope this helps to get some details straight.

Re: Show HN: Sixel-tmux displays graphics even if your terminal has no Sixel support

#75

Sixel is a terrible encoding. Most of the newer terminals have escape sequences for sending base64 encoded png/gif/jpg--for higher quality output & lower bandwidth.

Which terminals support "escape sequences for sending base64 encoded png/gif/jpg" ? Thanks.

Re: Show HN: Sixel-tmux displays graphics even if your terminal has no Sixel support

#77
post #24
post #13

Earlier quoted context omitted.

The issue with Kitty is that its graphics protocol is not widespread yet, so some of the CLI/terminal programs OP uses that can do graphics output may only support sixel. But yea, personally looking forward to Foot terminal implementing one of the fancier graphics protocols, even if it feels more like a toy at the moment (until they are used more). But seriously running the notcurses[0] graphics test with a terminal…

> it feels more like a toy at the moment It's not! Gnuplot in the terminal open many new use cases, such as examining data on remote hosts with scripts without even bothering to scp the data first. Also, Notebooks in the terminal is wonderful! Check https://github.com/koppa/matplotlib-sixel As for kitty format, adding support in sixel-tmux is planned, but you are welcome to write a patch if you want it sooner! Imagin…

> It's not! Gnuplot ...

You misunderstood me, I was saying Kitty graphics protocol feels more like a toy in how well it can produce graphics (GIFs, videos, etc). Sixel is more common in actual use cases (at the moment). But, take notcurse's graphics demo for example, using the kitty backend, it's very unreal terminal experience. But once Kitty's graphics protocol has more widespread support, for example in graphing tools, it'll be just as useful as Sixel :)

Re: Show HN: Sixel-tmux displays graphics even if your terminal has no Sixel support

#78
post #14

Earlier quoted context omitted.

I'll probably regret writing this but if you read the entire rant, the author had been trying get sixel support into VTE based terminals (GNOME terminal and family) but he was blocked, which isn't really surprising considering the "my way or the highway" approach of GNOME devs towards anything that they make. The recent theming fiasco is a good example for this. He also tried getting sixel support in tmux but was rej…

Yeah, I think OP wrote must of what they did in genuine frustation. Saladuh's response probably comes mostly from having read this paragraph from OP's rant: "This is why I released sixel-tmux. That's also why I use Windows besides the wonderful mintty being the number 1 choice for terminal afficionados, it gives more options in general: I like that because I don't like depending on people who seem stuck in a desire t…

No, my 'rant' came from this section of this other rant[0], which is linked in the rant in OP's linked repo. I suppose I should have made this more obvious instead of assuming everyone would read the links provided in the whole rant (because I did indeed read the whole entire rant, and I agree with a lot of it, just not the part about windows being better than Linux and everyone who disagrees is a "millennial" seeking "geek cred", which originally misquoted in my 'rant').

[0] https://github.com/csdvrx/cutexterm#wait-i-thought-people-sa...

Re: Show HN: Sixel-tmux displays graphics even if your terminal has no Sixel support

#79
post #11

OP, your rants are pretty subjective and imo come from a place of windows fanboy-ism (before someone reports this comment for flame baiting, go read both of OP's rants in the repo, they're far worse). I came to Linux last year, and I've been on it 100% no windows during this entire period. I'm using Sway (Wayland), a DE (well, really just a window manager) you cannot replicate in the windows graphical environment, an…

I read the rant and did not see the windows-fanboyism you suggest, on the contrary, they wish that a big chunk of the terminals used in Linux get support for a feature, and they do not just complain, but they actually do something for making things better. So I'm not sure your rant is warranted nor makes it much sense in this context, or is this some copy-pasta I failed to recognize?

No, my reasoning for the 'rant' is explained here: https://news.ycombinator.com/item?id=28769793

The rant in this repo links to a related rant in another one of the author's repos: https://github.com/csdvrx/cutexterm#wait-i-thought-people-sa...

Re: Show HN: Sixel-tmux displays graphics even if your terminal has no Sixel support

#80
post #32
post #25

Earlier quoted context omitted.

Hard forks rarely get traction and are almost always lost in obscurity, unless the original project itself is abandoned. tmux isn't abandoned so I doubt this fork will end up being used by more than a handful of people. EDIT: Yup, as suspected, the author doesn't intend to keep his fork updated with upstream and I don't blame him for that. This essentially makes this fork a proof of concept, nothing more. Unless it g…

Thanks for being understanding. To be honest, Windows fangirl? guilty as charged! But I try to keep my personal opinions separate, which is why my rants are on a separate page. Still, you nailed it: sixel-tmux was made to try to help correct the direction that has been taken, with 6 years wasted. I believe it's unfair that Linux users have fewer options than us Windows users, due to some people thinking sixel is "unc…

Apologies for misgendering you. My opinion that you come off like a windows fangirl was mostly due to the other rant you linked in the sixel-tmux rant: https://github.com/csdvrx/cutexterm#wait-i-thought-people-sa...

Here you mention some other things unrelated to terminals, and I was mostly addressing those. It seems to me you want a specific type of experience on Linux, but you can't get that, so therefore dismiss the merits of Linux. I think a lot of your impressions on Linux come from using an X11 based setup instead of Wayland. Completely different beasts, and I think a lot of your grievances would be solved by the latter.

For me, I cannot go back to Windows, ethical reasons aside: Sway on Wayland is perfect for me, and it's what I want out of my computing experience.

I actually agree with a lot that is written in those rants, particularly the VTE and gnome terminal situation. It's just your comments on windows vs linux came across as very personal imo, so I suppose I have retorted here with also a somewhat personal rant.

Also, I don't think either platform has many good terminal choices. Besides mintty, I don't think there are that many good (platform exclusive) terminal emulators on Windows. And on Linux, Foot is one of the few that meets my criteria, including top tier Sixel support (though Wezterm meets my criteria too if it wasn't so slow, hopefully it gets faster). But, for example, I could never really like mintty if I was forced to use Windows, because it lacks features I want.

What I'm trying to say: different needs, different use cases, different tastes. Sorry that my original rant came off so negatively to you and that I wasn't able to convey this point I was trying to make.

Post reply on HN