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

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 "uncool".

Desperate times call for desperate measures. Publishing this fork was a last resort move, for the exact reasons you stated: forks are often lost in obscurity.

However, the situation seems to be changing: check the discussion in: https://github.com/csdvrx/sixel-tmux/pull/1 and you'll see there may be some light at the end of the tunnel!

A compile time flag is not ideal, but if at least derasterize can be added by default, so that every tmux user can have some kind of graphics in the terminal, even if said graphics are not sixels but derasterized, that would be "good enough" to me.

No problem. I know maintaining forks isn't an ideal thing to do and support should ideally land upstream.

> I believe it's unfair that Linux users have fewer options than us Windows users, due to some people thinking sixel is "uncool".

I think the README page of termite pretty much sums up why getting involved in VTE, or any GNOME project for that matter, is a bad decision.

https://github.com/thestinger/termite/blob/master/README.rst...

I'm just a random spectator but perhaps your efforts might've been better spent on an independent terminal project (like Alacritty, for example) rather than trying to get features merged upstream in a GNOME project.

> However, the situation seems to be changing: check the discussion in: https://github.com/csdvrx/sixel-tmux/pull/1 and you'll see there may be some light at the end of the tunnel!

Yeah, I read the entire conversation and if sixel support lands in tmux upstream, it would indeed be good news.

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.

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.

Indeed! It's nice to see what's possible!

As for video playback, while it may not be realistic with the current sixel-tmux due to the size of the search space, it may be possible once the new 1FBxx block https://en.wikipedia.org/wiki/Symbols_for_Legacy_Computing is integrated into derasterize and the suggested fonts: restricting ourselves to the 1FB0x-1FB3x subset would only require adjudicating about 64 characters.

Some very basic programming tricks (a bloom filter after binarization of the input, memoizing...) may be sufficient to derasterize sixel videos in real time, even on an average system.

> I still suspect it's a performance issue in the terminal(s) I tested

If you don't use Windows, try xterm and mlterm. For xterm, I maintain a set of config files giving you a decent out-of-the box experience, cutexterm

> I should definitely have another look though, it's good to know that it is possible to get decent performance out of sixels.

Indeed :) It's a format that has been unfairly dismissed. It's old, but we have great tools like libsixel to do anything we want with it in this millenium.

Speaking of libsixel, also check https://github.com/libsixel/libsixel a recent fork that's open to PR