5 ms·

There have been pushes for sixel for ages. I just don't think it's going to happen.

by junon 4y ago

georgia_peach 4y ago
It's okay for low-color/solid-run images, terrible for everything else. Nachman's image mime blobs (iTerm2 style) is the superior approach. mintty/mlterm/rlogin/wezterm already support it. Kitty has an (incompatible) variant--same idea, but delivered in chunks.
- csdvrx 4y ago
  > terrible for everything else Define terrible. Wasteful, yes. But when we run chat programs inside electron apps, does it really matters? > is the superior approach My idea of superiority is linked to availability and support. Multiple competing formats are often a problem > Kitty has an (incompatible) variant Indeed, the multiple competing formats might each have some specific technical advantages, but networks effect makes your life harder.
  - georgia_peach 4y ago
    > when when run chat programs inside electron apps, does it really matters? From a dev perspective, it's a lot easier to base64 an image you already have, with a base64 that's already in your stdlibs, than to scour github for a passable sixel library to pre-rasterize that jpeg & reformat it as sixel. I say this as someone who's written a sixel conversion library. > competing formats It's not a very old format, yet already supported on 4-5 terminals last I checked.
    - retrocryptid 4y ago
      Or you could just use the libsixel package. Downloading libraries isn't unknown to developers (thinking about `apt-get install libncurses5-dev libsixel-dev` or the like.) Or sysadmins: `apt-get install libncurses5` or `apt-get install libsixel`.
      - georgia_peach 4y ago
        && find out how to get it on OSes that aren't debian-based && find a decent FFI wrapper if my app isn't in C-land && read the docs && static link hassles so I don't have to sort-out dynamic-link hassles for every platform || round-up a collection of dynamic libsixel libs & figure out how to bundle them with my script if I'm not using a compile-to-machine-code language vs b64 := base64.Encode(myImg) fmt.Printf("\x1b]1337;inline=1;size=%d:%s\n", len(b64), b64) If it's a feature request where I'm really only handling it to shut a few people up, which route am I going to take?
  - mongol 4y ago
    > Indeed, the multiple competing formats might each have some specific technical advantages, but networks effect makes your life harder. Any hope for standardization?
    - csdvrx 4y ago
      > Any hope for standardization? I do everything I can to help popularize sixels - it could be a default fallback format: sixel-tmux could "rewrite" on the fly sixel sequences into kitty iterm2 or whatever
- jhallenworld 4y ago
  Thanks, will try this. Wish xterm was on the list, but mlterm is OK.
