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 个赞
谢谢，太好了 
希望 Android 也能学会 
除了此功能外，灯箱还可以作为图片轮播按钮使用。
这个库看起来很有趣：GitHub - silvia-odwyer/photon: ⚡ Rust/WebAssembly image processing library · GitHub
Wasm 二进制文件似乎是理想的选择，因为它既快速又节省内存。
3 个赞
我很好奇，如果可能，客户端图像压缩是否会对低配置托管环境（例如共享 CPU 的 DigitalOcean 实例）的 Web 服务器性能产生显著影响。
我偶尔会看到 CPU 使用率出现峰值，我认为这与用户上传需要压缩的图像有关。有人遇到过类似的影响吗？
2 个赞
1 个赞