the one thing i will contribute to the webp discourse is that enabling the feature in our CDN that serves webp in place of png1 and jpg would save us a fairly substantial amount of money on bandwidth. since we do not have a lot of money to begin with, this would be worth doing in 99% of cases. i have not done this because i know that people get heated about image formats. that's all i have to say here.
png gets converted to lossless webp, there would not be a quality hit
a non-random sampling (the first page of posts on my timeline) shows 30%-75% savings on each load. even if we assume the lower end, shaving nearly 1/3 off our bandwidth bill is Kind Of A Lot, especially since we moved 18tb of just images last month.
from what I could tell most of the complaints were about support for webp outside of browsers. ideal solution imo is serving webp when someone just looks at a post but serving a jpg or png when downloading the image. not sure how easy that would be to implement (did see some mention in the replies about how some images would be displayed as 'blabla.png' but when saved they would be webp, so doing the opposite doesn't seem impossible from first glance.
I believe there is no way to do this as a website (outside of a download button, which is not how people download images), this is something the browsers have to implement.
could you transcode all the webp img tags into .png or some other format with some javascript/wasm that runs on client after the page loads? or is that still too slow on today's web clients? there would be a window before the script completes where you'd still observe the webp but maybe that's ok?
Hm… I think “save as” often works by re-downloading from the URL the image points to? So you might need to re-point the URL also, and I’m not sure if you can do that without the browser trying to download the new image? Oh right but maybe you change it to a data URL after you transcode…
For performance, tragically the WebCodecs API doesn’t include ImageEncoder so it would have to be wasm I bet.
hmm. on the server side, what if you kept the original file and webp side by side, and then on the client, switch out the <img> URL on a right-click event?
I feel like viewing images on cohost is already kind of weird (the up-to-four attached at the top of a post, anyway, and especially if they have a long description) so a "view full size" button might already be pretty useful, and so also having a download link would make sense for me. kind of like how flickr handles big images?
for perspective as an artist my opinion would be if you could get the benefits of lower bandwidth when displaying inline, but still allowing download of the original file when it's viewed directly, i would not see a problem
but as a website person, i see the other issues you have to deal with trying something like that
Do it and make requests to the same image with a png extension show a picture of a form to mail you a dollar in return for access to the png
out of curiosity, does it also offer avif for jpgs? (I hear AVIF is terrible at lossless though) seems avif is pretty well adopted except for Microsoft Edge lol
it does but there's a minor cost increase over webp (unsure what the justification is but w/e), not sure if the bandwidth win would outweigh that
I've seen enough references to the avif encoder being slow in various places that I assume it's just that avif encoding requires more hardware resources
webp encoding is fast enough that they can do it on-demand and it’s still fast for requests, avif encoding is offline (my impression is that it takes multiple seconds to do high quality?)
AVIF makes everything look like it has an aggro low-pass filter on it.
honestly you should do it, and i say this as a webp disliker. put something about it in the faq if u have to. if i want to download someone's image as a png i will simply ask them to send it to me that way i have both my preferred image format and permission
Yeah, I dislike webp because of out-of-browser awkwardness but learning about why you would do it and the very tangible benefits it would have has easily swayed me. I say go for it, and if I want to download an image, I can just use my usual workarounds to get it back into png form.
I don't like it on fandom wikis because I don't like fandom wikis and assume everything they do is malicious. I like cohost and trust their decisions and want them to have more money for eggbugs
If it saves a lot of bandwidth at equal quality, I would just switch over. I've never had a problem with webp images, and if something needs PNG or whatever, you can always convert it locally
IMO webp is worth serving straight from CDN. You're saving tons of bandwidth on the server and the client, meaning 4G/5G devices save 💰 too.
It's really not that hard to convert locally, especially if you're shipping lossless. Or a button that converts on client, not a bad idea!
i'm not an artist but i would happily deal with .webp if it helped cohost remain sustainable, even if only a little. i bet someone could make a weird bodged together thing that uses imagemagick to convert downloaded files into pngs or jpegs, to make it somewhat less annoying on the user end if they're someone who is saving a lot of images off cohost.
while I know this is a real option I would gladly pay several cohost pluses per month for this to not happen until and unless we manage to get to make it JXL
Honestly I think the png > lossless webp is a complete win. The frustration should be channeled towards image editors for not supporting a modern format, not website admins, but regardless, just use a transcoding tool, you're not actually missing anything. jpg > lossy webp is of course a messier question, but personally I think that if this is part of the compression for thumbnails it's a perfect use case, and perhaps the jpgs can be offered in the lightbox? offering the pngs in the lightbox would be enough to shut up the rest of the complainers I bet, if that's not too much of a bandwidth hit.
makes me furious JXL isn't available since it has a lossless recompression mode for existing jpgs.
Seconding this, JPEG-to-WebP seems iffy but for smaller sizes where you're already reencoding it's fine imo
The only image format thing I'm pissed about is how JPEG-XL was widely supported by everyone from independent projects like Krita to companies like Adobe, but because google has their own shitty format to promote, they just went "yeah we're not doing that lol" and just did not add it to Chromium, which is more of how much of a monopoly Google has on browsers that they can influence something like this so easily rather than "image format good/bad".
webp is fine. do it. im just sad we live in an effectively jxl-less world 😔
As far as I can tell googling around the opposition to webp mostly seems to be a) some corporate shitty services trying to stuff DRM into it HTML5 video style, and b) old man yells at cloud. Assuming cohost is not gonna suddenly start DRMing shitposts I don't see a problem with implementing it lol
You should do it if it saves money. I don't like webp and it makes my experience more tedious, but so do many other changes the internet has gone through over the years. Just more of the same.
I think the inconvenience is worth it if it means cohost has more resources.
I support stuff that saves you money. I haven’t followed the discourse, so I don’t know what the counter argument is, but as long as there’s a reasonable escape hatch for the folks who need it, I say do it.
It wouldn't be a problem if browsers had built-in support to "save as" another image format. But they don't for some reason, at least not FF.
Honestly the issue isn't with the format itself but the lack of support. It'd be good to maybe have a way for user to convert that file back into a jpeg or png or direct people to other site's converter.
I can think of a handful of use cases where I would need to download the original jpeg or png specifically, and most of them are cases where there are other files embedded in the metadata that doesn't get transcoded over when saved as a different image format, mostly for video games that save custom levels or characters as pngs, with the data in the header. It would be nice if there were an opt-in toggle to say 'serve this in its original format specifically' for those sorts of cases.
