Client side image resizing (discussion)

[Mesuva]

Back when 5.7 was released I noticed that the file upload in the file manager uses parts from jQuery-File-Upload - https://github.com/blueimp/jQuery-File-Upload

One of the features this library supports is the ability to do client size image resizing before uploading, using a canvas and other javascript features.

https://github.com/blueimp/jQuery-File-Upload/wiki/Client-side-Image-Resizing

I got this working today and I think it could be a great feature to include. What it means is that you can select multiple large photos directly from a digital camera for upload, think 4000px wide images, but the browser only uploads a resized version of the image, perhaps only 1920 wide. With this in place it stops images from being uploaded that the server can't handle, and also means file sizes are kept to sensible sizes.

To add this feature, I've found it only takes the inclusion of a few extra scripts in the build process and a minor adjustment of one javascript file. I can pretty much summarise it in two screenshots:

Without specifying a height and width to limit to, it defaults to 1920x1080.

Here's an example with four files I drag in (note the dimensions in the right column):

and here's the result in the file manager:

I'm thinking this is a possible feature that could be added without needing much in the way of an interface change. I'm thinking that all we'd need is either some config values or a config dashboard page where the maximum images sizes could be specified, the resize quality specified and maybe where it could be turned on and off. It could really just sit as a protection mechanism, or be just handy when you get sent a gallery of photos and you need to batch resize them before uploading.

I'm not quite sure of what the best approach would be here, I thought I was gauge some thoughts first. I also don't really know the best/preferred way of exposing a script like search.js to config values.

Thoughts? Ideas?

If anyone wants to try this out themselves, it's really just a case of adding the additional js files, adding the extra lines to the search.js file and rebuilding.
The only gotcha is that my jquery-load-image.js file is actually this already minified script: https://blueimp.github.io/JavaScript-Load-Image/js/load-image.all.min.js

Edit: this kind of feature would address the recent query here: http://www.concrete5.org/community/forums/5-7-discussion/compressresize-images-on-upload/

[Mesuva]

Alternatively, here are the two scripts effected, these can just be replaced in /concrete/js in a normal install to test it out (instead of trying to build it)

https://www.dropbox.com/s/5a7xp8knnu5ohbk/file-manager.js?dl=0
https://www.dropbox.com/s/0h3jliv44d1in89/jquery-fileupload.js?dl=0

[MrKarlDilkington]

👍

I tested this and it worked well.

Often users aren't aware of or consider image size. This solution would save bandwidth, speed up uploads, prevent users from wasting server storage, and make for faster sites. Doing this client side without any special desktop software is great.

I really like the idea of some type of dashboard configuration page to turn it on and off, set image quality, and specify maximum width and height.

[aembler]

This is cool stuff, thanks for sharing. People definitely upload files that
are too large and cause problems, I could definitely see certain sites
wanting to restrict that.

Here's how I think it ought to be implemented in the core.

1. We add a dashboard page in System and Settings > Files, named "Image
   Uploading" that has a checkbox (defaulted to off) that says something to
   effect of "Images can be no larger than" with two width/height boxes
   beneath.

2. If you check that box, the inputs are no longer disabled, and if you
   save the page, it's validated that you've placed valid numerical values in
   those boxes. These get saved using the config system.

3. If this is turned on, we enable the functionality through JavaScript.

4. Additionally, if this is turned on (by checking using the Config object)
   in FileImporter we also enable the use of our new ConstrainImageProcessor.
   This is new in 5.7.5.3 and lets developers do cool stuff with instances of
   the FileImporter. For example, on a custom project, here's how you might
   handle uploaded images that you wanted to force into JPEG, at a certain
   quality/aspect ratio:

   $config = \Core::make('field_blogger/config');
   $importer = new FileImporter();
   $importer->addImportProcessor(new ConstrainImageProcessor(1920,
   

   1080));
   $importer->addImportProcessor(new
   ForceImageFormatProcessor(ForceImageFormatProcessor::FORMAT_JPEG));
   $importer->addImportProcessor(new SetJPEGQualityProcessor(70));

Then proceed with using the file importer normally. So, if the user has
checked this checkbox, the built-in FileImporter class adds the
ConstrainImageProcessor itself.

I think that would do it! That'd be nice because it would always work – not
just if the user's JavaScript allowed it – and by the same token you
wouldn't be uploading massive files in every case, because the javascript
option resizes them for you if that functionality is available.

That'd be a nice addition.

On Tue, Nov 24, 2015 at 4:20 AM, Karl Dilkington notifications@github.com
wrote:

[image: 👍]

I tested this and it worked well.

Often users aren't aware of or consider image size. This solution would
save bandwidth, speed up uploads, prevent users from wasting server
storage, and make for faster sites.

I really like the idea of some type of dashboard configuration page to
turn it on and off, set image quality, and specify maximum width and height.

—
Reply to this email directly or view it on GitHub
#3147 (comment)
.

[Mesuva]

Is there a preferred way to get some values that would be stored in the config system into the arguments of the fileupload script?

Would it be a case of doing something like outputting the values a data attributes on something like the file input tag and then adjusting the javascript to look for that on the page? (with some sort of sensible fallback).

Or is a case of outputting a little piece of javascript with these variables ready to be used?

Or is there a better way of doing it?

[jeffharris23]

+1

This sounds awesome!

[aembler]

@Mesuva good question. There currently isn't a way to access config values from directly within JavaScript. I wonder if passing them as options into the ConcreteFileManager javascript plugin might be the way to go here. We could pass them through and if they're not defined then we just don't enable that functionality within the plugin.

[Mesuva]

I'll try to look at this in the next few days. I reckon I'll start with outputting the config values as data attributes somewhere on the upload form/html (perhaps on the <input type="file"...) and then get the script to try to find those.

I might just start with the javascript version of the resizing, and the corresponding dashboard page. Your point 4 I think would be best tackled as a second bit of development.

[aembler]

Yeah, honestly if you got everything else working it'd be simple for us to add point 4.

[Mesuva]

Here's a fully working version, with a new dashboard config page.
https://github.com/Mesuva/concrete5-1/tree/client-side-image-resize

It's working well from my initial tests, but I've not done a pull request yet. Comments welcome before I do.

I've set it so it's pretty foolproof in terms of the settings - if you turn it on it defaults to some sensible settings, so you only need to type in values if you want them different.

There are a few spots where images can be uploaded in the system. The replace dialog I couldn't include as that doesn't appear to use the jquery file upload at this point.

[Mesuva]

Pull request #3193

[gavthompson]

This would be a killer feature.

[aembler]

This has been integrated into the core and will be in the next release.