Use pixelated (up)scaling for custom emoji

cnx commented

2023-01-04 18:00:47 +00:00

First-time contributor

Smaller custom emoji are usually sprites which looks blurry with smooth upscaling. Before/after screenshots attached.

before.png

74 KiB

after.png

66 KiB

cnx added 1 commit

2023-01-04 18:00:48 +00:00

Use pixelated (up)scaling for custom emoji

ci/woodpecker/pr/woodpecker Pipeline was successful

Details

d547ffa00f

Mergan added the

Feature

label

2023-02-01 07:28:43 +00:00

floatingghost commented

2023-03-10 19:11:42 +00:00

Owner

apologies, i totally missed this

i'll have to test the upscaling with non-sprite images and see if it behaves normally, i'll get back to you

apologies, i totally missed this i'll have to test the upscaling with non-sprite images and see if it behaves normally, i'll get back to you

Oneric commented

2024-02-09 16:27:15 +00:00

Owner

image-rendering: pixelated only doing pixelated upscaling but smooth downscaling does already mostly avoid impacting non-pixel emoji since at normal display in-line or as a reaction they are small enough to not be (noticeably) upscaled anyway

However, if MFM is involved this does unfortunately sometimes lead to noticeable degredation :\

Compare default upscaling:

to pixelated upscaling:

(In an ideal world emoji would come with metadata specifying how to up/downscale them)

A hackish way to get it right most of the time, would be to only apply pixelated if no MFM upscaling is involved — but this leads to incosistencies with the same low-res pixelart emoji displaying very differently depending on MFM, plus even then there’ll probably still be some (presumably rare’ish) edge cases where it still looks bad even without MFM

Well, my opinion has no authority here, but imho given these complication and image-rendering settings depending on the frontend anyway, i’m afraid the best "fix" is to instead pre-upscale pixelart emoji by some integer factor before uploading unfortunately

`image-rendering: pixelated` only doing pixelated **up**scaling but smooth *down*scaling does already mostly avoid impacting non-pixel emoji since at normal display in-line or as a reaction they are small enough to not be (noticeably) upscaled anyway However, if MFM is involved this does unfortunately sometimes lead to noticeable degredation :\ Compare default upscaling: ![mfm-x4_default-scale.png.webp](/attachments/b14cc127-3b9a-454f-87c9-ee5cd1045668) to pixelated upscaling: ![mfm-x4_pixelated.png.webp](/attachments/a86a70f6-0bea-4b8a-aad0-700f75a384c9) (In an ideal world emoji would come with metadata specifying how to up/downscale them) A hackish way to get it right most of the time, would be to only apply `pixelated` if no MFM upscaling is involved — but this leads to incosistencies with the same low-res pixelart emoji displaying *very* differently depending on MFM, plus even then there’ll probably still be some (presumably rare’ish) edge cases where it still looks bad even without MFM Well, my opinion has no authority here, but imho given these complication and `image-rendering` settings depending on the frontend anyway, i’m afraid the best "fix" is to instead pre-upscale pixelart emoji by some integer factor before uploading unfortunately

mfm-x4_default-scale.png.webp

94 KiB

mfm-x4_pixelated.png.webp

30 KiB

Riedler commented

2025-03-26 07:08:14 +00:00

Contributor

what if we apply pixelated to images smaller or equal to 32px in either dimension? glossing over the javascript in that region of the code, this shouldn't be too hard to implement and produce decent results

what if we apply `pixelated` to images smaller or equal to 32px in either dimension? glossing over the javascript in that region of the code, this shouldn't be too hard to implement and produce decent results

Oneric commented

2025-03-27 15:25:14 +00:00

Owner

If it doesn’t create too much complexity or perf overhead it seems worth a try