Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

61–70 of 89 posts

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

#61

Post by rashil2000 »

csdvrx wrote: post #59
rashil2000 wrote: post #54

Earlier quoted context omitted.

Wow, I'd been dying to make tmux work on WT. I couldn't get your tmux.exe executable to work (it froze WT, in both bash and cmd). However, the script method works!

I thought you might be having this issue, which is why I tried to be very explicit. It's due to a cygwin and how /dev/cons* are different from /dev/pty* cf https://cygwin.com/pipermail/cygwin/2020-May/244878.html I've tried to explain that a bit better in server-client.c (check line 251) to give the user a clue of what's happening with *cause = xstrdup(c->ttyname) Unfortunately, even in 2021, properly configuring a t…

Oh, I apologize! I was under the impression that your executable would work without the /usr/bin/script workaround. My bad! I was aware of the Cygwin's tmux quirk, but not the script workaround. Thanks again for the detailed help!

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

#62

Post by speeddemon »

csdvrx wrote: post #57
speeddemon wrote: post #53

Earlier quoted context omitted.

>Not with 16 million colors. That's what 24 bit color mean (2^16) also called "truecolor" mode >Try to use sixel to play videos in mintty, with 24 bit support so palettes aren't a problem. You are confusing sixel with the iTerm image protocol which is different. Sixel is a really old and outdated, inefficient protocol that only supports uncompressed 6-bit paletted images. It would be best if we could just stop talkin…

> You are confusing sixel with the iTerm image protocol which is different. No I'm not. > Sixel is a really old and outdated protocol that only supports 6-bit paletted images. No it doesn't. sixels can be 16 million colors, that's precisely what the snake.six outputs tests: if you can't see the precise degradation of the snake skin greens and yellows, your terminal is broken. With so many bad terminals, it's no wonde…

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, please help out with fixing this for me if you know how. Because so far you have not adequately explained what is going on here, or corrected any misconceptions, or helped to fix anything that is wrong with these terminals. And even the various libsixel examples seems to show dithering: https://github.com/saitoha/libsixel

If I'm confused then you could be in a great position to help me out, so please explain what apparently myself and the libsixel authors are both doing wrong. Then maybe at some point in the future I could help you out and return the favor.

