it's been interesting to compare + contrast how mastodon currently thumbnails stuff with how the latest code on #GoToSocial main thumbnails stuff

now that we have ffmpeg embedded in the GtS binary we can transcode thumbnails to new(ish) efficient formats like webp, which can result in quite some savings in terms of thumbnail storage space

for example, given an original image of size ~500KiB (I'm using this very cool mermaid by Daniela Schreiter -- https://mastodon.art/@Fuchskind/112971326959280452), Mastodon thumbnails it to a .png file of size ~200KiB, while the current snapshot version of GtS thumbnails it to a .webp of size ~17KiB, that's a pretty decent difference! By contrast, version 0.16.0 of GtS thumbnails this to a jpeg of size ~20KiB

ofc it's not consistently smaller in all cases to thumbnail something to a webp, sometimes a webp will actually be larger than a png thumbnail, for the same dimensions, in cases where the png contains only a limited number of colors and complexity; also webp is lossy, so you absolutely do give up some definition and clarity in thumbnails compared to png

also, while webp is usually a little smaller than jpeg, it definitely uses more resources in GtS's case to thumbnail something to a webp, since with jpeg thumbnailing we don't need to invoke the embedded WASM ffmpeg at all, we can just do it with the fast + fairly efficient code we used before

so after a bunch of experimenting, we've now settled on using jpeg thumbnails where we can -- ie., when an input image is of type jpeg, or of type png, gif, or webp without potentially having an alpha (transparency) layer; and for all other types, we now invoke the embedded ffmpeg to create a webp thumbnail :)

this might change again before v0.17.0 comes out, since we're still exploring and messing around with trying to find a decent balance of performance, image clarity, and storage space

(oh and also just to clarify, we never transcode the full sized images, I'm talking specifically about thumbnails here)