Help understanding video and image size restrictions

On size, Lemmy uses pict-rs to handle image uploads. There's a per-instance-settable byte limit max on the max file size that can be uploaded to a pict-rs instance. I've got no idea whether it supports animated gifs.

EDIT: So, a bit of experimentation later, Pict-rs does take WebM. And WebM can contain AV1-encoded stuff, which can be lossless. But AV1 doesn't appear to be optimized for GIF-style flat color images, the way MNG and APNG are. Still, you can get a (larger) file which a pict-rs instance will accept as long as it doesn't hit the filesize limit, which represents the video in the GIF file without loss:

        $ stat --format=%s ibjtdug-imgur.gif
    804394
    $ ffmpeg -i ibjtdug-imgur.gif -c:v libaom-av1 -aom-params lossless=1 ibjtdug-imgur-av1-lossless.webm
    $ stat --format=%s ibjtdug-imgur-av1-lossless.webm
    1856545
    $

That slightly more than doubles the filesize.

That being said, I will point out that GIF itself really isn't a great format for this. Like, the reason that many codecs won't do well with this is because they deal poorly with dithered images. The original data (the original original data, pre-GIF-encoding) isn't dithered, and got smashed down to 256 colors and an ordered dither when it was encoded as a GIF, and it'd probably be preferable to not dither it; using that would probably result in a better-quality and smaller video.

EDIT2: It's too bad that pict-rs doesn't support APNG, which it looks like can clamp down on it further:

        $ ffmpeg -i ibjtdug-imgur.gif ibjtdug-imgur.apng
    $ stat --format=%s ibjtdug-imgur.apng
    995418

That's still enlarging it compared to the GIF. But then if we give it a pass through apngopt:

        $ apngopt ibjtdug-imgur.apng ibjtdug-imgur-opt.apng
    $ stat --format=%s ibjtdug-imgur-opt.apng
    512106

And now it's 36% smaller than the original GIF. But presently, pict-rs doesn't accept APNGs.

We can upload it to catbox.moe, though:

EDIT3: I also apparently yanked the loop setting off somewhere in there, but I'm sure that it's technically possible to have an APNG loop.

EDIT4: Ah, apparently one needs the -plays 0 flag for infinite looping on ffmpeg; ffmpeg apparently doesn't read that from the source:

        $ ffmpeg -i ibjtdug-imgur.gif -plays 0 ibjtdug-imgur-plays.apng
    $ apngopt ibjtdug-imgur-plays.apng ibjtdug-imgur-plays-opt.apng

And there we go:

EDIT5: It looks like, while the stock Lemmy Web UI displays WebM and one can see the one I posted on lemmy.today's pict-rs instance above along with the two APNGs on catbox.moe, the alternative Alexandrite Web UI apparently omits showing WebMs. So I don't know what the client support matrix is for all this --- gotta worry about pict-rs, the client, and if it's a Web client, the Web browser accessing the client.

