Was that given a go?
Another example of what is possible on ImageOptimization in browser:
This video goes over the tech. They compiled the state of art codecs (the same we use on the server for Discourse) to WASM 
Looks like a cool, optional thing for Discourse.
The WASM for mozjpeg can be compressed to 48k and the WASM for OptiPNG is 93k.
「いいね！」 9
My image folder grows to 42.3 GB.
So I think I need to figure out image processing and storing in Discourse 
「いいね！」 1
I’m not sure if this is the right topic to post on, but I am very interested in knowing if there’s a way to automatically downsize images before they get stored in my discourse. My community is going to be very image heavy.
I’m less than a week in and already 350 MB used and not even open to general public yet. Would like to be able to resize images down to some resolution so that I keep them < 1MB or something like that (based on image resolution though as per norm I think).
I’d recommend using Digital Ocean spaces or S3 for your images so you don’t need to worry about space so much.
It seems unlikely that a community that really likes images is going to want really bad ones. 
We already have max_image_megapixels site setting, can you try toning that down?
「いいね！」 2
@sam Yes, but, the problem is there’s a big difference between reducing some resolution that most people won’t even notice (IMO big diminishing returns), versus blocking them from uploading at all. On my main site, I downsize to 1500x and no one cares. But if they can’t upload it’s a huge hassle.
@pfaffman This sounds perfect, I guess I need to read:
I wonder, this is probably something I need to do sooner than later, because I’m guessing trying to migrate the files from discourse hosting to s3 could be hard?
「いいね！」 1
I do support a simpler mechanism longer term, something like
All images must be smaller than 500k but allow people to upload stuff up to 2000k and fix on server if needed by either downsizing or reducing resolution. Try resizing on client first if possible.
But yeah, getting to this level of fidelity will take quite a while.
「いいね！」 2
There is a rake task that will do it, but I’d say that sooner is better than later.
「いいね！」 1
当社のユーザーの多くはモバイルデータ通信を利用しており、通信速度が3G以下になることもあります。多くの場合、送信する画像の画質よりも速度が重要視されます。
3G環境（約2Mbps）では、5MBの画像を送信するのに約20秒かかります。速度が低下すれば、この時間はさらに長くなる可能性があります。
@Falco が指摘している通り、同様のアルゴリズムを用いれば、クライアント側で画像を圧縮し、解像度を下げることで、5MBの画像のサイズを190KBまで削減できます。これにより、送信が高速化され（3G環境では約1秒）、リソースの消費も少なくなります。
このような機能はロードマップに含まれていますか？もし含まれている場合、それは近い将来の実装ですか、それとも遠い将来のものですか？
それは最終的に実現したいと考えていますが、現在の公開ロードマップ（#releases）には含まれていません。
今週、この機能に関する RFC を作成し、少なくとも仕様面では前向きに進められるようにします。
「いいね！」 7
「いいね！」 7
ありがとう、素晴らしいですね 
Android も学んでほしいものです 
この機能に加えて、Lightbox は画像切り替えボタンとしても機能します。
このライブラリは興味深いですね: GitHub - silvia-odwyer/photon: ⚡ Rust/WebAssembly image processing library · GitHub
WASMバイナリは高速でメモリ効率に優れているため、理想的な選択のように思えます。
「いいね！」 3
クライアントサイドでの画像圧縮（可能であれば）が、低スペックなホスティング（例：Digital Ocean の共有 CPU インスタンス）の Web サーバーパフォーマンスに顕著な影響を与えるか気になっています。
時々 CPU 使用率が急上昇しているのを目撃しており、それは画像圧縮が必要なユーザーのアップロードと相関していると考えています。同様の影響を見たことがある方はいますか？
「いいね！」 2
実装について Optional image optimization before upload で議論中
「いいね！」 1