What nonsense, it takes literally 15 lines of code without using anything beyonf the standard library to write a client for the kitty graphics protocol. I challenge you to match that for sixel. https://sw.kovidgoyal.net/kitty/graphics-protocol/#a-minimal...
Sixels are pixels and enjoy a wide support due to how old this VT240 format is.
The Kitty protocol starts with multiple formats:
>> The terminal emulator must understand pixel data in three formats, 24-bit RGB, 32-bit RGBA and PNG.
Different tools for different needs, but if you are going for a wide support you want something simple that doesn't also have 5 different types you have to separately implement and test:
>> d: Direct (the data is transmitted within the escape code itself)
>> f: A simple file (regular files only, not named pipes or similar)
>> t: A temporary file, the terminal emulator will delete the file after reading the pixel data. For security reasons the terminal emulator should only delete the file if it is in a known temporary directory, such as /tmp, /dev/shm, TMPDIR env var if present and any platform specific temporary directories and the file has the string tty-graphics-protocol in its full file path.
>> s: A shared memory object, which on POSIX systems is a POSIX shared memory object and on Windows is a Named shared memory object. The terminal emulator must read the data from the memory object and then unlink and close it on POSIX and just close it on Windows.
> What nonsense, it takes literally 15 lines of code without using anything beyond the standard library to write a client
Conveniently taking a preencoded PNG and assuming away the necessary queries of supported protocol:
>> Since a client has no a-priori knowledge of whether it shares a filesystem/shared memory with the terminal emulator, it can send an id with the control data, using the i key (which can be an arbitrary positive integer up to 4294967295, it must not be zero).
> I challenge you to match that for sixel
Challenge accepted. There are many libraries for many languages. Let's look at this one in perl:
use Image::LibSIXEL;
$encoder = Image::LibSIXEL::Encoder->new();
$encoder->setopt("w", 400);
$encoder->setopt("p", 16);
$encoder->encode("images/egret.jpg");
and some print($encoder) to print the output, and this works on all the terminals listed on https://www.arewesixelyet.com/
Compared to kitty: "As of April 2022, kitty and WezTerm are the only terminal emulators to support this graphics protocol completely, with Konsole and wayst having partial support"
If we want graphics in the terminal, first we need graphics in the terminal (using sixels is the simplest way, and you get access to many tools) then you can do more if you still want to - but you're likely to realize by then that all the extra things Kitty supports is YAGNI: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it?use...
1) sixel has no querying. So if you want to compare apples to apples, you leave out the querying from the kitty protocol as well.
2) The code I linked to above uses only the standard library which I emphasized. You are using some random sizel specific library to add support for sixel to your perl script.
So no, you dont meet the challenge. I can output images with the kitty protocol using pure BASH + base64, available everywhere.
Oh and incidentally the saitoha sixel library is both unmaintained and full of security issues, so save yourself some headaches and dump it.
Trying to claim the kitty protocol is harder to use than sixel is beyond disingenuous.
Either you have PNG data, or you have to support the various RGB encodings
> I can output images with the kitty protocol using pure BASH + base64, available everywhere.
This is disingenuous: so can I if instead of .PNG files, I have .SIX files.
I won't even need base64 - which you'll need to write in shell script if you write a portable bash script. And if want you want to show isn't .png or .jpg, you'll need more...
> Trying to claim the kitty protocol is harder to use than sixel is beyond disingenuous.
Funny, because I think the same about you.
Given the tone of your previous post, and the tone of this post, I'm out.
Yes and PNG is an actual file format widely used and available. SIX isnt. And sure if you want to invent mythical SIX file formats, I can just as well invent mythical KITTY_IMAGE file formats that you can just cat into a terminal, without needing even base64 or bash. The point is, as it stands, the kitty image protocol is FAR easier to USE to display images than sixels. Trying to claim otherwise is just ridiculous. Indeed, if you want to talk of ease of use, the iterm2 protocol is even easier, since iterm supports more image formats without requiring conversion to RGB.
Good that you are out, hopefully you are out of trying to shill sixels as well.
Oh I dont hide the fact that I love kitty. I have good reason to do so, it has almost single handedly fixed so many problems that haveplagues the terminal space for decades. And done so in a robust, thoughtful and well designed manner. If you dont like kitty that's fine. But PLEASE do not advocate broken, badly designed disasters like SIXEL and modifyOtherKeys. they will just doom this ecosystem for decades more.
Funny, I don't see vt52, vt100, vt102, vt200, xterm et al. on that list. Could this be why sixels aren't everywhere except terminal emulators that run on gui platforms with highly advanced graphics already?
xterm is on that list (and at least for me, the distro provided version has sixels enabled, I've not dug into what build options can be switched off, but I wouldn't be surprised that lots of things that people assume, such as colour depth, can be switched off). Given the vt52, vt100, vt102 and vt200 predate the introduction of sixel (based on https://en.wikipedia.org/wiki/Sixel), I'm not surprised those 40 year old terminals don't support sixels ;)
Read https://sw.kovidgoyal.net/kitty/graphics-protocol/
Then read about the sixel format, and decide which one you think is the easiest to support.