Calling all image issues

[dylanaraps]

The image feature is a hack which doesn't work in all terminal emulators. To make matters worse it sometimes works in example_terminal on one machine but fails in example_terminal on another machine.

There is also the buggy and sometimes broken implementation of the "get terminal window size" escape sequence which can cause terminal size detection to fail on some systems.

I've been answering issues related to this for years and there's nothing I can do about resolving this issue. It's a hack! To ease the maintainence of this bug tracker, all image related issues will be directed here.

Please post your troubles, workarounds and overall discussion here.

NOTE: This doesn't include all image backends. Some work flawlessly as they convert the image to some form of textual representation. This also excludes backends like kitty, sixel and iterm2 which have real support from terminal emulators.

[ShayBox]

afaik Uberzug works flawlessly on any X session, regardless of the terminal or desktop, so I believe it would be a good default and main focus as it would bring the most compatibility.

[dylanaraps]

See: #1172

I have no interest in Überzug and it is still the same hack I am talking about above, only it now loops instead of drawing once. As stated in the issue above; I will review patches which add this feature.

[dylanaraps]

You need imagemagick installed.

[ghost]

Ok i got imagemagic installed now i get a broken image :

kristiyan grep -i image neofetchlog | less -S
~
kristiyan grep -i image neofetchlog
+ image_backend
+ case ${image_backend:-off} in
+ get_image_source
+ case $image_source in
+ image=
+ err 'Image: Using image '\'''\'''
+ err+='[!]\e[0m Image: Using image '\'''\''
+ to_ascii 'Image: '\''auto'\'' doesn'\''t exist, falling back to ascii mode.'
+ err 'Image: '\''auto'\'' doesn'\''t exist, falling back to ascii mode.'
+ err+='[!]\e[0m Image: '\''auto'\'' doesn'\''t exist, falling back to ascii mode.
+ image_backend=ascii
[!]\e[0m Image: Using image '\'''\''
[!]\e[0m Image: '\''auto'\'' doesn'\''t exist, falling back to ascii mode.
[!] Image: Using image ''
[!] Image: 'auto' doesn't exist, falling back to ascii mode.

[dylanaraps]

Closing this issue but leaving it pinned.

[gardotd426]

This used to work perfectly in kitty with --w3m, hell it always worked in gnome-terminal with --w3m as well, but now it won't work in any terminal I've tested (alacritty, kitty, gnome-terminal, urxvt, xterm) with anything except for in kitty with the specific --kitty backend (even `neofetch --w3m doesn't work in kitty anymore). Can't figure it out for the life of me.

[adrianrlaw]

This issue seems to be related to a hack implemented in w3m-img that would break in some terminals. As such, the patch has to be on w3m's end (though I think they're refusing to fix it). A rudimentary explanation is in this mailing list which refers to st specifically but should also apply to all other terminal emulators implementing the same or similar double buffering strategy.

Edit: Apparently there's a forked version of st patched to be compatible with libsixel and with some testing it appears to work with neofetch just fine if you use the --sixel backend.

[mattkelsey]

This might be useful for some people:
If you are using Wayland, then neofetch wont be able to detect your terminal size because there is not currently Wayland compatible tooling for fetching window size (i.e. xdotool only works with X and there is no equivalent for Wayland). Or if there is a tool, I haven't been able to find it.

If you have this issue, you'll get this error when running neofetch in verbose mode: Image: Failed to find terminal window size.

Workaround

Run your terminal with XWayland (Wayland's X11 compatibility layer designed for apps that don't support Wayland). Just set the GDK_BACKEND=x11 environment variable which will force the terminal to run under XWayland (for instance in Gnome you could modify your application file for your terminal to run with that env var prefaced). This allows all the X tooling to work as intended.

Of course this isn't good because your terminal can't run on Wayland but it's a small price to pay for sweet images! Also the terminal is not graphically demanding, so running through the compatibility layer doesn't seem like too big of an issue. Has been working fine for me so far.

[RisingThumb]

#1172 #1453
@ShayBox @dylanaraps I wrote a patch to support Ueberzug.https://pastebin.com/raw/y8wB4nEA I posted it on pastebin. It works on my machine which runs st. I believe it also meets most of the criteria for code convention, however I get 2 warnings from shellcheck that I'm unsure how to fix.

                        [identifier]="neofetch"\
                        ^----------^ SC2102: Ranges can only match single chars (mentioned due to duplicates).


In neofetch line 4170:
                        [max_height]="$((height / font_height))"\
                        ^----------^ SC2102: Ranges can only match single chars (mentioned due to duplicates).

Let me know if this patch works for you. It also depends on ueberzug.

[jazz-it]

Installing the following packages seems to help to fix this issue:

pacman -S xorg-xwininfo xorg-xdpyinfo xdotool

[JuanjoSalvador]

According to #1385, and as far I can test, gnome-terminal seems not supported anymore for displaying images. So maybe it should be removed from the wiki's compatibility list (suggestion!)

[mattdm]

Reviewers and enthusiasts seem to really like neofetch for their screenshots.

So, I'd like for it to display the Fedora logo nicely. We're particularly interested because we're just about to launch a refresh of the logo, and we've identified neofetch as somewhere where we'd like this to work nicely. I'd really like this to work out of the box with the chafa backend, but of course it doesn't on wayland (hangs on xwininfo, as noted in one of the bugs above). But chafa doesn't output pixels, so it doesn't really need the pixel size — stty size should be sufficient, right?

[cadenkriese]

Was having some issues on iTerm2, disabling Show inline images at retina resolution and Disable potentially insecure escape sequences in advanced preferences did the trick. Note that Disable potentially insecure escape sequences should be set to 'no', enabling the escape sequences.

[viniciusmuller]

Trying to run neofetch from tmux using kitty terminal, it hangs at Checking for graphics (10.0s max. wait) for some seconds and then just prints the text without any image. And if I run it from outside a tmux session, it just works.

[DanielEliasib]

Just to add here, I'm having the same problems using the windows terminal with WSL 2 and with chafa backend, as it has been stated the problem is because neofetch can't get the terminal size. The only information I can add is that it works if I have gimp open, and completely hangs if I have nautilus open.

Some logs, maybe they are useful for something.

neofetchlog-gimp.log
neofetchlog-naut.log
neofetchlog-solo.log

[ghost]

Hm, not working in konsole/yakuake, tried pixterm, w3m and catimg. pixterm and catimg are displaying images (not in noefetch), dont know how to do so in w3m :(. But in neofetch, with --w3m/--catimg/--pixterm it is always shows ascii art. Imagemagick installed btw

[62832]

Sorry if this has been answered already, but what exactly is the deal with st and refusing to display w3m or sixel images outright with the alpha patch also present? Is it just due to transparency not being explicitly supported on either one?

Allegedly a few people can also get it to work in spite of the alpha patch being present, but I am yet to figure out how this could be accomplished.

EDIT: For the time being, ueberzug seems like the best solution without having to worry about disabling alpha on st.

[ghost]

Sorry if this has been answered already, but what exactly is the deal with st and refusing to display w3m or sixel images outright with the alpha patch also present? Is it just due to transparency not being explicitly supported on either one?

Allegedly a few people can also get it to work in spite of the alpha patch being present, but I am yet to figure out how this could be accomplished.

EDIT: For the time being, ueberzug seems like the best solution without having to worry about disabling alpha on st.

I am not sure at 100%, but I think it's because st render is double-buffered, and how sixel/w3m draws images on a terminal is by drawing on the current term buffer

[clohr-vc]

Not working on kitty 0.23.1 either. All dependencies installed, using the icat plugin directly works flawlessly with all image types. In neofetch, it just blinks for a second, then disappears.

[ghost]

Not working on kitty 0.23.1 either. All dependencies installed, using the icat plugin directly works flawlessly with all image types. In neofetch, it just blinks for a second, then disappears.

neofetch --kitty I think