timg is not selecting sixel on Windows Terminal Preview

[gestate-8]

Windows Terminal Preview supports sixel images.

timg is not auto-detecting sixel support on WT.

timg -ps works well.

[j4james]

The way timg currently detects the supported protocol is with an XTVERSION query that returns the terminal name, which is compared against a hardcoded list of terminals. This is not ideal, and misses quite a few existing Sixel terminals.

The preferred way to detect Sixel is with a Primary Device Attributes query, which should report a 4 in the extension list on terminals that support Sixel.

[hzeller]

Determining the features is a careful dance, as not all queries to determine features will work and some actually end up messing up some terminals as they can't deal with the escape codes they were given (e.g. the kitty graphics query is known to make some terminals glitch). So only queries that don't interfere are selected for such things.
Having said that, Primary Device Attributes seems benign, so this might indeed be a good fallback solution.

There is one additional property to figure out: sixel terminal implementations seem to behave slightly differently w.r.t. cursor placement after an image had been sent; which requires some manual testing and hardcoding right now (setting the known_broken_sixel_cursor_placement in the timg TermGraphicsInfo. So there is also a good chance that even if we know the sixel property that we pick the wrong workaround.

Anyway, while I investigate implementing the fallback solution, let's add your terminal so the hardcoded list.
What is the output in your terminal when you emit the CSI >q query manually ?

echo -e "\033[>q"

To determine what kind of sixel workaround we need: if you run an animation

timg -ps someanimation.gif

Does it work correctly or is the image 'wandering' up or down ?

... or show multiple images in a grid:

timg -ps --grid=3 *.png

... do they align properly or look like they are arranged in a staircase ?

[hzeller]

I've implemented the Primary Device Attributes query to determine Sixel capability. Please try again from head to see if this works for you (please also test if animations and grid work as described before, as that behavior can't be auto-detected AFAIK)

[gestate-8]

echo -e "\033[>q"

Nothing prints. (Tested on vanilla bash shell)

timg -ps someanimation.gif

The image is pushed to the top of the terminal, flickering between a random colored background and frames.
The default terminal background is black.
But at least it does play.

timg -ps --grid=3 *.png

This works well, but also with a random colored background.

This was tested in latest commit.

❯ timg --version
timg 1.6.1+  <https://timg.sh/>
Copyright (c) 2016..2024 Henner Zeller. This program is free software; license GPL 2.0.

Image decoding GraphicsMagick 1.3.45 (2024-08-27)
Openslide 4.0.0
Turbo JPEG
librsvg 2.59.2 + cairo 1.18.2
PDF rendering with poppler 24.12.0 + cairo 1.18.2
QOI image loading
swscale 8.3.100
Video decoding libav 61.7.100; avdevice 61.3.100
Libsixel version 1.10.3
Half, quarter, iterm2, and kitty graphics output: timg builtin.

[hzeller]

With the latest commit: does it work without -ps ?

[gestate-8]

No, it still uses fallback with Unicode characters.

[hzeller]

Sounds like the terminal is neither implementing the >q query nor the primary device attributes, so we don't have anything to auto-detect. Maybe file a bug with the terminal authors.

For now, I recommend to set the environment variable TIMG_PIXELATION=sixel so that you can use timg without having to remember to pass -ps every time.

[gestate-8]

Thank you. I will make an issue on the WT repository.

[j4james]

Sounds like the terminal is neither implementing the >q query nor the primary device attributes

Windows Terminal doesn't support the >q query, but it does support device attributes. And your latest commit does work for me without the -ps option (built and run from within a WSL session).

I have some feedback on your fix though. If I'm reading it correctly, I think the test below will produce false positives on terminals that implement features like the Latin-2 character set (which is identified by the number 42), but which don't support Sixel.

timg/src/term-query.cc

Line 293 in dbe0299

if (find_str(start + strlen(kExpect), end - start, ";4")) {

And regarding the comment below, that first value identifies the terminal conformance level. technically it could be anything in the range 61 to 65. The example in the linked documentation is 64 because it's identifying a level 4 device.

timg/src/term-query.cc

Lines 285 to 288 in dbe0299

	// https://vt100.net/docs/vt510-rm/DA1.html
	// says CSI ?64 is returned, but I've only encountered
	// CSI ?62 in various terminals.
	// So, let's just watch for common prefix CSI ?6

So what you have there is technically correct as it is, but it's worth noting that some modern terminal emulators don't use a strictly correct DA response, so you may fail to detect them. Some examples that I've encountered in the past:

• Rxvt (with a Sixel patch) - \033[?1;2;4c
• St (with a Sixel patch) - \033[?12;4c

I don't think it's a big deal if you choose to ignore those, though, since people can always still use the -ps option.

This works well, but also with a random colored background.

This is the result of timg wrapping the libsixel output with an extra Sixel introducer. See here:

timg/src/sixel-canvas.cc

Line 130 in dbe0299

WriteStringToOutBuffer("\033Pq", &out); // Start sixel data

So the start of the Sixel image sequence actually ends up being \033Pq\033Pq. That's interpreted as an additional "blank" image, and because it has no parameters, it triggers a background erase, and with no declared dimension, the default size is the maximum extent of the screen. As a result, it'll generate a background fill from the current cursor position up to the bottom right of the page. You may not see that on a lot of terminals, because most don't implement background erase correctly.

There's also an unnecessary extra ST terminator here:

timg/src/sixel-canvas.cc

Line 147 in dbe0299

WriteStringToOutBuffer("\033\\", &out); // end sixel data

[hzeller]

The ambiguity between 4 and 42 was deliberate as I see this as a best-effort fallback solution, and I have also not seen any terminal I played with return that. If it becomes a problem, this should be addressed (only a line more code). The DA responses that don't start with 6 might be more of an issue. Maybe it is a good idea to simply look for \033[? ... since we anyway have only one query queued and expect the answer.

If you see something in the sixel implementation that causes issues like the blank image situation, please send a pull request. I don't remember exactly why these code-pieces are in there, it might well be that it was needed when testing on the various terminals when I implemented it.

[j4james]

The ambiguity between 4 and 42 was deliberate as I see this as a best-effort fallback solution, and I have also not seen any terminal I played with return that.

I've personally seen a few - the current release version of Windows Terminal being one example - but I've just tested that now, and surprisingly it still works with the latest commit. I'm guessing it's because you can't detect the font size, and without that you won't even attempt to detect sixel. I'm not sure about the other terminals, but I suspect they probably wouldn't report the font size either, so this is likely not as big a deal as I initially thought.

If you see something in the sixel implementation that causes issues like the blank image situation, please send a pull request.

OK. I might give that a go this weekend.

[hzeller]

I already changed the detection so that only 4 not 42 is detected.

I've now added information about what happens in the terminal query phase if --verbose is given. Can you compile timg from head and then call it with --verbose and some image ? Before the image, there should be some information about the terminal queries. I think this will help in the future when adding new auto-detection.

Output looks something like this (here on my local terminal):

Query: '\033[>q\033[5n' Response: '\033P>|Konsole 24.12.0\033\\\033[0n' (0ms)
Query: '\033]11;?\033\\' Response: '\033]11;rgb:0000/0000/0000\033\\' (0ms)