3 ms·

https://vt100.net/docs/vt3xx-gp/chapter14.html#T14-1 https://vt100.net/docs/vt3xx-gp/chapter14.html#T14-1 Am I reading this incorrectly? It seems I was wrong,

https://vt100.net/docs/vt3xx-gp/chapter14.html#T14-1 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, 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 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 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.

traverseda 5y ago
https://saitoha.github.io/libsixel/ https://saitoha.github.io/libsixel/ Looks to me like the limited pallete is mostly as XTerm limitation, but a limitation of the protocol.
- speeddemon 5y ago
  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 those sixel implementations to do the right thing.
  - csdvrx 5y ago
    > 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 for some specific applications)
    - speeddemon 5y ago
      Either one, it wasn't explained how the protocol can be used to do any color depth higher than 8 bit. 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.
csdvrx 5y ago
> 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 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...

traverseda 5y ago

https://saitoha.github.io/libsixel/ https://saitoha.github.io/libsixel/ Looks to me like the limited pallete is mostly as XTerm limitation, but a limitation of the protocol.

speeddemon 5y ago
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 those sixel implementations to do the right thing.
- csdvrx 5y ago
  > 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 for some specific applications)
  - speeddemon 5y ago
    Either one, it wasn't explained how the protocol can be used to do any color depth higher than 8 bit. 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.

csdvrx 5y ago

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