[csdvrx]

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

[noergl]

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.

[speeddemon]

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.

[noergl]

Well it is not that bad, imho all newer terminal implementations, that dont try to strictly emulate a VT340, do sixel this way. libsixel even propagates this as "highcolor". But again, sixel is still limited to ~1M colors in RGB and ~3M colors in HSL, even with that implementation trick.

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.

[speeddemon]

>Yes

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