The rant is a much better read and insight into the reason for this: https://github.com/csdvrx/sixel-tmux/blob/main/RANTS.md

This is such a good read. I hope this person goes far and gets wider support for this. I really like their project and their motivation.

> Sorry guys, but I don't want you to hold Linux terminal users hostage for your petty concerns over what is the "right" way to do something like sixels. [...] It's something that has been done successfully for over 30 years.

...

> Still, you could successfully block sixel support by having control over the terminal emulators or the libraries. Ok, but now, try to prevent your users from running sixel-tmux!

...

> Also, you guys like to say that the only voices that matters are from those who can code? Hmm, ok for that too. Let's see how you like the code I release to show the pointlessness of your petty fights, and free your users from your questionable decisions.

Also, I wasn't familiar with the term "sixel". They've been around since DEC introduced them in the 80's: https://en.wikipedia.org/wiki/Sixel

>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 in a way that isn't broken). I wish open source programmers would make less rants and emotionally-driven forks, it's not helpful to someone like me who just wants to get something new like images in their terminal. The issues in the GNOME/WT bug trackers are what actually contain technical information. And just from looking at that, it appears there is an open development branch for VTE that contains sixel support: https://gitlab.gnome.org/GNOME/vte/-/issues/253

So if you use GNOME, I would say just use that and work on that, the quality is going to be better than the degraded functionality you get from de-rasterizing. In my opinion, it would be better from a technical standpoint if the author just wanted to work on that, or wanted to work on getting it implemented proper in WT. The degraded-image approach used by this tmux fork is unusable for the cited use case of getting nice graphs in the terminal, and I can't see how it's going to make it any easier for those other terminals to solve the real technical issues with sixel.

Edit: I also want to respond to this comment in the rant:

>What will happen as Wayland replaces X?

Nothing? XTerm still works. But there is also a Wayland-native terminal called "Foot" that supports sixel, if that's your thing: https://codeberg.org/dnkl/foot

2nd edit: To those downvoting, please reply to me instead of doing that. If you disagree with me it would be better to know why so I could potentially change my view, a downvote communicates nothing of value towards changing my mind.

> I can't agree. Like most rants, I found it to be very emotional and lacking in the technical department

It was an accurate assessment of the situation. Read @hpa technical analysis if you prefer, but you'll see he and I seem to concur: there's nothing technically wrong in sixels.

> So if you use GNOME, I would say just use that and work on that

The difference between you and I is you still believe what they say. I don't. And I question the motives of people associated with a project whose official stance is that it's acceptable to plan technical hurdles to prevent people from using themes: https://news.ycombinator.com/item?id=28559716

> In my opinion, it would be better from a technical standpoint if the author just wanted to work on that

