[Feature Request] ASCII Frontend for Radar View

[acxz]

It would be really cool if wttr.in can provide a radar frontend that can be viewed in an ascii format.

[chubin]

Have you checked v3.wttr.in (curl v3.wttr.in)? The original idea behind it was exactly that

[acxz]

The original idea behind it was exactly that

Cool!

Have you checked v3.wttr.in (curl v3.wttr.in)?

I just did but ended up getting a bunch of gibberish output with curl v3.wttr.in/Bayern.sxl in kitty.

https://v3.wttr.in/Bayern in the browser does work for me tho.

But I guess getting the map in the terminal is the first step, excited to see this progress and glad it was on your mind from the beginning!

[chubin]

Can you try this in Kitty:

curl -s v3.wttr.in/Bayern.png | kitty icat --align=left

[acxz]

Can you try this in Kitty:

curl -s v3.wttr.in/Bayern.png | kitty icat --align=left

That worked just fine.

I can also use timg via curl -s v3.wttr.in/Bayern.png | timg -

PS. personally prefer timg as it automatically resizes and works with terminals without non image protocols. (although ofc the resolution will be reduced, since those terminals don't support sixel) For things like displaying readable text, it might not be a good idea, like the above example. But maybe for just radar it is prob good enough.

[chubin]

I think that ideally all options (sixel, MIP, Kitty-protocol and usual pseudographics à la timg) should be supported, and the user should have the choice

[acxz]

timg does support Kitty, iTerm, and pseudographics

Also have you heard of notcurses? Do check it out! https://github.com/dankamongmen/notcurses

[chubin]

There is no point of rendering graphics and then converting it back to pseudographics via timg, but notcurses is a cool thing indeed, and we should consider using it for v3.wttr.in && radar pseudographics rendering

[chubin]

(@acxz I've just ordered your book about notcurses on Amazon; it seems to be very interesting and pretty relevant to me)

[acxz]

I'm not the author or owner of notcurses, but I'm glad u find notcurses interesting.

What exactly are we referring here with "pseudographics"? I have been assuming them to be ascii block characters like, 1) full blocks, 2) half blocks, 3) quad blocks, or 4) sextant blocks.

timg supports those as well as directly rendering the Kitty and iTerm protocols. It does not convert it back to pseudographics (ascii block characters).

One usecase of this could be however, that not all terminals support these fancy graphics protocols and thus rendering in a best effort ascci block character set might be the only option in such a case.

[acxz]

But in any case, notcurses supercedes timg in terms of rendering capabilities as notcurses is a bit more low level and includes sixel, sextant ascii block, and other goodies which timg does not.

[chubin]

Yes, indeed, I don't know why, I somehow had an idea that it was you, but it does not really matter; nevermind; and the book is still pretty interesting. Look forward to read it (it goes far beyond notcurses per se).

What exactly are we referring here with "pseudographics"? Everything what can be displayed on the terminal (excluding sixel/IIP).

Have you checked v2.wttr.in out? you can't get it from the PNG representation back, in this quality. So direct terminal rendering will be of course better than any results of autoconversion of graphics into terminal output (this being said, timg is of course a great project, without any doubts, just for other usecases)

[chubin]

(please ignore the last mentioning; posted a wrong link; already fixed)

[acxz]

So direct terminal rendering will be of course better than any results of autoconversion of graphics into terminal output

Totally agreed, direct terminal rendering is the way to go. I still believe that sixel can provide on par results with conversion from png -> sxl for displaying on the terminal. But that's not exactly the pipeline we are looking for.

But my concern and motivation here is that not all terminals support high fidelity direct terminal rendering and in such a case, following back to the next best thing (sextant ascii blocks) should be a solution we provide for users trying to view v3.wtter.in.

tldr; support both sixel and sextant blocks for v3.wttr.in