[Bug]: Excessive storage usage for thumbnails

[Nutomic]

Requirements

• Is this a bug report? For questions or discussions use https://lemmy.ml/c/lemmy_support
• Did you check to see if this issue already exists?
• Is this only a single bug? Do not put multiple bugs in one issue.
• Is this a backend issue? Use the lemmy-ui repo for UI / frontend issues.

Summary

While looking at the code for generating link metadata I noticed a major problem with the way thumbnails are generated: In this line images are fetched using pictrs endpoint GET /image/download which stores the full size image in pictrs. This same fullsize image is then returned as "thumbnail", there is no resizing done at all. To confirm this I looked at some API responses from lemmy.ml, and in fact post.url and post.thumbnail_url always point to an identical image with the exact same dimensions (sometimes over 1000px). Thumbnails are also generated whenever a remote post is received, so even an instance with no local user activity will quickly grow in storage size.

To resolve this I think pictrs should add an option like GET /image/download?resize={pixels}. If an image is larger than this, it should be downscaled before storing, and the full sized image discarded. It would also be good if we could test image functionality as part of api tests to ensure that thumbnails are always below a certain size.

cc @asonix @dessalines @phiresky

[asonix]

While I do want to support custom params like this on the ingest side, it won't be in 0.5

However, 0.5 includes features like automatically removing thumbnails that haven't been accessed in a given timeframe, and automatically removing proxied media that hasn't been accessed in a given timeframe.

I think ingest parameters will be a priority for 0.6, since it will allow applications to have different requirements for different uploads.

[Nutomic]

Sounds good. Btw for any admins reading this, 0.19 adds a new config option pictrs.cache_remote_images which can be set to false to prevent these image downloads.

[kroese]

The images are stored in their original format, but lemmy-ui request them like this:

https://domain.tld/pictrs/image/hash.jpeg?format=webp&thumbnail=256

So they are converted to much smaller dimensions before sending them to the visitors. I always assumed this was by design. Because otherwise it will become impossible to change the thumbnail width or height in the future without them becoming blurry.

And some Android clients display the posts in a feed-style where they use the original image instead of the downscaled ones,. If you throw away the originals because lemmy-ui does not need them, clients like Voyager/Jerboa/Boost cannot show high-quality feeds anymore.

[Nutomic]

The problem is that pictrs stores the original images without any size limit, so they may be thousands of pixels and multiple MB. That means over the long term a lot of storage is used which will make instance hosting more expensive. So there needs to be some size limit, even if its 500 or 1000 pixels. Besides the thumbnail_url field is completely useless now if its identical to the url.

[kroese]

@Nutomic The size limits are specified in the pictrs settings in the compose file:

      - PICTRS__MEDIA__GIF__MAX_WIDTH=256
      - PICTRS__MEDIA__GIF__MAX_HEIGHT=256
      - PICTRS__MEDIA__GIF__MAX_AREA=65536

Maybe pictrs does not enforce these limits, but it should resize or reject any files larger than this, so if not then its a bug.

[Nutomic]

Thats only for gifs and wont apply to other file formats. There may be similar settings for jpeg etc, but thats not a good solution because the main image can be large, only thumbnails should be small.

[kroese]

Sorry I ment:

PICTRS__MEDIA__IMAGE__MAX_FILE_SIZE

And Im not sure what you mean by "main image". Maybe you are referring to posts that consists of nothing more than an image? In that case it doesnt matter to make the thumbnail small, since you always have a link to the original.

But I am referring to posts where the thumbnail image was automaticly retrieved from the URL's metadata (og:image tag). For such posts the only image that is stored is in the thumbnail_url, its not identical to url.

Maybe PictRS can be changed to automaticly resizes images until they conform to MAX_FILE_SIZE instead of simply rejecting to store them. But in any case this feels more like a PictRS issue than a Lemmy issue.

Edit: Now I think about it.. You are right that the current max filesize parameter is not sufficient. Because it also applies to user-uploaded images. So this is indeed a Lemmy issue, because PictRS cannot know if the upload is a thumbnail or user upload. So Lemmy needs a way to signal a lower max filesize to PictRS when storing a thumbnail.

[dessalines]

This can be done via nginx, or better, using the new pictrs "ProxyAllImages" setting.

So this is indeed a Lemmy issue, because PictRS cannot know if the upload is a thumbnail or user upload. So Lemmy needs a way to signal a lower max filesize to PictRS when storing a thumbnail.

Lemmy doesn't store images, only pictrs does. So the pictrs size limits apply to both uploads and thumbnails.

[Nutomic]

This issue is still valid. While there is a general size limit in pictrs, it cannot distinguish between thumbnails which should be limited to 100px or so, and post images which should be 1000px or larger. The problem does not happen when using image proxy mode, but not all instances do. So most Lemmy images still store full size images as "thumbnails".

So to resolve this we still require a parameter GET /image/download?url={url}&resize={int} in pictrs, which downscales images before storing them. Alternatively we could download images directly with reqwest, and then upload to pictrs using POST /image?{args} which already supports the resize param.