phanpy icon indicating copy to clipboard operation
phanpy copied to clipboard

Bug: avatars are not displayed in the correct format in the timeline

Open coxde opened this issue 1 year ago • 1 comments

Describe the bug Hi,

I found out that avatars are not displayed in the correct format in the timeline (.jpg) while the original one are .png or .gif. BTW, they are displayed correctly in profile page.

  • Which site: dev.phanpy.social
  • Which site version: 2024.06.23.5d6a43e
  • Which instance: It's a GoToSocial server, and I can't reproduce it on a Mastodon server, so maybe it's also related.

To Reproduce Steps to reproduce the behavior:

  1. Go to the timeline
  2. Find out that some users' avatars are with black background
  3. Use browser dev tool to check avatars' format, they're .jpg instead of .png or .gif

Expected behavior They should be displayed as the original format, or at least without the weird background.

Screenshots Timeline or post avatar: image

Profile avatar: image

Desktop (please complete the following information):

  • OS: Linux
  • Browser: Firefox
  • Version: 107

Additional context N/A

coxde avatar Jun 23 '24 11:06 coxde

Just for the reference :)

It seems that this issue should be converted to a feature request.

When GtS reencodes images to create thumbnails, it creates the thumbnails in jpg format, which means the transparency/alpha layer gets lost for things like gifs or pngs which originally had transparent backgrounds.

Phanpy will be showing the thumbnails/static versions by default, which is sensible behavior. Other clients do the same thing, but they usually also let you specify that you wanna see the animated/full-size version instead of a thumbnail for things like emojis, avatars, and headers. For example, pinafore will let you select the setting "Autoplay animated GIFs", which will then use the full-size/original media for everything. Likewise there's a similar setting in Tusky.

If phanpy introduces a similar setting, that would be a neat fix I think. To "fix" the issue from our side would require rejigging how we do media reencoding, and possibly having to pull in other libraries and stuff, which is a much larger piece of work.

coxde avatar Jun 26 '24 14:06 coxde