I’m on an instance using Mbin and have seen that extension, but there’s usually a link I can click to show the picture. This one however showed fine, so maybe it depends on how it’s linked. The ones I saw before like that were in the comments, not the post.
Honestly, I think that the right route is to update them. Especially on the Threadiverse, where the server time is donated and images are the big storage/bandwidth consumers—I’d rather do what’s possible to keep costs down. My own favorite Android client, Eternity, is unmaintained and can’t do AVIF, which I think is unfortunate, but I can view them externally using a browser and I suspect that unless someone decides to take over maintenance, I’ll probably need to switch clients anyway. Either clients get maintained or ultimately die to bitrot…
When I’ve uploaded images recently, I generally submit AVIF and then also include a WebP link in the body or a comment for older clients. In this case, it sounds like the instance may be transcoding to AVIF, so that probably isn’t an option.
EDIT: Well, I thought that it couldn’t do AVIF, but…somehow I can view it in Eternity. Huh. I did change Android devices recently. Not sure if that’s a factor.
EDIT2: Ah. Sounds like Firefox has app-level AVIF support, and Android 12+ has OS-level support. Might be that Eternity had been relying on the OS.
Eternity, which is still my favorite Android client, can’t, though it’s unmaintained (though it can open AVIF images externally in a browser).
I’ve generally also submitted an alternate WebP link when I upload AVIF to help people using older clients. But, yeah, I really think that it’d be better to just get clients updated, as it’d help get bandwidth demands and disk space demands down for everyone. The Threadiverse is running on donated server resources, and images are gonna be the big storage and bandwidth consumer.
EDIT: Hmm. Apparently I can presently view it in Eternity. See my other comment in this thread—might be that it was relying on Android OS-level support and I was using an old version of Android until recently.
Which is weird, because I remember seeing this comic in 2014, five years before AVIF. I only remember it because my wife and I joked about it in the hospital while our oldest son was being born, and he just turned 12.
Yeah it’s very common for CDNs to transcode images (convert them to a different format) to save bandwidth. Your browser or app tells the server which image formats it supports using the Accept HTTP header, and the server returns the image in the best format it supports. There’s been significant improvements to data compression technology in the last 20+ years, and an AVIF file is usually around 50% the size of a comparable JPEG file of similar quality.
Cloudflare does this (although I’m not sure if it’s only a paid feature or if it’s available on free accounts too), and major services like Google, Facebook, Instagram, etc do it too. At those scales, halving the amount of bandwidth used by images is a significant saving.
If an app gets an image format it doesn’t support, it’s likely not setting the Accept header correctly.
Edit: There’s also JPEG XL which is essentially supposed to be like “JPEG 2.0”, but it’s not widely supported yet.
I’m on Mbin and the image doesn’t show, moreover the .avif is a strange extension for a picture file.
I’m on an instance using Mbin and have seen that extension, but there’s usually a link I can click to show the picture. This one however showed fine, so maybe it depends on how it’s linked. The ones I saw before like that were in the comments, not the post.
It’s a (somewhat) newer image format that has better compression than WebP. Some clients still don’t support it.
https://en.wikipedia.org/wiki/AVIF
You’ll probably be fine if you’re using a Web UI of some sort, since browsers have pretty good support, but not all mobile clients can handle it.
It’s cool that it compresses down to 28kb, but is it not showing up on many devices/apps a too high price for that?
Honestly, I think that the right route is to update them. Especially on the Threadiverse, where the server time is donated and images are the big storage/bandwidth consumers—I’d rather do what’s possible to keep costs down. My own favorite Android client, Eternity, is unmaintained and can’t do AVIF, which I think is unfortunate, but I can view them externally using a browser and I suspect that unless someone decides to take over maintenance, I’ll probably need to switch clients anyway. Either clients get maintained or ultimately die to bitrot…
When I’ve uploaded images recently, I generally submit AVIF and then also include a WebP link in the body or a comment for older clients. In this case, it sounds like the instance may be transcoding to AVIF, so that probably isn’t an option.
EDIT: Well, I thought that it couldn’t do AVIF, but…somehow I can view it in Eternity. Huh. I did change Android devices recently. Not sure if that’s a factor.
EDIT2: Ah. Sounds like Firefox has app-level AVIF support, and Android 12+ has OS-level support. Might be that Eternity had been relying on the OS.
Support is very widespread so clients that don’t support it are likely using outdated libraries.
Eternity, which is still my favorite Android client, can’t, though it’s unmaintained (though it can open AVIF images externally in a browser).
I’ve generally also submitted an alternate WebP link when I upload AVIF to help people using older clients. But, yeah, I really think that it’d be better to just get clients updated, as it’d help get bandwidth demands and disk space demands down for everyone. The Threadiverse is running on donated server resources, and images are gonna be the big storage and bandwidth consumer.
EDIT: Hmm. Apparently I can presently view it in Eternity. See my other comment in this thread—might be that it was relying on Android OS-level support and I was using an old version of Android until recently.
Which is weird, because I remember seeing this comic in 2014, five years before AVIF. I only remember it because my wife and I joked about it in the hospital while our oldest son was being born, and he just turned 12.
.zip uses an image proxy server which might be doing the conversion automatically.
Yeah it’s very common for CDNs to transcode images (convert them to a different format) to save bandwidth. Your browser or app tells the server which image formats it supports using the
AcceptHTTP header, and the server returns the image in the best format it supports. There’s been significant improvements to data compression technology in the last 20+ years, and an AVIF file is usually around 50% the size of a comparable JPEG file of similar quality.Cloudflare does this (although I’m not sure if it’s only a paid feature or if it’s available on free accounts too), and major services like Google, Facebook, Instagram, etc do it too. At those scales, halving the amount of bandwidth used by images is a significant saving.
If an app gets an image format it doesn’t support, it’s likely not setting the Accept header correctly.
Edit: There’s also JPEG XL which is essentially supposed to be like “JPEG 2.0”, but it’s not widely supported yet.