Continuing the discussion from
Optional image optimization before upload:
This feature is now available for testing here on Meta. Uploading an image here will trigger a resize/encode in the user browser before it’s sent to the server.
Please give it a try, here
in this topic or in your own community by enabling the “composer media optimization image enabled” site setting. We are leaving it off by default while we test it.
To illustrate the differences, here is a before/after:
The picture is freshly taken from my phone and went from 3.7Mb to 416Kb using our default settings.
The goal of this feature is what
@sam described here:
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.
Discourse ships with a 4MB limit for user uploads out of the box. Now I can drag and drop a 58MB JPEG:
And it uploads just fine.
Here’s a 57MB photo of some trees I took 10 years ago, dragged into the composer
That was pretty quick!
One minor point about the loading percentage metre. When uploading this 6.1MB HEIC image I found it progressed to 100% relatively quickly, then stayed there for about 50 seconds before completing. That could cause some confusion / cancelling.
Video of the issue:
Loom | Free Screen & Video Recording Software
This is awesome. A quick question, maybe an obvious one - would it be possible to only have it enabled on images higher than the site limit? Thus, images up to the limit are not processed, but if someone tries to go over it will seemingly downscale it?
This is something what I waiting for long time
Thank you Falco.
I have a question. Is it optimize older images with rebake posts or only the new uploads? Thanks again
You did not test this new feature as it doesn’t work on ingested HEIF images. I wanted to work with HEIF but browser support for decoding that is inexistent
HEIF/ISO Base Media File Format | Can I use... Support tables for HTML5, CSS3, etc. So you tested the server side HEIF conversion that we have working for quite some time already.
I could make it work by shipping a WebAssembly decoder, but those images are so rare that I didn’t find it necessary because we already have the server side conversation that
@pmusaraj worked on.
As of now this feature can ingest JPG, PNG and GIF. I can easily add support for AVIF/JPEGXL/TIFF and will do so soon.
A quick question, maybe an obvious one - would it be possible to only have it enabled on images higher than the site limit? Thus, images up to the limit are not processed, but if someone tries to go over it will seemingly downscale it?
composer media optimization image kilobytes optimization threshold to the desired value.
No it won’t. This work happens in the user browser, just in time before the upload. Rebake is a server side process, so they are quite different.
(A 28 MB photo I took from my city centre during the first confinement in 2020)
I tested the upload with various connection speeds, from 1 Gbs to 1Mbs. Worked well, except for the 1 Mbs bandwidth. The uploading behavior with the latter being a bit strange.
Stuck to 0% for a long time, then a quickly increasing percentage (faster that a 1 Mbs connection would upload), then stuck a 100% for a long time before showing this message:
Note that my picture original format is jpg, not png…
[Uploading: 20200328_141218.jpg...]() remained in the post, instead of showing the picture.
Pretty cool photo! From 28MB to 113KB is a pretty good ratio!
So this new feature only changes the ‘pre-upload’ phase. We intercept the file you try to upload, apply transformations on it and then swap the new smaller file and resume the old upload process.
It stays at 0% and uses “Processing…” in the pre-upload phase, so that is expected. I will try to also swap the “Uploading…” string at the bottom too.
It’s kinda confusing for the user that the site allows to send and display a 50 MB picture, but when I try to send a 21600×21600 108 MB picture (from
here ), I get this message:
The confusion here is the > 4 MB forbidden but 50+MB pictures allowed anyway.
4MB is still forbidden, the trick is that we optimize the image so it’s >4MB when possible, so it can survive the file size limitation.
I tried a few images from that site, but they all use PNG opacity so I can’t safely convert to JPG and the optimizer bails out.
I tested a 60MB PNG now, and the optimizer can deal with it, but uses over 4GB RAM while doing so to end up with a 360KB JPG.
What device, browser and OS version you were using on this test?
I added a new ‘Processing Upload’ composer status message so you know exactly what is happening now.
This feature is safe to be tested now, please let me know how it goes in your community!
Trying with a 1.6MB photo I took on my iPhone:
Wow, 300k and very high quality.
I started use the composer image optimization. I notice if i want to upload more photos then it will activate the reply button after the first image uploaded and only deactivate when the next image optimization finish. If click the reply button in this time then the other image uploads stuck and will compose only the text (processing). I cannot repro here because on Meta change the button quickly but on my site it hang most of the time ~10sec or more between uploads. I use the default settings and 3x ~3-4MB images
I tried it with Huawei P20 Pro Android 10 (Chrome 91.0. 4472.120) Webapp.
As you see on the video after the uploads (Feltöltés) the reply button activate. Each image ~2.3MB.
Is that possible to disable Reply button all the time while images upload?
I am confused with this settings. Is “kilobytes” is correct?
Thank you for the answer!
Thanks for the report! There was a bug when calculating the disabled status of the button:
04:37PM - 16 Jul 21 UTC
There was a UI bug when submitting multiple files in the same batch. We
Kilobyte - Wikipedia. It defaults to half a megabyte, but you can tweak as you need. I’d recommend going as low as ~300kb if you want to save the most space.
Thanks for the fix.
I see. I just thought that this is a misspelling bytes to kilobytes. Because I put
524288kb to the converter and it says 512mb. That was I confused it. But yeah now I understand Thanks
Ohhhhh I see it now. My bad!
05:46PM - 16 Jul 21 UTC
Thanks for the fix
Now it is working great!
I have a question about mobile uploads. When i upload image from mobile it will not resize the image to the target px width. I think only the quality changes. If i try it on Desktop pc the resize working. Am I missed something? Thanks
We try to resize on both mobile and desktop, but the resize operation may fail if your device hardware is too weak. When that’s the case we skip it.