Sixel capability not detected in foot + tmux

[amigthea]

I get a pixelated image using chafa on tmux

There's no problem outside tmux

can you replicate? there' s something else I can try to workaround this?

chafa --version

Chafa version 1.14.5

Loaders:  AVIF GIF JPEG JXL PNG QOI SVG TIFF WebP XWD
Features: mmx sse4.1 popcnt avx2
Applying: mmx sse4.1 popcnt avx2

Copyright (C) 2018-2024 Hans Petter Jansson et al.
Incl. libnsgif copyright (C) 2004 Richard Wilson, copyright (C) 2008 Sean Fox
Incl. LodePNG copyright (C) 2005-2018 Lode Vandevenne
Incl. QOI decoder copyright (C) 2021 Dominic Szablewski

This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[hpjansson]

Hi, thanks for filing the issue. Could you please run the following:

for i in TERM TERM_PROGRAM TERM_PROGRAM_VERSION TMUX; do echo $i=$(printenv $i); done

...both outside and inside tmux, and paste the output here?

The name and version of your terminal emulator would also be helpful.

[amigthea]

with pleasure:

the terminal emulator is foot
foot --version

foot version: 1.19.0 +pgo +ime +graphemes +toplevel-icon -assertions

inside tmux

TERM=screen-256color
TERM_PROGRAM=tmux
TERM_PROGRAM_VERSION=3.5a
TMUX=/tmp/tmux-0/default,4032,0

outside tmux

TERM=foot
TERM_PROGRAM=
TERM_PROGRAM_VERSION=
TMUX=

[hpjansson]

Thanks. Here's the explanation for what you're seeing:

If we send sixels to tmux and the outer terminal does not support it, it'll just show a blank placeholder. Therefore we have to be sure the outer terminal can handle it.

Unfortunately, foot does not export any environment variables apart from TERM, which tmux overrides, so we don't have a way of detecting it, and have to go for the safe character-based option. For comparison, WezTerm exports WEZTERM_EXECUTABLE, so we can enable sixels there.

The only workaround currently is to invoke the Chafa CLI tool with chafa -f sixel. I'm not sure if Kew has a similar workaround.

I'm looking at two ways to work around this in the library:

• Implementing our own environment variable(s), e.g. CHAFA_MODE and CHAFA_PIXEL_MODE, which would allow users to transparently override the detection in any API consumer.
• Probing for the outer primary/secondary/tertiary device attributes with passthrough. This means new API, and client programs would have to be updated to use it.

It may be a good idea to implement both.

[amigthea]

I just tried tmux on

• konsole
• alacritty
• wezterm

and the image render is broken on all of them.

I tried the workaround you suggested with tmux on foot but didn't return anything

I'm feeling I'm doing something wrong, it works on your environment?

[hpjansson]

Maybe your tmux was built without --enable-sixel. Try this in tmux:

echo -e "\033[c";cat

What does it say?

[amigthea]

it outputs this

tmux display -p '#{client_termfeatures}'

returns me

bpaste,focus,rectfill,sixel,title

[hpjansson]

Ok. The 4 means it has sixel support. Last thing to try:

chafa -f sixel -s 5 <image.jpg>

This makes the image tiny. tmux has an upper limit on the image data it will permit, and it's set fairly low.

[amigthea]

eureka!

is there a way to change tmux image data limit?

[hpjansson]

is there a way to change tmux image data limit?

Unfortunately not. It's restricted by the maximum size of the input buffer, which is hardcoded at the moment:

https://github.com/tmux/tmux/blob/46f384665965dd279754915772d3d86245b48784/input.c#L96

I don't know if the tmux maintainer is open to increasing it or making it configurable. You could ask, but be aware there are previous reports where users hit the limit, e.g. tmux/tmux#3726.

There are ways we could work around this in Chafa (e.g. quantizing the image until it's below the limit, or splitting it into multiple sixel images), but it's bound to be somewhat brittle and requires a significant work investment from us.

[amigthea]

thank you for the insight, really appreciated

beside image dimension, I'm gonna explicitly use -f sixel parameter, at least for tmux navigation. For third party implementations like ravachol/kew#189 I'll wait to test those two solutions you suggested before as soon as they will be implemented <3

[amigthea]

in the meantime

Unfortunately not. It's restricted by the maximum size of the input buffer, which is hardcoded at the moment:

https://github.com/tmux/tmux/blob/46f384665965dd279754915772d3d86245b48784/input.c#L96

I don't know if the tmux maintainer is open to increasing it or making it configurable. You could ask, but be aware there are previous reports where users hit the limit, e.g. tmux/tmux#3726.

exciting news on this!

input-buffer-size option is now available, altough chafa seems to fail the image preview at all in the latest tmux-git version:

the previously working chafa -f sixel -s 50 cat.jpeg command is now just briefly flashing the image on terminal output and disappear

something in the latest git version seems to mess up the preview I think?

[hpjansson]

exciting news on this!

Woo! Thanks for raising the issue.

the previously working chafa -f sixel -s 50 cat.jpeg command is now just briefly flashing the image on terminal output and disappear
[...]
something in the latest git version seems to mess up the preview I think?

Yes, I've been reworking the TE identification code to be more flexible and manageable. That's good for the long term, but in the short term it's caused a few regressions. Thankfully we have a great QA department, so this will be fixed shortly.

Does it work if you add --passthrough none?

[amigthea]

Does it work if you add --passthrough none?

unfortunately not, I noticed that with this argument it does not even flash the image