As someone who has almost every client uploaded 5,000px camera phone images straight from the phone, it would be great to be able to downsize them to something more sensible.
Whilst this can be done with an upload hook if you know what your doing, it would be greate to be able to do it via blue print settings on the upload options for fields and sections.
There is a plugin for this: https://github.com/medienbaecker/kirby-autoresize
@Oliver Sure, but the point is it would be nice if you didnt need the plugin and you could resize via blueprint.
@Hello: I agree with you that’s why I also upvoted your suggestion :-)
maybe also resize them directly in the browser before uploading them :)
As we’re already messing with the original image data, then it would be nice if we could also change the FILE FORMAT - e.g., resize and save as WebP (or AVIF), instead of the original.
@Roman Steiner While I get the benefits of already downscaling in the browser, adding an implementation that does this and supports multiple image formats seems like a bigger task (and maintaining that alongside oru backend file processing). So it would be probably more feasible to rely on server-side processing.
@Roman Steiner I would assume the most common use case of the images is to displayed somewhere. Which would define the maximum dimensions needed. I’d say an option that scales down 5000x5000px to e.g. 2500x2500 but leaves 400x5000px as is (instead scaling to 200x2500px) would be highly confusing for most people. What’s the use case where scaling down to 2500x2500 is ok, but 200x2500px woul dbe problematic?
Also we are talking about backend rescaling on upload now, so Kirby’s thumb engine will need the RAM anyway. When rescaling in the frontend it might indeed make more sense to reduce the strain on the server by limiting the maximum total file size.
Does the thumb engine wait for them to processed one by one with a batch upload or try to do as many as it can in parrallel? Can only see ram being a bigger issue if trying to do them in parrallel. I guess if you add in WebP conversion at the same time, this get intensive quite quickly.
I guess performance can be tuned if its in the core though. I know from testing my WebP plugin with the downsize hook also active - i uploaded about 10 images at once ranging from 2mb to 14mb file size each and the conversion / downsize didnt take a horrible amount of time with the PHP ram set to 512mb. Perhaps 10 - 15 seconds.
I used this in my plugin if its helpful https://github.com/rosell-dk/webp-convert
Yeah, that could indeed become an issue. It’s difficult to do queing in PHP without a central database or daemon, so I think the only option would be that each thread that receives an uploaded image rescales it instantly (= in parallel).
@Nico, any very tall or wide image that contains text.
Typical example could be web comics; typically intended to be viewed on a smartphone: width is limited to that of the screen (something like 400 ~ 500 px), height is given by the content and has no limit.
Resizing 5000x5000 to 2500x2500 is ok, because the image is seen anyway at about 400x400.
Resizing 400x5000 to 200x2500 would mean the image is then seen at half of the intended resolution, pixelating it or, worse, making the text unreadable.
But hey, it was just something to consider… or not.