I think we could sponsor a plugin that experiments with https://github.com/nodeca/pica.
It takes just 300ms for me in my phone 
.
Workflow:
max upload size
Since browser support can be flaky around all the APIs needed, a plugin to experiment and allow image heavy sites to test may work.
Great idea, we don’t want our users to not be able to upload the pictures they want, rather they should be given the option to resize it or get the server to resize it down to the max size.
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.
My image folder grows to 42.3 GB.
So I think I need to figure out image processing and storing in Discourse 
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?
@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?
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.
There is a rake task that will do it, but I’d say that sooner is better than later.
Most of our users use mobile data and sometimes their internet speed may be 3G or less. Many times, the quality of the images they send is not important and speed is more important to them.
In 3G upload (about 2Mbps), sending a 5MB image takes about 20 seconds, and this time may be much longer as the speed decreases.
As @Falco points out, with similar algorithms, the size of a 5 MB image can be reduced to 190 KB by compressing at the client-side and reducing the dimensions. This way both sending faster (in 3G, about 1 second) and fewer resources are needed.
The screenshot above shows the sending of
the image in the Telegram Messenger
Is there such a feature in the Roadmap? If the answer is yes, is it far or near?
It’s something we want to eventually do, but it’s not in our public roadmap at #releases.
I will write a RFC on this feature this week so we can move forward with it, at least specification wise.
This is already possible in iOS. Like so (will post screenshot stand by)
Via
I selected “large”. It still screws up the orientation though!
Thanks, that’s great 
I wish Android learns too 
In addition to this feature, lightbox can be an image rotation button
This library looks interesting: https://github.com/silvia-odwyer/photon
A wasm binary seems like the ideal choice because it’ll be fast and memory efficient.
I’m curious if client side image compression, when possible, would have a notable impact on web server performance with low spec hosting (eg shared cpu digital ocean instance).
I see a spike in CPU utilization occasionally that I believe correlates with users uploading images that need to be compressed. Has anyone seen similar impact?
