Use pixelated (up)scaling for custom emoji #270

Open

cnx wants to merge 1 commits from cnx/akkoma-fe:pixemoji into develop

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

ci/woodpecker/pr/woodpecker Pipeline was successful Details

d547ffa00f

Use pixelated (up)scaling for custom emoji

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

Member

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_pixelated.png.webp

30 KiB

mfm-x4_default-scale.png.webp

94 KiB

ci/woodpecker/pr/woodpecker Pipeline was successful

Details

This pull request has changes conflicting with the target branch.