I see Ghostty does not support (and does not plan on adding support for) Sixels, instead preferring the Kitty image protocol.
Now if the Kitty image protocol is so great and the Sixel stuff is so bad, ~~why is it only used in Kitty and Ghostty?~~
*Edit: it's also supported in Konsole, WezTerm, ... but still I'm interested in why we have 2 competing protocols right now.
> Now if the Kitty image protocol is so great and the Sixel stuff is so bad, why is it only used in Kitty and Ghostty?
Images as in "pictures" or is that something else? I'm using Alacritty, and I don't think I've once thought "I need to see this image inside the terminal" and I do deal with images and frames from videos a lot. Probably if I saw it being added to Alacritty I'd think it was adding unnecessary bloat, so I wouldn't be surprised not every terminal is rushing to implement it.
Or I completely misunderstand what you're talking about.
I think it's because Kitty and Ghostty are the newest terminals, so they came up with new modern options and solutions.
More than two, e.g. there’s also the Inline Images Protocol supported by iTerm2 and WezTerm.
Kovid documented his rationale at some length here: https://github.com/kovidgoyal/kitty/issues/33
IMO none of them are particularly useful. Sixels is hilariously inefficient. Kitty is slightly better because you can send data as PNG, but ... you have to send image data as PNG!
I wish there was a high performance way of remoting graphics over SSH. How cool would it be if you could SSH to a remote machine and it just showed you the remote desktop in the terminal itself? No messing around with port forwarding, weird X servers, etc.
I think probably that requires a full fat video codec like H.264 to work well though. Or maybe RDP?
Probably too many GUI naysayers and "What's wrong with remote X?" for this to ever happen though.
>why is it only used
Sixel has existed for 40y, Kitty protocol originated and initially made for a single project (Kitty) few years ago.
>why we have 2 competing protocols
Well, iTerm2 also got its own image protocol (predating Kitty's but basic, only meant to show images rather graphics in general) that has been adopted by few other projects. Terminology also got something on its own, and urxvt can show images by setting the background image.
Curious, what do you do with this?
mitchellh says no plan to support Sixel:
to be fair, pretty much anything would be better than sixels
Sixel came earlier, and already fulfilled the basic requirement of "put pixels on screen in a single well-defined format" (something not even iTerm2's protocol does.)
Kitty is a lot more complex: it accepts five different encodings, has three different ways to load the data, supports animations, etc. So it's no wonder only a few terminal developers had time to implement it.
See also: https://github.com/veltza/st-sx/issues/1#issuecomment-190272... 5000 lines (Kitty) vs 1000 lines (Sixel) even though the Kitty patch is just a "subset".