Topic: Minimum image quality for gif?

Just got a gif submission deleted and the reason is "does not meet minimum quality standards (Compression)", does anyone know whats the acceptable compression? I cant find it anywhere...
My gif is 1920x1080 (1.12 MB) so I thought the file size and resolution should be alright?

The file size is less important here, more important is what it looked like. Usually posts deleted for compression looked really bad due to having way too much compression artifacts.

Edit: I checked, and issue is likely that the compression method you used causes the image to have significant amounts of unnecessary dithering on flat colored surfaces. That in general should not be happening. Flat colored surfaces should have flat coloring rather than being composed out of several colors in grid pattern.

yeah, it's dithering within the color
your best bet is to avoid it by rendering it to apng or gif with a higher color count

I would personally use WEBP but APNG should also be fine. Though, the animation seems to have simple enough colours that you might be able to get away with a more optimised palette.

Fun fact, there is a weird hack you can do with GIF files to allow them to display more than 256 colours at once. It's very impractical and not worth the effort but still fun to know about.

Thank you all! Toonsquid doesnt support exporting to apng or webp so I guess I'll have to take the long way and convert from a video file...

If making a new loop in 2026, APNG or WebM is better, but we still have tons of archaic GIFs out there.

alphamule said:
If making a new loop in 2026, APNG or WebM is better, but we still have tons of archaic GIFs out there.

There are still situations where I'd say GIF is best, like pixel art or flat-color aliased art.
But yeah I'd assume most artists would want one of those two.

braixenarchivist said:
There are still situations where I'd say GIF is best, like pixel art or flat-color aliased art.
But yeah I'd assume most artists would want one of those two.

Honestly the only reasons to use GIF in 2026 are you need to use outdated animation software that can't export to a better format or you are catering to users on machines so old that connecting them to the internet is a security risk. WebP gives you better file sizes than GIF in almost all scenarios, including pixel art and low colour count animations. The biggest reason it hasn't taken on is, as mentioned, a lot of art software doesn't support it for whatever reason.

eightoflakes said:
Honestly the only reasons to use GIF in 2026 are you need to use outdated animation software that can't export to a better format or you are catering to users on machines so old that connecting them to the internet is a security risk. WebP gives you better file sizes than GIF in almost all scenarios, including pixel art and low colour count animations. The biggest reason it hasn't taken on is, as mentioned, a lot of art software doesn't support it for whatever reason.

The same could be said for WebP replacing PNG and JPG since it can do lossless and lossy still images as well also usually at smaller sizes.

And if we're going for features over accessibility, JPEG XL is better than WebP. It's got lossless and lossy compression that's smaller than WebP and can do animations. You can even losslessly convert old JPG into JPEG XL and save space.

The biggest reason WebP got popular while JPEG XL didn't from what I understand is because Google pushed WebP very hard (and actively suppressed JPEG XL adoption but that's another story).

braixenarchivist said:
And if we're going for features over accessibility, JPEG XL is better than WebP. It's got lossless and lossy compression that's smaller than WebP and can do animations.

This is true, but having tried both, I'd point out that you do pay a decoding-time cost for higher compression.

I have many scans (a full A4 scan at the resolution I use is ~3700x5200 px). It takes about 1s to decode a lossless maximum compression WEBP, and about 5s to decode a JXL of the same scan with lossless maximum compression (via 'sxiv' viewer; imlib2 is responsible for the WEBP and JXL decoding in this case).
I also have A3 stitched scans (~5200x7400px), which typically have decoding time of ~3s in WEBP format / ~10s in JXL format.

I expect if e621 supported JXL, then the kind of long decoding times I mentioned might come up for some of the ancient art (paintings etc with a lot of fine detail). For the 'typical' e621 image (relatively little high-frequency detail), decoding time would probably not be much different from WEBP.

This matters much less for smaller / more compressible images, of course. I use a somewhat ridiculous thumbnail size (768x768) with sxiv, and converted the entire thumbnail cache into JXL for significant space gains without incurring any noticeable loading delay in thumbnail-view mode.

Plus there is still room to optimize decoding times, as well as the fact that JXL supports 'progressive' decoding (if you encode the image for it..) which can turn 'long decoding times to get to fully resolved image' into a non-issue.

EDIT: But much of this is subject to support for specific features. Eg. WaterFox supports JXL, but only static, not animated, no idea if progressive load is supported.. There are enough features in JXL that saying 'XYZ app supports JXL' is not really adequate at this point - it's more likely that it supports a subset of JXL features. Would not be surprised if many apps take a long time to support high-bit-depth JXL, for example.

You can even losslessly convert old JPG into JPEG XL and save space.

This gives a typical 10% saving, FWIW (for comparison, I got 25%-60% savings from maximum effort (cjxl -d 0 -e 9) conversion of already-lossless source images). Worth doing if you have a lot of JPGs; but IIRC not all metadata types are preserved (this is true in general, not just for the 'lossless JPG transcode' mode). Off the top of my head I think EXIF and XMP are supported but IPTC is not.

braixenarchivist said:
You can even losslessly convert old JPG into JPEG XL and save space.

