81–89 of 89 posts
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.
Earlier quoted context omitted.
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" seekin…
But yes, I do believe people claiming that Linux offers the best terminal experience are either doing that for social credit and validation of their peers (in an "emperor has no clothes" way) or due to misinformation and a lack of personal experience with alternatives (in a "micro$oft only knows embrace, extend, extinguish" way)
Some do that for both reasons, and I'll let you make your own conclusion about their demographic group.
Earlier quoted context omitted.
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 t…
However, I think my expectations and opinions on terminals are quite fair, and that most people would enjoy an equivalent of mintty if there was one on Linux: it has been polished by years of adding small functionalities that adds up to make a whole that's greater than the sum of the parts.
You seem to generally agree with my takes, so I'm curious, what is lacking in mintty for your own uses? Personally, the only missing functionality that I sometimes regret is tab support.
As for platform exclusives, Windows Terminal has great tab support and is right now the best terminal for someone who doesn't need sixels: the ability to configure different shells ("profiles") is by itself quite admirable. The attention to details (SGR1) and configurability of said details seals the deal: different colors for different tabs of different profiles, so you don't mix your remote sessions!
As for Wayland, I can't say. I may have tried it for 10 minutes or 1 hour then found limitations, and decided it may not give the best argument in favor of Linux so I'd rather skip it. I will try Linux again in 2022, and I'll spend time with foot since everyone seem to love it, so I'll give another try to Wayland!
Besides having a great terminal experience (as I do most of my work there), one of the silly details that matters to me the most is having a consistent white theme which both removes the perception of reflections on glossy displays in the daytime, and allows an easy dark mode if you do a screen inversion + a red shift at the night time. NegativeScreen is a gem to do that on Windows: night mode for every app as soon as you press a button!
If I can't do that on Wayland (no more xrandr) like I do on Windows, the lack of support for themes in future gnome versions worries me, as pure white themes (for eInk) and pure black themes (for OLED) are extremely rare by default.
Still, I would love to be able to use Linux, because I love ZFS, but so far the terminal experience and the UI have kept me firmly in Windows land.
I'll see how the situation evolves... if it doesn't change enough, I may do something weird, like a GPU passthrough with everything on Windows, storage on a zvol handled by Linux as the virtualizer.
Earlier quoted context omitted.
> 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…
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…
>Good.
Please avoid these snarky responses, this is not helping explain anything and will not serve to change anyone's mind.
>I HAVE TOLD YOU AT LEAST 4 TIMES: YOU NEED TO USE A STATE OF THE ART TERMINAL TO FIRST CORRECT YOUR MISCONCEPTIONS.
Please avoid the caps lock, this is also not helpful. I have told you multiple times: I don't have access to one of those terminals, so if you want me to use that, you will either have to try to help those other projects, or you will have to explain how this can be fixed to bring those projects up-to-date. You cannot seriously expect everyone to switch to your terminal of choice just to use a special version of tmux. If you're presenting a new version of tmux that you want to get adoption then you will need to support many terminals, not just your favorite.
And actually upon looking into this it appears that libsixel is what is doing the quantization, so this statement seems to have nothing to do with either of our setups at all. Have you modified your libsixel not to do this? Or is there some other command I need to type? Please explain these things instead of just telling me I have misconceptions with no description of what they actually are.
>considering you have been proved wrong
Well I'm happy to be proven wrong but you never did this despite me asking repeatedly. It was only explained by someone else in a sibling comment. This is why I suggest against making rants, in every single case I've ever seen a developer posting rants, it prevents the actual technical issues from getting explained. And your hostile responses towards me have actually further discouraged me from using sixel or from using your tmux fork, and even from trying out mintty eventually. This is not the way to be persuasive.
>You are pointing me to a 6 years old bug report about tmux eating sequences important to display sixels
No, this is wrong. The issue is about iTerm escape sequences, not sixels. Imgcat doesn't use sixel. Please make sure to get this correct, it's very important to your project. Also this bug report is not just about eating the escape sequences, but that the escape sequences cannot possibly be processed by tmux because they lack enough information to display correctly.
>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.
This doesn't help, I mean a video that actually explains what is going on technically. You could make a youtube video that walks through the code and explains to other terminal developers how to do it.
>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...
We already have better protocols than sixel though.
Earlier quoted context omitted.
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 f…
Also the PNG format is extremely common and supports 32-bit color, so if you don't support that then you cannot accurately display PNG images, or any other RGBA format. Without this you're about 25 years out of date.
Earlier quoted context omitted.
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 t…
Uh, no apologies needed, as I don't think such issues really matters (especially online where everyone can be a dog, woof woof!). And it's ok to call out potential prejudice if you think some opinions are unfair. However, I think my expectations and opinions on terminals are quite fair, and that most people would enjoy an equivalent of mintty if there was one on Linux: it has been polished by years of adding small fu…
Also, there are other wayland environments besides GNOME, so don't feel you have to use that.
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.
Earlier quoted context omitted.
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…
I figured something like that was the case, thank you for the explanation. Still that seems like a bad hack that terminals are not going to implement because it goes off-spec. It seems as if iTerm or kitty protocols (or anything else designed for a real screen and not a printer) would be a much better choice for a terminal trying to choose.
The sixel format has much bigger issues beside its reduced color resolution - no alpha channel, need for really expensive quantization and printer head movements serialization, with bad cache locality due to its 6-pixel offset in y direction. Its compression is lousy. All that said, encoding/decoding sixels is a mainly CPU-bound resource hungry task with high bandwidth needs - all for worse quality compared to modern formats. With modern hardware, where beefy GPUs exist, it is really a shame to insist on using this format (which was effectively dead for >20ys).
On terminal side there are more issues about sixels and how they relate to cursor advance and the terminal grid, but going into these details will only bore ppl in a rant thread.