🍵
It's funny how well a relatively low-resolution (max 1024 or 2048 pixels on either side), WebP-mangled 15-80 KiB image can get the message across.
Take a look at the images I've posted to this account; I'm always extremely purposeful on the images' resolution, format, and compression factor, even when posting from mobile (which I do most of the time). Very, very few of my images are over 100 KiB.
We're spoiled by our storage and bandwidth.
On corporate platforms, all images get the same amount of mangling, and many images get properly mangled by being decompressed and recompressed over and over again.
I love that #GoToSocial gives its users agency to choose how their images are encoded.
@rl_dane they don’t, they force webp for thumbnails now and explicitly rejected the option of sticking to frmats people can actually see
I'd be happier if AVIF was an option, but for low-fidelity, low-file-size images, WebP is ahead of JPEG.
@rl_dane doesn’t help if your (retro-)computer can only show GIF, JPEG and perhaps PNG
How retro?
I view WebP and AVIF quite often with [nsxiv] (debian package link], openports.pl link) from @tut
nsxiv should run beautifully well on almost any hardware. I even use it sometimes via ssh -CX to my raspberry pi.
For web browsers, even links2 seems to support webp, such as when I paste in this link
@rl_dane
As much as I would like to see AVIF and JPEG XL (but not WebP) succeed, support for them nowadays is indeed still quite limited.
Besides, retro does not necessary mean very old hardware, people often use exotic devices with software those came with for the sake of aesthetics. E.g. my ThinkPad T43 from 2005 is capable of decoding JPEG XL, but not my Lumia 950 from 2015🤷
@mirabilos
@rl_dane @mirabilos
Like I said, this wouldn't be a problem is servers honoured the "Accept" header, I think it should be trivial to make a filter in nginx in front of actual Fedi server software for paths ending in the likes of ".webp" and if the client requests specific types, not just "image/*" — pass it to a tiny proxy, which would convert it on-the-fly to desired format. Coupled with caching, it shouldn't be a great hit on performance.
@m0xee @rl_dane ideally GtS could generate thumbs in the requested format by the requester just using the file extension they want, the links like https://toot.mirbsd.org/fileserver/01BF7Z603VK76GWT5HJZDBANT8/attachment/original/01J785X523X1KV1SQ0DH11CRCE.png (though original/ is always in the encoding of the sender and not recoded) and https://toot.mirbsd.org/fileserver/01GS55SW7VWYN3BFRYCX5NW526/attachment/small/01PSHCXWQ6T4HVK0K654J4J5JT.jpg (thumbnails are generated by GtS) have the extensions as desired
(and I think only the originals, not the thumbs, are federated out? so this only affects local clients only AIUI?)
@mirabilos
> only the originals are federated
True. I was thinking about media proxy. Not sure GtS has this feature, but Masto, Pleroma and snac2 do this (optionally): the instance caches the original media from federated posts locally, so instance users don't have to download it from remote instances — good for privacy and reduces the overall load on the network.
Converting the media cached this way to the desired format on the fly might make sense too!
@rl_dane
@rl_dane @mirabilos
If those guys at Google are right and everyone indeed wants WebP today — shouldn't be such a big problem.
I intend to try this on my snac2 instance, see if I can come up with a working solution. It might be non-trivial with other Fedi server software, but snac2 uses paths with clear extensions — shouldn't be too hard.