Is there any way to make the image in Konsole not look so blocky? As you can see below, Konsole vs. Kitty…
KONSOLE:
KITTY:
Whilst many see Konsole as the superior terminal, Kitty is famous for having superior graphics rendering.
I’m not sure that rendering a fetcher’s image is a particulary high ticket agenda for the future of Linux development.
Quite disappointing and shortsighted point of view.
This is not about “rendering a fetcher’s image”, it’s about the highest quality option to display graphics in the terminal, like, for example, for gnuplot output, to see a preview of fonts, or to display images in the terminal.
Any of these are possible and easy, with zero mental overhead, over a remote connection via ssh on a server. For example, you can type iv <font> | <image> | <...> to get the desired output in the terminal. (iv from Github by kenshaw)
Same with gnuplot, the kittycairo terminal allows to crunch data on a server and view it directly in the terminal.
And lots of applications more, besides just displaying a fetcher’s image.
Sadly, these serious applications seem to have gone unnoticed. I followed the discussion for quite some time before Konsole implemented sixel and kitty graphics, and there was significant developer resistance besides this being one of the most popular requests at the time.
And the implementation is somewhat half-baked, as OP’s request shows. A few hours ago, I came across this Reddit post
which exemplifies Konsole’s graphic support vs Windows Terminal and iTerm2. There is room for improvement here.
I hope that the mindset of ‘who needs graphics in the terminal’ goes away, along with the Bill Gates quote “640 kB ought to be enough for anybody”.
Is this sixel or kitty’s image format? i.e. This is a good case for study. Let people reproduce it and play with it. However, the images seem to be different in compression sizes, etc. It might be apples and oranges..
There are different requirements with regard to a tui display, the two that still seem to be the most prevalent are speed and portability. e.g. how many terminal emulators are able to interpret kitty graphics formats?
Even Sixel emulators aren’t available everywhere and sixel is far older than kitty.
1 Like
I followed the Reddit post and looked at the examples. These are exclusively sixel images.
Too bad that I couldn’t post the link.
Regarding the portability: Among terminal app maintainers, the consensus seems to be that sixel support is the most widespread and kitty (v2) is superior in scope and speed. A lot of graphics-capable terminal apps support both these two. Same as Konsole does.
The issue with graphics in terminal is a chicken-egg issue; more apps are going to support this if the terminal emulators which support it are more widespread.
I’d say the 48 (!) terminal emulators from your ‘Are we Sixel yet?’ page are testament of widespread enough support for the graphics itself. Having kitty v2 protocol is just the cherry on top. I expect a migration to kitty after a time while the terminal emulators support both, kitty as the better protocol and sixel as the safe fallback.
if the terminal emulators which support it are more widespread
This is perhaps not exactly what I meant? e.g. Portability - being able to interpret & render kitty formats everywhere with other code bases, in all emulators (notice some of the big hitters that don’t support sixel, let alone kitty).
i.e. At this point I wouldn’t give up my favorite terminal emulator(s) just to display kitty graphics. Although I admit, I do fall back on xterm for such reasons, but, only because it is available just about everywhere (e.g. places I have no control over). I don’t think kitty will reach this level of ubiquity.
I’m afraid I didn’t get your point then. “Render[ing] kitty formats everywhere with other code bases, in all emulators” is a mighty tall order. It took ages for proper unicode support to penetrate the code bases. You had code pages, JIS encoding, ASCII, EBCDIC, … and issues still crop up every now and then. Graphics are even more complex than simple character encoding.
For now, a graphics-capable program should support sixel as the least common denominator and kitty as future protocol. If the terminal can render sixel and, ideally, kitty on top of that, there’s sufficient support.
It’s impossible to expect 100% penetration right from the start, but this is a viable path.
See above: Sixel support is good enough now. I’d love to see kitty support across the board, but for the moment, the programmers can adopt kitty at a more leisurely pace. Which ‘big hitters’ don’t support sixel? I think most bases should be covered – GNOME terminal, Konsole, alacritty, foot, kitty, iTerm2, Windows Terminal, urxvt, xterm, even PuTTY – what do you think is missing?
My point is: Konsole is my favorite terminal emulator and the KDE default, and I use graphics quite often in it, either sixel or kitty, depending on the program. I waited long enough to not have to resort to an alternative, like you do with xterm sometimes. xterm will also go away, by the way. More and more Wayland usage. People seem to settle on kitty and foot as popular terminal choices there. So, the support for kitty graphics increases just by Wayland usage alone.
This is why I wish that Konsole has even better graphics support than it has right now.
I can’t answer your question, but what is the name of this fetch that you’re using?
I’m using Fastfetch
1 Like
Well, according to the link I posted, gnome terminal has sixel seated but it’s not maintained and it’s not by available by default (which may or may not be a good thing for kitty graphics), the xfce default terminal doesn’t have sixel (I think) and lxqt’s terminal doesn’t have support for sixel either (*). I’d like to see it happen though.
Anyway, my two cents is that I’d like it to be implemented asap (in more places than now) and then polished (as I believe you’ve just written).
(*) One might think that qterminal would be ripe for sixel, especially since lxqt is supposed to be a lightweight desktop (I like qterminal’s xml menuing system), but, I think there’s pushback and not enough demand.