WordPress uses plupload to handle uploads - I’m not saying this solves the problem - just might be some lessons to learn from it.
Does the server down sample the uploaded images already?
The current 3mb limit is really bugging me as it is preventing phone uploads right now. If we up the limit to 10mb and then downsize the image to 3mb on the server side while we work this out it would seem a decent tradeoff.
I agree, the handheld computer would load this in memory - whether this is a full expanded 32 bit bitmap in memory or an optimization, it will still consume a bunch of client memory FIRST. That is with the full resolution of whatever size image (max equipment camera resolution) it has.
There is no way around it if you want to do JS mobile resizing.
Alternatively, the user can upload whatever image, and the server reduces the size down to 2.1 megapixel (full HD) as the MAXIMUM resolution.
After that you can play around with either mozjpeg for a really small jpeg image or an indexed png image if the colors used are below 256 (or maybe ~400) for the ULTIMATE minimal size.
At the very least, we should start introducing cjpeg/jpegtran from MozJpeg 3.0 into the docker image for the ultimate JPEG compression.
We’ve recently upped that limit to 10MB. Not sure it has been committed to a new image yet. Thoughts @sam?
It should be, but you need to update discourse docker
cd /var/discourse git pull ./launcher rebuild app
The 10mb limit has been in for a while now. @zogstrip is the server-side resizing maximum (either in filesize, or dimensions) still on your plate?
Also update on current popular “cameras” and their image sizes:
iPhone 5s and 6 have 8 megapixel, 3264×2448 resolution cameras. The additional fluffery is in image quality, not absolute image size. Which is sensible.
It still is on my plate. I tried using filesize but there’s no way to reliably predict what it’ll be. So I guess it’ll have to use dimensions.
Just updating here to note that @zogstrip did indeed add some site settings to get overly large images resized on the server. That is in place, so the server bit is handled.
Still 100% unclear how we can solve this on the client, by asking the client to please send a more ‘reasonably’ sized image to us rather than a 10mb monster JPG.
The general trick is to use the canvas API, then you can allow users to resize and even crop prior to uploading.
As I said above, I think this will destroy phone memory as it loads the entire bitmap in memory, then resizes it in memory. I’m not sure some devices could even load this much data in the browser without causing a problem?
I’d need to see some actual proof that this wasn’t blowing out browser memory on the device, because I… don’t believe.
Note that the 6s takes larger pictures, 4032 × 3024 = 48 megabytes of memory…
Yeah I guess this approach is mostly about a value add for desktop as opposed to mobile, I wonder if mobile has any platform specific APIs to allow you to ask for smaller images.
This is one of those edge cases when having an “app” really helps even if its only a shell on top of a web browser.
Why would we even worry about this on desktop? Mobile is always the main concern, who wants to upload 100MB of image over a cellular network?
On Desktop people want to be able to crop/resize and blur info prior to uploading … its a great value add.
On mobile you are just trying to protect against explosions
This is still completely unresolved. Other than mobile devices mostly having 2GB RAM these days, there’s still no reasonable way to get the browser to resize images on the client before uploading…
Someone pointed me to this
I want us to keep researching. Would be a good pr-requested issue … images ain’t exactly getting any smaller on smartphones.
This is pretty fast!
Tested with a bunch of GoPro photos, and it takes 250ms, and the resized image is nice.
Canvas does in 3ms but it’s a worse result.
That was back in Ye Olde 2014 … @sam correctly pointed out it has been a while since we looked at this… so here’s a dump from my iPhone 7, excluding panoramas, cropped images, and screenshots
- 381 jpg photos, 1.02gb = 2.90mb each on average
- Largest 6.0mb
- Smallest 1.4mb
3mb limit would exclude 133 / 381 images; 4mb limit would exclude 37 / 381 images.
So maybe you’re right @sam, perhaps we should bump this default from 3mb to 4mb here in 2018?
Sure I bumped us up to 4 out-of-the-box.
Our NGINX config remains at 10 out-of-the-box.
I think we could sponsor a plugin that experiments with https://github.com/nodeca/pica.
It takes just 300ms for me in my phone .
- User selects image to upload
- Image is larger than
max upload size
- We offer to resize the image to a preset size.
- We upload the resized image.
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.