I have no interest in wasting hours writing then submitting code to people who have put into writing the reasons why they are playing the clock against sixel support (as if I couldn't have read between the lines...), and who have said previously they would use their positions to veto the inclusion.

By default, I no longer trust them. It's up to them to prove they have changed. In the meantime, sixel-tmux will exist to push for change, as a pebble in their shoe.

> The degraded-image approach used by this tmux fork is unusable for the cited use case of getting nice graphs in the terminal, and I can't see how it's going to make it any easier for those other terminals to solve the real technical issues with sixel

Don't be so focused on one format. There needs to be a foot in the door, after which other formats can be added. It's just a bootstrapping problem.

Said differently, if tmux can understand sixels and store them into some internal representation, it's easy to convert from that into other formats as needed (iterm, kitty...) meaning others terminals will enjoy the graphical formats in pixel perfect quality, as long as they support at least one format.

Meanwhile, gnome users will be left to wonder why they are left to deal with a derasterized output, and fingers will be pointed into the right direction.

Maybe that will encourage the VTE team to do what the users want? If not, it will make it easier for alternatives to emerge (like "foot" for Wayland that was mentioned here)

What I'm doing is totally a political move, I grant you that.

> solve the real technical issues with sixel.

THERE IS NO TECHNICAL ISSUE WITH SIXEL (!!)

Try the nyancat linked below. Look at the FPS. 30 fps in the terminal is good enough for most uses.

The only issue with sixel is some people hold personal grudges against it.

Sorry, but I don't play ball with them anymore.

Have you read this issue? It goes more into detail about the issues with sixel: https://gitlab.freedesktop.org/terminal-wg/specifications/-/...

If these issues keep coming up, and you keep saying "sixel isn't broken" then we have nothing technical to discuss and it's going off into emotional rant territory. You have to respond to the actual technical concerns. In addition to all those things, the restriction to only paletted images makes it so I personally won't use it, it cannot be used to do any kind of accurate graphics. If you wanted to work on a new protocol that wasn't broken, I think that would be great too.

Also I think you are making more erroneous and emotional arguments when you say these things:

>And I question the motives of people associated with a project whose official stance is that it's acceptable to plan technical hurdles to prevent people from using themes

This is misinformation, GNOME is not preventing people from using themes. I can go into more detail if you like.

>I have no interest in wasting hours writing then submitting code to people who have put into writing the reasons why they are playing the clock against sixel support (as if I couldn't have read between the lines...), and who have said previously they would use their positions to veto the inclusion.

You don't need to submit any code, you could produce a fork as you already have done. Then once that's done, you could send it to someone else who could get it cleaned up for submission, if you were interested. Please don't fixate on fighting someone or arguing with one person's statements when the actual state of the project contradicts that.

>Don't be so focused on one format. There needs to be a foot in the door, after which other formats can be added. It's just a bootstrapping problem.

This doesn't make sense, the issue here seems to be the sixel protocol itself, and getting a foot in the door won't help when the format itself is broken. You would need to go back to square one in any case to design a new protocol. I think it's good to have a project that can convert between the different formats, but starting with a baseline of a broken format that doesn't work is just going to ensure that everything stays broken.

Also, using sixel to display animations seems like an extremely bad idea. You'll always get horrible performance that way. That to me seems just like it's growing towards a really bad and outdated reinvention of an X11 or RDP-style protocol. I'd say it's a mistake to pursue that.

>Maybe that will encourage the VTE team to do what the users want?

I posted a link to it, but VTE already has started adding support for Sixel.

First, stop accusing me of being emotional.

Second, tell me why 24 bits colors is insufficient for drawing into the terminals?

> starting with a baseline of a broken format that doesn't work

Look at that https://github.com/hackerb9/sixvid and that https://github.com/libsixel/libsixel and tell me precisely what doesn't work, in your own words.

If you can't...

> then we have nothing technical to discuss

... I think you may be right there!

You're saying you're "reading between the lines", that reads to me like an emotional statement, not a technical one. Please let's focus on the technical issues at hand and what has actually been said, not on what we think someone might be saying.

>tell me precisely what doesn't work, in your own words.

I already explained it, I've used sixel in Xterm and Foot and I don't like it, the restriction to paletted images makes everything look bad. Also, changing the font size breaks the images. Also, the protocol is still terrible on bandwidth, if you use it to try to transmit 1080p video over ssh (as someone is bound to do) then you will encounter the same bandwidth issues. Again please read this issue if you want to know more about my stance, I agree with everything it's saying: https://gitlab.freedesktop.org/terminal-wg/specifications/-/...

So sixel-tmux is not going to help me, sorry. It may even make things worse for me if apps are trying to use it when I don't want it. If you want some more suggestions on what to do to help, I can give those. But you're also welcome to not listen to me if you disagree. Maybe you have to accept that I am just not in your target audience, but that's no reason to accuse other maintainers of trying to hold me hostage.

Edit: I said earlier that I think it would be a good goal to support the various image protocols, I would be happy to use this if eventually an image protocol was added there that wasn't seriously flawed. But the apps and terminal emulators will still have to be changed to support that, so supporting sixel doesn't really help towards that goal at all, and in some ways it impedes it because those projects might be expected to maintain that as a backwards compatibility option. That's what I meant earlier, I think you may be approaching this problem from the wrong angle.

> the restriction to paletted images makes everything look bad

Not with 16 million colors. That's what 24 bit color mean (2^16) also called "truecolor" mode

> Also, changing the font size breaks the images.

Not on mintty. I can change the font size up and down, it even resizes the sixels in proportion so the images remain aligned to the text in a pixel-perfect way.

It's a terminal problem. You are using bad terminals. I grant you that xterm is the least worst option on linux, but do yourself a favor and try mintty on Windows.

> Also, the protocol is still terrible on bandwidth

Are you using telnet on remote hosts? Unless you do that, with ssh, compression means I can stream video (!!!) just like on local hosts (where bandwith is not an issue)

> It may even make things worse for me if apps are trying to use it when I don't want it.

In the future, sixel-tmux will intercept sixels live and rewrite them into other format, like iTerm or kitty.

How is that making things harder for you?

If you really don't want sixel even if your terminal supports them, use the appropriate terminfo and you will see nothing.

> seriously flawed

You have yet to tell me the flaws in your own words, flaws that are not due to a given terminal.

Try to use sixel to play videos in mintty, with 24 bit support so palettes aren't a problem. Then try tweaking the font size (why not!), notice how it remains a perfect user experience, then we'll talk again.

For now, all I see is FUD.

>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 talking about sixel altogether, because this is not even what you're referring to anymore. I'm actually concerned that you're conflating these two, it would also best if you could be clear about this in terms of your project so it's not confusing as to what your project supports. Maybe the name should change from sixel-tmux at some point?

SSH compression is not going to be better than the image's native compression, you really don't want to rely on that to compress your images when we already have dozens of other better ways to transmit video.

>Not on mintty. I can change the font size up and down, it even resizes the sixels in proportion so the images remain aligned to the text in a pixel-perfect way.

I'd love to look into how that's accomplished but I can't use mintty because I use a Mac, sorry. I'm also not really interested in trying to mess with mingw just to get this set up.

This isn't FUD either, you're saying the terminals are bad, well, there is no terminal I can use that works correctly, I suggested to help out fixing the terminals if you know how and you basically said no. So what am I supposed to do? Part of making a good protocol is making one that is easy for the apps and terminal emulators to implement correctly, if that doesn't exist, then like I said you have to go back to square one. Adding this support to tmux is useful in some cases, but it still isn't going to help with getting the terminals to implement this right.

>In the future, sixel-tmux will intercept sixels live and rewrite them into other format, like iTerm or kitty.

This is a good idea, please do this instead of trying to get other terminals to adopt Sixel when they are just going to have to replace it down the line anyway.

> 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 wonder that a lot of people have such a bad opinion about sixels!

> It would be best if we could just stop talking about sixel altogether, because this is not even what you're referring to anymore. I'm actually concerned that you're conflating these two

Actually, with what you said, I think you're the confused one here. When you could not express in your own words which practical limitations were imposed by sixels, I was 99% sure.

Now I'm 100% sure you have no idea of what you are talking about. Sorry if it's blunt, but take the time to run the tests I've suggested to correct your misconceptions about sixels.

Maybe you'll end up loving the format once you see what it's really capable of?

> I'd love to look into how that's accomplished but I can't use mintty because I use a Mac, sorry. I'm also not really interested in trying to mess with mingw just to get this set up.

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

So install Windows one way or another, go to msys2.org, download the latest release, click on install. No messing required, mintty is here by default.

You can then use pacman if you want more, which BTW is far better than most of the package managers available on Mac: simply follow the pacman update steps clearly explained with many screenshots on the first page.

Then you'll have an up-to-date msys2 install, with most of the linux tools you want running natively (no WSL involved) or just a `pacman -S` away.

>> In the future, sixel-tmux will intercept sixels live and rewrite them into other format, like iTerm or kitty.

> This is a good idea, please do this instead of trying to get other terminals to adopt Sixel when they are just going to have to replace it down the line anyway.

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.

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.