A powerfull image upload field for all modules

[Mich-adg]

Hi,
i have a dream... that before 2019 ends, a new upload field with client-side resizing (and cropping !) will see the light of day Ready to pay for that because it's not possible to ask clients to resize/crop their big images with "Paint" or something else before uploading in cmsms.
With all engineers working on cmsms, it must be possible to achieve this!!

[calguy1000]

and I disagree.

Content editors are not aware of issues like photo rotation, compression and optimal size. So they probably should not be making those decisions. It is not their business to know that stuff... it is yours as the developer.

That's why there are modules like CGSmartImage to process those images after the user has uploaded them, and when they are displayed.

Another option would be to have a batch job that goes through all image files that were recently uploaded and resize them to some specification, rotate them... whatever. But I still don't think that such a feature is a core feature.

[Rolf]

I have build a module "FileMgr" that is a wrapper around the responsivefilemanager.com which also is included in the TinyMCE module.
It is a very powerfull plugin, but I am not sure in which direction my part of the development goes... The initial idea was just to maintain the files in the assets folder, but who knows...

[Mich-adg]

Calguy, it seems that my message was not clear.

What i want to do, is setting an "image" field (say 'Article' or 'Lise' custom field or reusable for all mods) wich can resize to a max width size (that i set for my editors, say 1200 pixels for example). So the editor select his image on his desktop or mobile, this image is resized to 1200 pixels (client-side) and uploads.
Just that will be a great step! (i know in TinyMCE we can do it, but i need it on custom fields). The idea is: the editor edits his article/item in 1 shot (no need to prepare/resize his image separatly in any software or module).
But what would be the top, the same field like above but with a cropping function: the editor choose his file and then move a crop zone (that we can pre-define in the field definition, say 600x600 pix. for field "image1").
In practice, we could have many custom image fields ("image1", "image2"... with for each custom settings: for image1, max-width 600px, cropping zone 600x600px, for image2, max-width 1200px, cropping zone 800x400px...).
A revolution for my editors...!!!

[calguy1000]

You do know that all image selection stuff in the core uses the filepicker? or is moving that way. This is what people wanted, the ability to use a filepicker to use an existing image or to optionally upload a new one.

Which means images can be reused from a shared location. i.e: two or more different pages/fields may be choosing the same image and displaying it with different criteria. In some places you may want to display a 1920x1024 image and in others, a cropped image with maximum height of 300px These images may be used in CSS or in img tags, figure tags, srcsets, etc. So defining a 'cropping profile' at each and every location where users could possibly select an image and having the image resized on the client is not reasonable IMHO.

Therefore auto cropping using tools like CGSmartImage on the server is the best way to go IMHO.

The best idea I can currently think of is to have some kind of server-side post-processing function that would use a data-attribute or some other mechanism of tags and auto-crop the image and replace it with a cropped one. CGSmartImage has some limited functionality for that.

The problem with auto-cropping is that the server can't easily detect the focus subject of the image. i.e: if the face is on the left size of an image it may be cropped out in autocropping. That's where third party services that use artificial intelligence and other magic can be useful... arguably that is probably still a better solution than relying on the average secretary to be able to figure out how to manipulate an image on the client before uploading.

[Mich-adg]

Okay... i understand the point for the reusable image.
In some case, i propose a filepicker field + an image upload field: so the editor can select an existing image OR send a new one (without using the FileManager first).
But for me sending huge images (> 8 or 10 Megabytes coming from smartphones) is stupid, and asking editors to resize "manually" is not so easy and sounds like "old practices" today. That's why i was saying a simple max-width resize function on a field is very usefull (why sending 6000 pix image when we need only 2000 pix for example on the whole website?).
Actually, for news articles, i propose a field image and CGSmartImage renders a thumbnail + a "normal" size. But the problem of the size of the image still occurs, some people try to send huge images and get an error, and ask me to resize if they can't do it...!
About the cropping: automatic cropping is not the best solution, i prefere let an editor simply move a crop zone on the image and validate the cropping.

[calguy1000]

First. processing an image on the client side to only upload an image of say 600x600 requires extensive functionality.. including resizing, rotating, cropping and possibly color balancing etc. and has platform specific problems so is by no means 'simple'.

Next: The user uploading an image to display in a content page should not have to care that you only want to display it in a 300px box. They should just upload the image, and you as the developer decide how, when, if, and where to display it. It is the same problem as users uploading huge CSV, PDF, zip or EXE files or whatever... in order to be safe and appear properly they should be cleaned/filtered/trimmed/scanned on the server. We don't often do that, but we should.

If your concern is server storage for an image heavy site, then CGSmartImage can automatically resize large images on the server, and watermark them, independent of how, who, or when they were uploaded... so there is no need for a core feature for that.

If your concern is php's max_upload_size setting, The file picker uses ajax file uploading and has no size limit... so there is no issue with server limits. The PressRoom module in CMSMS 2.3 now uses the file picker exclusively, so no issues with server limits.

Users will always be able to upload crappy images, so to fix them The file manager has graphical tools for resizing, cropping and rotating images. They can even correct those images (with the proper permissions) AFTER the item has been uploaded.

So, the only remaining concerns in my eyes are automatic resizing for efficiency to the browser, and 'cropping'. Tools like CGSmartImage can get you 90% of the way there automatically on the server side. without the user having to know how to scale, color balance, rotate, and crop images. There will always be some images that don't crop well.. but at least by having the large version YOU can fix it in a couple of minutes from the Bahamas when the site owner calls after when they can't make it work.

[DIGI3]

I do see having a client-side maximum dimensions option being useful, just to save people bandwidth when uploading overly-large images, but I think this would need to be a third-party module as an optional filepicker alternative.

If someone made such a module, it wouldn't be unreasonable to have the core allow for the option of specifying which filepicker module is used per field in a module (if it doesn't already). Then you could use the core filepicker for a PDF field but the third-party one for images, for example. This idea has already been used in the past with JMFilePicker.

[Mich-adg]

Digi3, that's exactly how i imagine it!

[velden]

IIRC the Gallery module uses a client side resize library. Flash driven long time ago now JS.
It doesn't offer any user functionality like cropping etc, but just makes sure the uploaded image will have some maximized dimensions.

It allows for multiple uploads at once btw.