Image Compression question, even on non-lemmy image links

[misnina]

I don't really think this is a bug, but I'm asking more for clarification on how image compression is used on lemmy's UI web client.

I have uploaded pixel art, which is pretty susceptible to terrible compression. I do understand that images hosted directly to lemmy probably need to be compressed, but I thought I solved that by making the url an off-site direct link. As in, at first I uploaded a 10x upsized pixel art to lemmy through the web version, and it looked awful. So I then linked it to this one.

The actual post still links to this image, and when previewing the link when editing the post, it looks as intended.

However, after saving the edit and checking, and checking in multiple browsers and clearing cache, the preview is horrible.

On the mlem app though, it seems to be in perfectly fine quality, so I would guess it's some kind of caching/storage of the web app specifically. Can I ask the reason why if it's a direct image link, that the full expanded image would not simply use this link?

I haven't really used github issues before, so please bear with me if I've made a mistake.

[dessalines]

Lemmy-ui serves up compressed webp from pictrs, but the original jpg / file is available through pictrs. I've chosen not to have the UI display the originals tho, as those files can be very large, and taxing browsers.

Not really sure what a good solution would be, other than having one of the image links be the original. I'd just hope that browsers wouldn't ever use that by default, unless opened in its own tab or something.

[misnina]

I don't know if it's possible to have an exception for very small files? Even my most complicated and large pixel art upscaled 5 or 10 times aren't more than 50kb. (The non animated ones at least, but lemmy's treatment of gifs is an entirely different beast) I admit that I'm not really familiar with what amount of file size add up or maybe serving webps is easier, but the original png of this image is 8kb on disk, and the webp it converted to is actually twice the size at 16kb on disk. Other webps that I'm looking at on lemmy can get up to 50kb - 100kb as well.

I know this is very niche as it really only effects small scale pixel art, but clean pixel art is increasingly shafted across the web as automatic image conversion processes are put into place without an exception for these very tiny files.

[eishiya]

Another exception worth considering is one for palette-based PNGs - leave those as-is, as they're very likely to already be relatively small, and to be coming from users who already know a thing or two about image file size. This is how Twitter made their system work a few years ago, and it was one of the few good changes I recall on that site :]

The actual check should hopefully be simple and performant, as in valid PNGs, the colour type is always stored in the exact same location in the file (I think the 18th byte?), and if that type is 3, the PNG uses a palette and should probably not be converted.