You can also losslessly convert back to old jpeg for images converted from old jpeg to jpeg xl. i.e. round-trip jpeg -> jpeg xl -> jpeg is lossless, if you need to serve old jpeg format to users with images that were converted from old jpeg to jpeg xl on the server.

braixenarchivist said:
The same could be said for WebP replacing PNG and JPG since it can do lossless and lossy still images as well also usually at smaller sizes.

And if we're going for features over accessibility, JPEG XL is better than WebP. It's got lossless and lossy compression that's smaller than WebP and can do animations. You can even losslessly convert old JPG into JPEG XL and save space.

The biggest reason WebP got popular while JPEG XL didn't from what I understand is because Google pushed WebP very hard (and actively suppressed JPEG XL adoption but that's another story).

But yeah, we have a JPEG XL evangelist among our devs; we'll likely add it eventually.

eightoflakes said:
Honestly the only reasons to use GIF in 2026 are you need to use outdated animation software that can't export to a better format or you are catering to users on machines so old that connecting them to the internet is a security risk. WebP gives you better file sizes than GIF in almost all scenarios, including pixel art and low colour count animations. The biggest reason it hasn't taken on is, as mentioned, a lot of art software doesn't support it for whatever reason.

Oh, and even with newer hardware, high-resolution GIFs are slow as hell compared to even a lossless VP9 video.

I'd love to see JPEG XL supported more.

aacafah said:
Is this Catt0s's alt or something?

But yeah, we have a JPEG XL evangelist among our devs; we'll likely add it eventually.

Not my alt but yes I love JPEG XL. Sadly adoption is stupidly slow.

watsit said:
You can also losslessly convert back to old jpeg for images converted from old jpeg to jpeg xl. i.e. round-trip jpeg -> jpeg xl -> jpeg is lossless, if you need to serve old jpeg format to users with images that were converted from old jpeg to jpeg xl on the server.

We could, out MD5s would be wrong, but it could be worth it.

catt0s said:
We could, out MD5s would be wrong, but it could be worth it.

Being able to find most posts by just using the MD5 hash is a huge advantage of this site, and breaking that sucks
Not to mention that not modifying what we're given is one of the core tenets of archival

watsit said:
You can also losslessly convert back to old jpeg for images converted from old jpeg to jpeg xl. i.e. round-trip jpeg -> jpeg xl -> jpeg is lossless, if you need to serve old jpeg format to users with images that were converted from old jpeg to jpeg xl on the server.

Full jpegxl support is actually 0%, partial support is 12% and only on iOS devices
https://caniuse.com/jpegxl

so this conversion would be needed for likely 90%+ of users

donovan_dmc said:
Full jpegxl support is actually 0%, partial support is 12% and only on iOS devices
https://caniuse.com/jpegxl

I don't think most websites want or need 'full' support, TBH. 'decoding of both lossy and lossless images' + 'progressive decoding' + 'both animated and still images' + 'displayed with 24bpp (/32bpp with alpha) accuracy' is probably a reasonable goal.

JXL spec includes other things, like high bit depth support, layer/frame blending modes, very high resolution (<=1,073,741,823 pixels per side), and 'non-display channels', which a browser probably wouldn't benefit much from supporting at this point. At most, >8bits-per-channel pixels should be sensibly downgraded to 8bits-per-channel for display.

Unfortunately, not supporting animation yet is understandable -- if you look at the spec , you can see that there are some features, like previous-frame-references and jxli frame-indexes for seeking, that the browser probably should involve itself with and not just hand off entirely to libjxl. There's no doubt that JXL animation is significantly more complicated than GIF (Not sure about WEBP; I think that is still relatively simple).

savageorange said:
I don't think most websites want or need 'full' support, TBH. 'decoding of both lossy and lossless images' + 'progressive decoding' + 'both animated and still images' + 'displayed with 24bpp (/32bpp with alpha) accuracy' is probably a reasonable goal.

JXL spec includes other things, like high bit depth support, layer/frame blending modes, and very high resolution support, which a browser probably wouldn't benefit much from supporting at this point. At most, >8bits-per-channel pixels should be sensibly downgraded to 8bits-per-channel for display.

Unfortunately, not supporting animation yet is understandable -- if you look at the spec , you can see that there are some features, like previous-frame-references and jxli frame-indexes for seeking, that the browser probably should involve itself with and not just hand off entirely to libjxl. There's no doubt that JXL animation is significantly more complicated than GIF (Not sure about WEBP; I think that is still relatively simple).

Sure, but partial support is still at just twelve percent, and only on iOS devices
not having full support really doesn't matter, I just pointed it out to say it doesn't have near enough adaptation to even consider it
Any perceived benefits do not at all outweigh the cost, and likely won't for a good while longer

donovan_dmc said:
Being able to find most posts by just using the MD5 hash is a huge advantage of this site, and breaking that sucks

True. Actually for one adaptation of e621ng, I considered having a system that stores an original md5 and a compressed md5. Anyway, it is looking good for jpeg XL, i have heard (take with some salt) both chrome and firefox have started working on implementation again.