Maybe it is possible to integrate Tcell with Sixel image format.
Here is a working project:
https://github.com/diamondburned/tcell-sixel
I think it will be great to view images just as usual text mails
in terminal. Also it can be possible to view html rendered to png just
in terminal.
To render html to png:
CutyCapt --url=file:///home/et/mail.html --out=mail.png
Then to sixel and display in terminal.
For now I am using this config:
[openers]
text/html=qutebrowser
image/png=feh -x -
image/jpg=feh -x -
I know there is thread on mail list "displaying images within aerc",
but I saw "tcell-sixel" project and decided to write about it again.
Regards,
John Mcenroy
---
handplanet@outlook.com
On Sat Nov 12, 2022 at 12:53 PM EST, Johnmcenroy wrote:
> Maybe it is possible to integrate Tcell with Sixel image format.> Here is a working project:> https://github.com/diamondburned/tcell-sixel>> I think it will be great to view images just as usual text mails> in terminal. Also it can be possible to view html rendered to png just> in terminal.
Hey John,
You can render images in the terminal with something like catimg[1] or
img2sixel[2]. Then you just set a filter to use it:
[filters]
image/*=catimg -w $(tput cols) -
That library does look nice. I think I prefer keeping image rendering
external, though.
[1]: https://github.com/posva/catimg
[2]: https://github.com/saitoha/libsixel
--
Jason Cox
jasoncarloscox.com
Without sixel support in tcell the output of catimg is pretty useless
(very bad resolution). I think having native sixel (or even better, kitty
image protocol) support would be great.
The current solution that came up in the already mentioned thread with
kitty is not terrible, but that is done outside of aerc, just overlayed
on it which is pretty fragile.
2022. nov. 12. 19:29:58 Jason Cox <me@jasoncarloscox.com>:
> On Sat Nov 12, 2022 at 12:53 PM EST, Johnmcenroy wrote:>> Maybe it is possible to integrate Tcell with Sixel image format.>> Here is a working project:>> https://github.com/diamondburned/tcell-sixel>>>> I think it will be great to view images just as usual text mails>> in terminal. Also it can be possible to view html rendered to png just>> in terminal.>> Hey John,>> You can render images in the terminal with something like catimg[1] or> img2sixel[2]. Then you just set a filter to use it:>> [filters]> image/*=catimg -w $(tput cols) ->> That library does look nice. I think I prefer keeping image rendering> external, though.>> [1]: https://github.com/posva/catimg> [2]: https://github.com/saitoha/libsixel>> --> Jason Cox> jasoncarloscox.com
On Sat Nov 12, 2022 at 2:01 PM EST, Bence Ferdinandy wrote:
> Without sixel support in tcell the output of catimg is pretty useless > (very bad resolution). I think having native sixel (or even better, kitty > image protocol) support would be great.
Right you are. I've used img2sixel successfully outside of aerc, but
since I don't usually use a sixel-capable terminal, I hadn't actually
tested in aerc. I just copied the example filter out of the config --
guess I should have tried it first :)
In that case, I'm all for adding sixel support; viewing images directly
in the terminal is much more convenient than opening an external
program. I still think the actual image to sixel conversion should be
performed by a filter, but aerc needs to be able to actually render the
sixel if the terminal supports it.
--
Jason Cox
jasoncarloscox.com
I actually use alacritty with sixel support and I rather sixel since is
an open standard among many proyects while kitty is not and is bloated,
you will have to force us all to use kitty? I do not think this is the
right move, sixel is been and will be suported on most terminals.
{gemini,https}://{,rek2.}hispagatos.org
https://hispagatos.space/@rek2
On Sat Nov 12, 2022 at 9:29 PM +03, Jason Cox wrote:
> You can render images in the terminal with something like catimg[1] or> img2sixel[2]. Then you just set a filter to use it:
Hi Jason,
Thanks for reply, but catimg output very pixelated bad quality graphics,
img2sixel only converts various formats to sixel for view it in terminal
that support sixel image format. What I mean it support of high quality
graphcs in terminal just as wee see in usual graphics programs as Gimp.
As far as I know there are two ways to achieve this:
1. Kitty graphic protocol
2. Sixel image format, first supported on VT340 terminal.
To view high quality image in kitty:
kitty +kitten icat image.png
And to view sixel image format in xterm (convert from png to sixel):
xterm -xrm "XTerm*decTerminalID: vt340" -xrm "XTerm*numColorRegisters: 256"
convert image.png sixel:-
So if Tcell will support Sixel we get high quality images in terminal.
The same with converted html mail to png images.
Regards,
John Mcenroy
---
handplanet@outlook.com
On Sat Nov 12, 2022 at 20:25, ReK2 wrote:
> I actually use alacritty with sixel support and I rather sixel since is an> open standard among many proyects while kitty is not and is bloated, you will> have to force us all to use kitty? I do not think this is the right move,> sixel is been and will be suported on most terminals.
The kitty protocol is not tied to kitty itself, there are at least 3 other
terminal emulators currently, that implement it [1].
My knowledge is quite limited as I only read up on it when trying to get images
in aerc, but this guy who, (who wrote notcurses, if you haven't seen it yet
take a look at [2], I think it's quite convincing he knows what he is talking
about) recommends people implement the kitty protocol [3]. Both him and Goyal
[4] say that sixels is inferior and some things just don't work with it.
True, I actually use kitty. Not a huge fan - I currently find it the least
bothersome of all the emulators I tried -, but I think the protocol actually
looks like a much better idea than sixels. On the other hand WezTerm actually
supports both [5], so it should also be possible to just support both. On the
other hand you have to hand it to Goyal, he's put a lot of thought into
terminal protocols [6], for example the keyboard one is another I'd really like
to see going everywhere ...
1: https://sw.kovidgoyal.net/kitty/graphics-protocol/
2: https://www.youtube.com/watch?v=dcjkezf1ARY
3: https://nick-black.com/dankwiki/index.php/Spriteful_TErminal_GrAphics_Protocol
4: https://github.com/kovidgoyal/kitty/issues/2511
5: https://wezfurlong.org/wezterm/features.html
6: https://sw.kovidgoyal.net/kitty/protocol-extensions/
--
+36305425054
bence.ferdinandy.com
I'm pretty sure something's up with how you compose your replies John, as they
also never end up in my thread view :)
Best,
Bence
--
+36305425054
bence.ferdinandy.com
On Sat Nov 12, 2022 at 4:44 PM EST, Bence Ferdinandy wrote:
> On Sat Nov 12, 2022 at 20:25, ReK2 wrote:> > I actually use alacritty with sixel support and I rather sixel since is an> > open standard among many proyects while kitty is not and is bloated, you will> > have to force us all to use kitty? I do not think this is the right move,> > sixel is been and will be suported on most terminals.> The kitty protocol is not tied to kitty itself, there are at least 3 other> terminal emulators currently, that implement it [1].>> My knowledge is quite limited as I only read up on it when trying to get images> in aerc, but this guy who, (who wrote notcurses, if you haven't seen it yet> take a look at [2], I think it's quite convincing he knows what he is talking> about) recommends people implement the kitty protocol [3]. Both him and Goyal> [4] say that sixels is inferior and some things just don't work with it.
I'd personally cast my vote in favor of sixel as well. I've gotten the
impression that sixel, while maybe not quite as fancy as the kitty
protocol, is a bit more "standard". Mostly I prefer sixel because my
terminal emulator of choice -- Alacritty -- should be getting support
for it very soon (and will likely never get kitty protocol support from
what I've seen).
I'm not sure what it would take to support both. Ideally aerc would be
able to render whatever the underlying terminal emulator supports.
--
Jason Cox
jasoncarloscox.com
On Sat Nov 12, 2022 at 5:15 PM CST, Jason Cox wrote:
> I'd personally cast my vote in favor of sixel as well. I've gotten the> impression that sixel, while maybe not quite as fancy as the kitty> protocol, is a bit more "standard". Mostly I prefer sixel because my> terminal emulator of choice -- Alacritty -- should be getting support> for it very soon (and will likely never get kitty protocol support from> what I've seen).>> I'm not sure what it would take to support both. Ideally aerc would be> able to render whatever the underlying terminal emulator supports.
Throwing in my two cents here.
I assume that viewing of images would inherently come from viewing via a :term,
or a message viewer, both of which will require tcell-term to support the
protocol, at least for sixel - I haven't looked at the kitty protocol to see if
it's using escape codes or what to display images.
tcell-term *already* had sixel support, though it was pretty poor. I commented
it out because it had poor parsing and caused issues with other escape codes.
Also, because it was implemented "outside of tcell" (IE it wrote raw bytes to
the pty to work), tcell was unaware of screen redraws, scrolls, etc, and tcell
also wouldn't know it was there and would not do a full redraw of the screen.
Both of these are relatively easy to fix, but will come with some severe
performance penalties (tcell needs to do a screen.Sync vs screen.Show). I also
haven't thought at all about implementing scrolling.
I looked at the tcell-sixel implementation and really that would need to be
upstreamed into tcell for both tcell-term and aerc to support sixels "natively"
in tcell. I don't think gdamore is in favor of it from reading the issue tracker
though.
--
Tim