EDIT6: Piefed's Web UI looks like it's fine with displaying both the APNGs and the WebM. Searching for a public mbin server --- apparently fedia.io stopped allowing anonymous access --- based on kbin.earth, it looks like mbin's Web UI doesn't show any of the images inline, though it does provide links to them (which may be a good idea from a privacy standpoint. I've pointed out before that external inline images have privacy implications for users).

EDIT7: Hmm. While pict-rs doesn't accept uploads of APNG on lemmy.today, looking at the pict-rs crate, it says that it does support APNG (and GIF, for that matter).

Supported ext file extensions include apng, avif, gif, jpg, jxl, png, and webp.

"Curiouser and curiouser", said Alice.

EDIT8: And based on the docker/docker-compose.yml in the Lemmy git repository, the version of pict-rs being used with Lemmy should support it.

https://github.com/LemmyNet/lemmy/blob/main/docker/docker-compose.yml

image: asonix/pictrs:0.5.17-pre.9

It looks like pictrs's APNG support should have been done as of commit 719626de07cfed793bf6b2b812ce988c8f6acd4c. pict-rs's 0.5.17-pre.9 tag was commit 2c84bb20923f6562c79d0684dc8736965e70a3da, much later, so it should be in. Dunno; maybe there's some restriction in Lemmy that I couldn't find quickly.

EDIT9: And it's not that it was only recently that Lemmy pulled in that version of pict-rs. On the pict-rs repo, checking which releases had the pict-rs APNG support:

        $ git tag --contains 719626de07cfed793bf6b2b812ce988c8f6acd4c

The output there includes v0.5.7. In the lemmy repo:

        $ git blame docker/docker-compose.yml|grep asonix
    426684d90f docker/docker-compose.yml     (Dessalines       2025-02-10 17:27:22 -0500  64)     image: asonix/pictrs:0.5.17-pre.9
    $ git blame docker/docker-compose.yml 426684d90f~|grep asonix
    027017b0a8 docker/docker-compose.yml     (renovate[bot]    2024-06-15 06:53:11 -0400  78)     image: asonix/pictrs:0.5.16
    $ git describe --tags 426684d90f
    1.0.0-alpha.0-10-g426684d90
    $ git describe --tags 027017b0a8
    0.19.4-13-g027017b0a
    $

So while they did pull in pict-rs 0.5.17-pre.9 pretty recently, and it's only to be in the 1.0 release (and lemmy.today is running 0.19.11), they pulled in pict-rs 0.5.16, which should contain the APNG support, way back for the lemmy 0.19.4 release. That does sort of suggest that either there's a bug in Lemmy or that there's some intentional restriction that I'm not promptly finding in the Lemmy codebase to prevent GIF and APNG uploads.

19 comments

EDIT: For real though, you can always just hotlink embed the source like this (provided the source site allows hotlinking):
Example: ![](http://my.image.url/image.gif)
This specific image: ![](https://www.maxim.com/wp-content/uploads/2021/05/ibjtdug-imgur.gif)
If you're looking for somewhere to upload files with clear limits which are explained, I suggest catbox.moe
- I'm pretty sure that pict-rs doesn't force-convert things to WebP -- the vanilla Lemmy Web UI just fails the upload, and I'm sure that it at least also does PNG and JPEG, as static images go. It might be that your client is doing a conversion to try to work around that limitation?
  
  I only upload photos from the web interface. They all always become webp.
On size, Lemmy uses pict-rs to handle image uploads. There's a per-instance-settable byte limit max on the max file size that can be uploaded to a pict-rs instance. I've got no idea whether it supports animated gifs.
EDIT: So, a bit of experimentation later, Pict-rs does take WebM. And WebM can contain AV1-encoded stuff, which can be lossless. But AV1 doesn't appear to be optimized for GIF-style flat color images, the way MNG and APNG are. Still, you can get a (larger) file which a pict-rs instance will accept as long as it doesn't hit the filesize limit, which represents the video in the GIF file without loss:

$ stat --format=%s ibjtdug-imgur.gif 804394 $ ffmpeg -i ibjtdug-imgur.gif -c:v libaom-av1 -aom-params lossless=1 ibjtdug-imgur-av1-lossless.webm $ stat --format=%s ibjtdug-imgur-av1-lossless.webm 1856545 $
That slightly more than doubles the filesize.
That being said, I will point out that GIF itself really isn't a great format for this. Like, the reason that many codecs won't do well with this is because they deal poorly with dithered images. The original data (the original original data, pre-GIF-encoding) isn't dithered, and got smashed down to 256 colors and an ordered dither when it was encoded as a GIF, and it'd probably be preferable to not dither it; using that would probably result in a better-quality and smaller video.
EDIT2: It's too bad that pict-rs doesn't support APNG, which it looks like can clamp down on it further:

$ ffmpeg -i ibjtdug-imgur.gif ibjtdug-imgur.apng $ stat --format=%s ibjtdug-imgur.apng 995418
That's still enlarging it compared to the GIF. But then if we give it a pass through apngopt:

$ apngopt ibjtdug-imgur.apng ibjtdug-imgur-opt.apng $ stat --format=%s ibjtdug-imgur-opt.apng 512106
And now it's 36% smaller than the original GIF. But presently, pict-rs doesn't accept APNGs.
We can upload it to catbox.moe, though:
EDIT3: I also apparently yanked the loop setting off somewhere in there, but I'm sure that it's technically possible to have an APNG loop.
EDIT4: Ah, apparently one needs the -plays 0 flag for infinite looping on ffmpeg; ffmpeg apparently doesn't read that from the source:

$ ffmpeg -i ibjtdug-imgur.gif -plays 0 ibjtdug-imgur-plays.apng $ apngopt ibjtdug-imgur-plays.apng ibjtdug-imgur-plays-opt.apng
And there we go:
EDIT5: It looks like, while the stock Lemmy Web UI displays WebM and one can see the one I posted on lemmy.today's pict-rs instance above along with the two APNGs on catbox.moe, the alternative Alexandrite Web UI apparently omits showing WebMs. So I don't know what the client support matrix is for all this --- gotta worry about pict-rs, the client, and if it's a Web client, the Web browser accessing the client.
EDIT6: Piefed's Web UI looks like it's fine with displaying both the APNGs and the WebM. Searching for a public mbin server --- apparently fedia.io stopped allowing anonymous access --- based on kbin.earth, it looks like mbin's Web UI doesn't show any of the images inline, though it does provide links to them (which may be a good idea from a privacy standpoint. I've pointed out before that external inline images have privacy implications for users).
EDIT7: Hmm. While pict-rs doesn't accept uploads of APNG on lemmy.today, looking at the pict-rs crate, it says that it does support APNG (and GIF, for that matter).
Supported ext file extensions include apng, avif, gif, jpg, jxl, png, and webp.
"Curiouser and curiouser", said Alice.
EDIT8: And based on the docker/docker-compose.yml in the Lemmy git repository, the version of pict-rs being used with Lemmy should support it.
https://github.com/LemmyNet/lemmy/blob/main/docker/docker-compose.yml
image: asonix/pictrs:0.5.17-pre.9
It looks like pictrs's APNG support should have been done as of commit 719626de07cfed793bf6b2b812ce988c8f6acd4c. pict-rs's 0.5.17-pre.9 tag was commit 2c84bb20923f6562c79d0684dc8736965e70a3da, much later, so it should be in. Dunno; maybe there's some restriction in Lemmy that I couldn't find quickly.
EDIT9: And it's not that it was only recently that Lemmy pulled in that version of pict-rs. On the pict-rs repo, checking which releases had the pict-rs APNG support:

$ git tag --contains 719626de07cfed793bf6b2b812ce988c8f6acd4c
The output there includes v0.5.7. In the lemmy repo:

$ git blame docker/docker-compose.yml|grep asonix 426684d90f docker/docker-compose.yml (Dessalines 2025-02-10 17:27:22 -0500 64) image: asonix/pictrs:0.5.17-pre.9 $ git blame docker/docker-compose.yml 426684d90f~|grep asonix 027017b0a8 docker/docker-compose.yml (renovate[bot] 2024-06-15 06:53:11 -0400 78) image: asonix/pictrs:0.5.16 $ git describe --tags 426684d90f 1.0.0-alpha.0-10-g426684d90 $ git describe --tags 027017b0a8 0.19.4-13-g027017b0a $
So while they did pull in pict-rs 0.5.17-pre.9 pretty recently, and it's only to be in the 1.0 release (and lemmy.today is running 0.19.11), they pulled in pict-rs 0.5.16, which should contain the APNG support, way back for the lemmy 0.19.4 release. That does sort of suggest that either there's a bug in Lemmy or that there's some intentional restriction that I'm not promptly finding in the Lemmy codebase to prevent GIF and APNG uploads.
MP4 > GIF
- I mean yeah but having to use handbrake to encode it is less than great.
  
  I feel like something’s gone very wrong if the MP4 is dimensionally smaller but has a larger file size than the GIF
I'm on @jerry@infosec.exchange 's cursed Mbin instance, and I can upload GIFs as images. The upload filesize limit here is 6,000,000 bytes with the drawback that I can't upload in better formats like MP4 or WebP.
- I can increase that if you like.
  
  based admin
  
  5.71MB is plenty generous. I'd give up 5MB of that if we could have anonymous browsing again. I can't recommend Mbin to people if they have to log in to see anything. Would converting all uploads to WebP lighten the load?
I've pretty much given up on Lemmy media uploads and I default to hotlinking these days.
Catbox.moe is a popular place for uploading for this purpose. Alternatively, I decided to roll my own for various reasons and you can DM me if you're interested in testing the platform.