Better lossy compression needed for for uploaded images. Making the case for implementing WebP.

[Titianbeetle]

There is a growing number of photographers using Bluesky to show off their work, but the uploaded images are rendered poorly compared to other social networks. WebP compression could be used instead since it would compress large images to a smaller file size with a minimal loss of detail.

Example: an uploaded portrait image of 3753 x 5004, at 300 dpi (original file size 7.25 MB) is compressed + automatically scaled via Webp to 1920 x 2560 at 72dpi (file size 72.6 KB) with a 32 Bit depth. The output is a smaller file compared to the same image currently compressed on Bluesky (file size 210 KB) and with only a minimal loss of detail compared to the original.

WebP files explained

[DavidBuchanan314]

+1 from me, importantly, webp has very broad browser/platform support: https://caniuse.com/webp

If you use the APIs directly, you can actually upload and view webp images on bluesky today. However, the default bsky.app client re-compresses using jpeg on upload, and the official appview's image CDN re-compresses (again!) to jpeg by default.

In theory, switching to webp would just be a config change (famous last words)

But also, I think both the client and CDN would benefit from some logic to decide when not to re-compress and/or re-scale an image (e.g. if it's already below some size threshold), which ought to eliminate any redundant re-compressions.

One detail to consider is that, like GIF and APNG, webp can be animated. Guards would need to be added to prevent the animation from playing by default (I'd suggest that the CDN should strip all but the first frame)

Despite the great browser support, there is a small subset of users who are annoyed by webp images, because their operating system (or other tooling) still doesn't have great support it. Hopefully they're a shrinking minority, as webp support continues to grow across the board.

[snarfed]

+1 from me too, hit this in Bridgy Fed recently. We proxy image blobs and redirect requests for them to their original URLs. @gabboman's https://github.com/gabboman/wafrn uses webp for profile pictures, which it sounds like the bsky.social PDS and image CDN still may not support? And Bridgy Fed doesn't convert (yet). I expect we'll also hit this with other types, eg SVG.

(Btw, looking at the lexicons, post image blobs can supposedly be any type, but profile pictures and banners can only be PNG or JPG. I wonder if that difference is intentional, or just a historical artifact?)

[snarfed]

Hey, what do you know, webp may be supported now after all, at least for profile pictures, maybe also in posts. looks like the bsky.social PDS and/or CDN convert them to jpeg. eg https://bsky.app/profile/gabboman.app.wafrn.net.ap.brid.gy was bridged from https://app.wafrn.net/blog/gabboman , which has a webp profile picture.

The blob is https://atproto.brid.gy/xrpc/com.atproto.sync.getBlob?did=did:plc:whco57z2rz6jvi3wv3o56jdi&cid=bafkreib7laxfuwt76tecdn3dzaqcv3ea6ywq5uduudb7daehc733no73fe , which redirects to https://media.wafrn.net/1710855461530_81c749fff194627803de2164d6fdcecacb9bdb99.webp, which serves a webp image (with no Content-Type 😕).

[craigS89]

So this is probably too late as Ive seen Bluesky has now moved to using Webp as its main file format, but i was going to argue at this point it might be better to use its successor .avif. It has en even better quality to file-size ratio and is supported by all major browsers and Operating systems.