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