(bug) Image uploads are rescaled to 2000x2000, even if source image is smaller

[HeyItsLollie]

Bluesky appears to rescale images to fit a maximum resolution of 2000x2000 pixels. While this step is understandable for handling larger images, it makes no sense to perform this on smaller images.

This also likely means that file size does not appear to be a factor in whether an image is processed and recompressed. Images are simply made to fit 2000x2000 indiscriminately. If these images are being stored at this resolution, they'd be wasting more server space and network bandwidth than necessary in the process.

I've noticed this with my own images posted via PC (Win 11, Firefox), and also in many images uploaded by other users.

Ideally, if an image is smaller than the max resolution or file size, simply leave it be. Additionally, the front-end should state the max resolution and file size somewhere, so that users can better prepare their images for the platform if they have the means.

[Zero3K]

I saved an image from Bluesky and can see that the size is almost 2000x2000 (but the file size is only 231 KB) This really needs to be fixed ASAP.

[HeyItsLollie]

I've accidentally submitted this issue with the "feature request" label - this was intended to be a bug report, sorry.

One behavior that leaves me puzzled: image URLs include the line "\rs:fit:2000:2000:1:0", leaving me to believe that this scaling might actually be performed when delivering it to a user, and not on upload as I originally assumed. But I don't understand why this step would even be necessary. Browsers have long supported arbitrary scaling of images, and it's a common feature of any modern graphics rendering library. What does this step actually achieve?

[pfrazee]

I think is a question for @devinivy, I'm not sure what the backend logic is and I'm 75% sure we don't scale up in the client

[devinivy]

That's right, images are resized on demand and then cached. So if the original image in a user's repository is very large, we can still serve a resized, compressed, jpeg version of it to the client as e.g. their avatar which is generally displayed much smaller. The next time another user asks for the same avatar image, they will be served the cached version. Especially in the federated setting where the originals could be varied in size/format/etc, this ensures clients are getting consistent views of images on the network.

We'll take a look into the upscaling issue 👍

[HeyItsLollie]

So if the original image in a user's repository is very large, we can still serve a resized, compressed, jpeg version of it to the client as e.g. their avatar which is generally displayed much smaller.

So one big problem with the current approach is that the resized/recompressed JPG is being served regardless of whether that version is actually smaller than the original image. PNGs can be considerably smaller in filesize compared to JPGs, and this format is commonly used in art spaces — especially true for pixel art.

As a quick example, here's a random screenshot from an old PC-98 game. 640×400, a mere 22kb.

After Bluesky resizes and compresses it, the image becomes 408kb, an 18× increase.

Even if this is only resized and cached on demand, the version that ends up being delivered is unnecessarily bloated, compared to the original. This is where it'd make the most sense to cache and deliver the original instead (with certain metadata stripped).

[Zero3K]

This bug hasn't been fixed yet.

[Tuss36]

I too am greatly vexed by this. Especially for jpeg works, as it makes the jpeging around the edges much more noticeable, though it's also especially bothersome for creators that post things at particularly small resolutions.