And there are also other problems with the iterm escape sequences that I suspect will prevent you from correctly implementing them in tmux (see here: https://gitlab.com/gnachman/iterm2/-/issues/3898). So all paths point towards needing to make some new protocol for this. You may be in the best position to do that too.

>Intel macs can run Windows natively. You've also got your pick of emulators, from parallels to vmware, if you roll that way.

I'm not going to dual boot Windows or use a VM just to use a terminal emulator for a couple minutes, sorry. If you could just explain what that terminal does that's special so that it could be implemented in other terminals, or show a video, that would help.

>What you've written makes about as much sense as saying a drawing program should stop trying to support BMP format since it will have to be replaced down the line by JPG or PNG. gimp, paint and others support many formats. Nobody is complaining. People just click on open. They don't care about the underlying formats.

If GIMP was attempting to pressure other projects to output BMP files then yes, that would be a problem. I suspect other projects wouldn't go for that just because they asked.

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

#63

Post by csdvrx »

trapnii wrote: post #60
_2paq wrote: 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…

> Some people like it bold, some people like the color to be intensified instead when using `SGR 1` (which is responsible for making font intensified/bold).

Indeed, and the right solution is a config options, just as was done in Windows Terminal, since nobody is wrong: it's just a matter of preferences!

The right technical way of handling preferences is offering more choices to the users, with some sane default that will satisfy most users.

Personally, I love italics (I use vim and I want comments shown in italics, and I make an heavy use of bold+italics, cf https://github.com/csdvrx/indent-rainbow/blob/main/after/syn... ) but I would not want to force this option to people who don't want italics, for their own reasons that are none of my business (actually, if they reasons are good enough, it may cause me to change the default choices, but I would never remove the user freedom to make such choices in the first place)

IMHO that's the key difference between MacOS/iOS/Gnome/new school linux on one side (fewer freedoms) and Windows/KDE/old school Linux (more freedoms)

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

#64

Post by csdvrx »

kzrdude wrote: post #56
csdvrx wrote: post #24

Earlier quoted context omitted.

> 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…

A matplotlib backend isn't even needed, just a cool piece of info, it's possible to extend ipython and/or jupyter console to display pngs and svgs with sixels (and/or kitty graphics, dynamically). I have code lying around for this.

Wonderful! Thanks for the info!

I have to check the current state of rstudio/ipython console support with sixels: doing everything from the terminal is a luxury I want in 2021, especially now that hidpi/4k screens are becoming mainstream :)

Last time I tried in uni on a "new" Thinkpad R52 (well, new for me as it wall already over 10 years old, but it had such a glorious 1400x1050 display!) quite a few things were missing.

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

#65

Post by speeddemon »

misnome wrote: post #51
speeddemon wrote: post #36

Earlier quoted context omitted.

>This is such a good read. I really like their project and their motivation. I can't agree. Like most rants, I found it to be very needlessly emotional, lacking in the technical department, and motivating towards the wrong goal (trying to fight and argue with maintainers, accusing them of negative things like "holding users hostage", etc) rather than doing the right thing for users (delivering new and useful features…

> I can't agree. Like most rants, I found it to be very needlessly emotional, lacking in the technical department, and motivating towards the wrong goal It's titled as a rant, in a file called RANTS.md, and unless you've gone out of the way to read it, the rest of the immediately available documentation looks to be perfectly professional and courteous. I'm not sure what you are expecting? I dislike when this sort of…

I'm asking for people to stop posting these rants. There's nothing wrong with scratching an itch, but the rants are just inflammatory and cause drama. I have never personally found them to be an adequate documentation of governance issues, and it almost always seems to devolve into a "he said she said" type of situation. Every time I've dug into an issue (this one included) the rant is way off-base with what is actually happening, and when I push back on it the developer just starts getting hostile at me and further fanning the flames. So it's not really useful to try and dismiss this by saying "oh it's just one piece of documentation you don't have to read it," my point is that people are still using these bad attitudes to inform themselves when that's a destructive thing to do. I mean, come on, someone just posted this in an HN comment. If you want to vent to your friends about how you think someone is a jerk then just do that, but it hurts me when that gets dumped in front of me as someone who's just try to comment on these issues and get my terminal fixed.

Open source in general has a problem with this, if it's left unchecked it leads to toxic behavior very quickly. That's my experience anyway. Traditional diplomacy doesn't help because some people seem to see open source as a "I can do whatever I want" type of thing, which it is. It's fine to do whatever you want in your free time but once you combine that with an attitude of "I will never change my mind or stop ranting" then is when it gets destructive and harmful towards someone who is trying to build a community and convince other projects to collaborate and adopt a shared standard. So if that's the goal then the ranting and bad attitudes need to stop. (Full disclosure: I'm saying this as someone who used to rant quite a lot, and damaged many relationships over it. It felt good for me but it made everyone around me become distrustful of each other)

If you want to downvote me again then that's fine, but if you have something to say then please reply. A downvote or an upvote can't mend a broken relationship like a strong conversation can.

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

#66

Post by traverseda »

speeddemon wrote: post #62
csdvrx wrote: post #57

Earlier quoted context omitted.

> You are confusing sixel with the iTerm image protocol which is different. No I'm not. > Sixel is a really old and outdated protocol that only supports 6-bit paletted images. No it doesn't. sixels can be 16 million colors, that's precisely what the snake.six outputs tests: if you can't see the precise degradation of the snake skin greens and yellows, your terminal is broken. With so many bad terminals, it's no wonde…

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,…

https://saitoha.github.io/libsixel/

Looks to me like the limited pallete is mostly as XTerm limitation, but a limitation of the protocol.

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

#67

Post by speeddemon »

traverseda wrote: post #66
speeddemon wrote: post #62

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,…

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 those sixel implementations to do the right thing.

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

#68

Post by kzrdude »

csdvrx wrote: post #64
kzrdude wrote: post #56

Earlier quoted context omitted.