- retrocryptid 4y ago
  Sixels are compatible with cursor positioning escape sequences, so I can position the image on the screen. I wasn't able to do this with term2. Very possible I just didn't see how to do it though. If you have a pointer to docs for making that work, I'd love to play around with it.
  - georgia_peach 4y ago
    Last time I evaluated this, sixel & base64 image placement relative to re-positioned cursor had slightly different behaviors across different implementations. I think the only one with well-defined placement/dimensions behavior was the Kitty format--which is unfortunately Kitty-only. https://sw.kovidgoyal.net/kitty/graphics-protocol/ https://sw.kovidgoyal.net/kitty/graphics-protocol/ If the goal is to hot-patch graphics into existing TUIs, Kovid is probably on the right track with this. It needs to be something richer than what sixel or iTerm2 provide--with pixel placement, play/pause, scaling, etc. Though for a do-over of piping a UI over a (relatively) low-bandwidth wire, I think something like Sun NeWS would have been a simpler & more feature-complete approach.
    - wezfurlong 4y ago
      wezterm supports the kitty image protocol (as well as sixel and iterm2), and runs on all major platforms. (disclaimer: I'm the wezterm guy)
      - georgia_peach 4y ago
        a mighty fine terminal sir
      - junon 4y ago
        Been using Wezterm for about a year now and I'm a very satisfied user. Beats any others I've ever used - iTerm2 comes close but it's Mac only. Every other terminal emulator in my experience has been problematic. Wezterm has not been. Just works.
pcwalton 4y ago
Yeah, I don't see the point in trying to resurrect a dead standard that isn't very efficient or widely supported. Backwards compatibility is important, but sixels aren't even that well supported nowadays†, so there's not much to be compatible with. Better to just push for new de facto standards for images in the terminal; trying to resurrect sixels is an exercise in retrocomputing. † xterm and iTerm2 are the only widely-used terminal emulators nowadays that support sixels. Few Linux users use plain old xterm nowadays due to lack of desktop integration, and iTerm2 is not the OS default terminal (and it supports a better image format anyway). Also note that no popular Windows terminal emulators (conhost.exe, conemu, Microsoft Terminal) support sixels at all.
- retrocryptid 4y ago
  The idea here is you can get graphics via a ssh connection. You don't need to setup a web interface to collect and process metrics. It's useful cause you don't have to take your fingers off the keyboard to get graphical information. And yeah. I would be just as happy to use NAPLPS, but Sixel support is what we have.
- jph00 4y ago
  sixel works fine, and is better supported than a "new de facto standard" the doesn't even exist yet. It's not at all true that no popular windows s/w supports it - mintty/wsltty supports it just fine and is widely used.
  - pcwalton 4y ago
    No, a better standard does exist: https://iterm2.com/documentation-images.html https://iterm2.com/documentation-images.html In fact, mintty already supports it. Only xterm doesn't. Sixel really is just retrocomputing at this point.
- hulitu 4y ago
  Xterm integrates perfectly in fvwm. And it does not need GB of RAM to render text.

There have been pushes for sixel for ages. I just don't think it's going to happen.

by junon 4y ago

There have been pushes for sixel for ages. I just don't think it's going to happen.

It's okay for low-color/solid-run images, terrible for everything else. Nachman's image mime blobs (iTerm2 style) is the superior approach. mintty/mlterm/rlogin/wezterm already support it. Kitty has an (incompatible) variant--same idea, but delivered in chunks.

csdvrx 4y ago
> terrible for everything else Define terrible. Wasteful, yes. But when we run chat programs inside electron apps, does it really matters? > is the superior approach My idea of superiority is linked to availability and support. Multiple competing formats are often a problem > Kitty has an (incompatible) variant Indeed, the multiple competing formats might each have some specific technical advantages, but networks effect makes your life harder.
- georgia_peach 4y ago
  > when when run chat programs inside electron apps, does it really matters? From a dev perspective, it's a lot easier to base64 an image you already have, with a base64 that's already in your stdlibs, than to scour github for a passable sixel library to pre-rasterize that jpeg & reformat it as sixel. I say this as someone who's written a sixel conversion library. > competing formats It's not a very old format, yet already supported on 4-5 terminals last I checked.
  - retrocryptid 4y ago
    Or you could just use the libsixel package. Downloading libraries isn't unknown to developers (thinking about `apt-get install libncurses5-dev libsixel-dev` or the like.) Or sysadmins: `apt-get install libncurses5` or `apt-get install libsixel`.
    - georgia_peach 4y ago
      && find out how to get it on OSes that aren't debian-based && find a decent FFI wrapper if my app isn't in C-land && read the docs && static link hassles so I don't have to sort-out dynamic-link hassles for every platform || round-up a collection of dynamic libsixel libs & figure out how to bundle them with my script if I'm not using a compile-to-machine-code language vs b64 := base64.Encode(myImg) fmt.Printf("\x1b]1337;inline=1;size=%d:%s\n", len(b64), b64) If it's a feature request where I'm really only handling it to shut a few people up, which route am I going to take?
- mongol 4y ago
  > Indeed, the multiple competing formats might each have some specific technical advantages, but networks effect makes your life harder. Any hope for standardization?
  - csdvrx 4y ago
    > Any hope for standardization? I do everything I can to help popularize sixels - it could be a default fallback format: sixel-tmux could "rewrite" on the fly sixel sequences into kitty iterm2 or whatever
jhallenworld 4y ago
Thanks, will try this. Wish xterm was on the list, but mlterm is OK.
retrocryptid 4y ago
Sixels are compatible with cursor positioning escape sequences, so I can position the image on the screen. I wasn't able to do this with term2. Very possible I just didn't see how to do it though. If you have a pointer to docs for making that work, I'd love to play around with it.
- georgia_peach 4y ago
  Last time I evaluated this, sixel & base64 image placement relative to re-positioned cursor had slightly different behaviors across different implementations. I think the only one with well-defined placement/dimensions behavior was the Kitty format--which is unfortunately Kitty-only. https://sw.kovidgoyal.net/kitty/graphics-protocol/ https://sw.kovidgoyal.net/kitty/graphics-protocol/ If the goal is to hot-patch graphics into existing TUIs, Kovid is probably on the right track with this. It needs to be something richer than what sixel or iTerm2 provide--with pixel placement, play/pause, scaling, etc. Though for a do-over of piping a UI over a (relatively) low-bandwidth wire, I think something like Sun NeWS would have been a simpler & more feature-complete approach.
  - wezfurlong 4y ago
    wezterm supports the kitty image protocol (as well as sixel and iterm2), and runs on all major platforms. (disclaimer: I'm the wezterm guy)
    - georgia_peach 4y ago
      a mighty fine terminal sir
    - junon 4y ago
      Been using Wezterm for about a year now and I'm a very satisfied user. Beats any others I've ever used - iTerm2 comes close but it's Mac only. Every other terminal emulator in my experience has been problematic. Wezterm has not been. Just works.

pcwalton 4y ago

Yeah, I don't see the point in trying to resurrect a dead standard that isn't very efficient or widely supported. Backwards compatibility is important, but sixels aren't even that well supported nowadays†, so there's not much to be compatible with. Better to just push for new de facto standards for images in the terminal; trying to resurrect sixels is an exercise in retrocomputing. † xterm and iTerm2 are the only widely-used terminal emulators nowadays that support sixels. Few Linux users use plain old xterm nowadays due to lack of desktop integration, and iTerm2 is not the OS default terminal (and it supports a better image format anyway). Also note that no popular Windows terminal emulators (conhost.exe, conemu, Microsoft Terminal) support sixels at all.

retrocryptid 4y ago
The idea here is you can get graphics via a ssh connection. You don't need to setup a web interface to collect and process metrics. It's useful cause you don't have to take your fingers off the keyboard to get graphical information. And yeah. I would be just as happy to use NAPLPS, but Sixel support is what we have.
jph00 4y ago
sixel works fine, and is better supported than a "new de facto standard" the doesn't even exist yet. It's not at all true that no popular windows s/w supports it - mintty/wsltty supports it just fine and is widely used.
- pcwalton 4y ago
  No, a better standard does exist: https://iterm2.com/documentation-images.html https://iterm2.com/documentation-images.html In fact, mintty already supports it. Only xterm doesn't. Sixel really is just retrocomputing at this point.
hulitu 4y ago
Xterm integrates perfectly in fvwm. And it does not need GB of RAM to render text.