A matplotlib backend isn't even needed, just a cool piece of info, it's possible to extend ipython and/or jupyter console to display pngs and svgs with sixels (and/or kitty graphics, dynamically). I have code lying around for this.

Wonderful! Thanks for the info! I have to check the current state of rstudio/ipython console support with sixels: doing everything from the terminal is a luxury I want in 2021, especially now that hidpi/4k screens are becoming mainstream :) Last time I tried in uni on a "new" Thinkpad R52 (well, new for me as it wall already over 10 years old, but it had such a glorious 1400x1050 display!) quite a few things were mis…

Thank you yourself for working on sixels and other things for image support in terminals. I've seen your work before and it's quite inspiring. :)

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

#69

Post by seg_lol »

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, it forces people to use a whole browser to show images. Graphics support in the terminal is more than just QoL for the users, it is also a power savings and a hardware lifetime issue.

You are fighting the good fight.

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

#70

Post by csdvrx »

speeddemon wrote: post #62
csdvrx wrote: post #57

Earlier quoted context omitted.

> You are confusing sixel with the iTerm image protocol which is different. No I'm not. > Sixel is a really old and outdated protocol that only supports 6-bit paletted images. No it doesn't. sixels can be 16 million colors, that's precisely what the snake.six outputs tests: if you can't see the precise degradation of the snake skin greens and yellows, your terminal is broken. With so many bad terminals, it's no wonde…

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 this for me if you know how.

I HAVE TOLD YOU AT LEAST 4 TIMES: YOU NEED TO USE A STATE OF THE ART TERMINAL TO FIRST CORRECT YOUR MISCONCEPTIONS.

Then if you are speaking in good faith, we will talk again.

> Because so far you have not adequately explained what is going on here, or corrected any misconceptions, or helped to fix anything

I'm at a loss. I can't hold your hand while you install msys2 so you realize yourself you were wrong, just like you did with the 24 bit colors which you wrongly assumed to not be supported by sixels.

Let's try a Bayesian approach: considering you have been proved wrong, you should update your priors and consider the likelihood of being wrong again is greater than me being wrong, since I have 1) quite an experience with sixels 2) so far I've been proven right.

> I suspect will prevent you from correctly implementing them in tmux (see here: https://gitlab.com/gnachman/iterm2/-/issues/3898)

You are pointing me to a 6 years old bug report about tmux eating sequences important to display sixels, which funny enough is the original concept behind sixel-tmux: click on my profile and you will notice "Show HN: Sixel-tmux, display graphics because it does not eat escape sequences" by csdvrx on Nov 27, 2019

I agree it was a serious issue, enough to motivate me. I didn't know it was also affecting iterm. At least I learned something too from this exchange, thanks a lot!

> So all paths point towards needing to make some new protocol for this. You may be in the best position to do that too.

All path point toward you mixing up terminal issues and sixel issues, not using the right tool, refusing to even try to use the right tool.

But yes, a few of us are in a position to push for better standards. I think @christianparpar and @hpa have the deepest understanding of the alternative standards. Eventually a few standard may emerge... or not. It doesn't matter. BMP, GIF, PNG and JPG can all coexist, each have their pros and cons. There's no need to make a choice when all apps support loading and saving in the user favorites formats.

> I'm not going to dual boot Windows or use a VM just to use a terminal emulator for a couple minutes, sorry.

Then I'm not going to try to explain you what you are understanding in a wrong way, as only seeing how mintty handle sixels WITH YOUR OWN EYES may correct your misconceptions at this point.

> If you could just explain what that terminal does that's special so that it could be implemented in other terminals, or show a video, that would help.

Click on the url and you'll see a few demos, including the snake.six displayed in a wonderful example of 24 bit "truecolor" support.

Your request to add a video showing how mintty handle font changes seems resonable. It will make a nice addition to sixel-testsuite.

> If GIMP was attempting to pressure other projects to output BMP files then yes, that would be a problem

If other projects did not even support BMP, but only knew about drawing ASCII art with a 8 colors palette, yes, refusing to implement BMP in 24 bit mode as a first step, while spending 6 years debating the best way to achieve the perfect format that will have absolutely no drawback (chasing a wild goose) would indeed be a problem...

Post reply on HN