Make image/video resizing simpler in the WebUI

[NiteRide]

Problem

It can be tricky to resize images and videos when required as manually calculating and setting height and width can be confusing to figure out the maths due to the need for remembering variables like sensor size, any cropping, and borders that may have been applied.

It would be useful to make it easier to specify resizing of an image or video (uploaded image, timelapse, mini-timelapse, etc).

Proposed idea/solution

• Where there are two fixed dimensional values, let user leave one as "0" and Allsky will then auto-scale based on the single input.
  • Eg if user enters a width of "1000" with "0" for height, then Allsky should auto-scale the height to match that ratio when processing an image or video. (Similarly if user enters only height and "0" for resize width.)
• This same behaviour should apply across the Allsky settings to uploaded image, timelapse, mini-timelapse, anyplace resizing can be specified
• It would also be nice to allow a user to simply specify a scaling factor (such as "50%") instead of specific dimensions
  • eg a user types in a number with a "%" symbol eg 50% vs 50 then Allsky would just calculate the new image size at that ratio (rounding to even numbers, etc)
• this would require some careful thinking about rewriting the on-screen descriptive labels and also reviewing the documentation to make it intuitive

Advantages:

• Keeps current settings in tact for existing users which improves upgrade experience and reduces change
• provides real usability enhancement for scaling as it can be set and forget without too much thinking about what size the image actually is
• Retains more of existing logics and look and feel

[EricClaeys]

Images with odd numbers for the width or height can cause problems so I think it's reasonable to only allow even pixel numbers to be input.

Allsky is currently inconsistent with this:

• Image Resize Width/Height and Resize Uploaded Images Width/Height say "Must be an even number" on the Allsky Settings page, but that's not enforced and should be.
• Crop values must be even numbers and it's enforced. In theory odd numbers would work as long as both sides numbers and/or top and bottom numbers were odd, resulting in an even width or height. But that's too difficult to easily and concisely explain.
• Timelapse Width/Height must be even numbers and it's enforced. Ditto for mini-timelapse.

For percents input, I don't see a technical problem with allowing odd percents or fractions (but I suggest not allowing fractions - it makes the coding more complex).

[NiteRide]

I have done a bunch of work on a shared function to handle resizing so that it can be reused across the app.
This will handle various inputs for specifying resizing requirements in a single field and allow a user to specify in a manner that relates best for them on what they know about their images.

meeting requirements of above discussions, it will allow input by defining a single dimension, as a percent, or fixed scaling.
also, it should be transparent with minimal change for existing users as prior saved values can still be used.

Also, I am choosing to round up if the user enters an odd number...

resize parameter	interpreted as
'50%'	percent scale (both sides)
'50'	plain number treated as percent to scale
'720H'	target height (width auto scaled)
'1000W'	target width (height auto scaled)
'1280x720'	fixed width x height (WxH)
'0', blank	no resizing

I'll submit a PR for this in the next couple days and plan to use the logic with some of the module work I am doing.

[EricClaeys]

@NiteRide, thanks for doing this.
May I suggest that 50 with no unit behind it, be an error? The number 50 may be obvious it should be a percent, but how about 720 with no unit? A percent or a width?
I vote that exactly one %, H (or h), W (or w), or x (or X) must be present. Spaces anywhere in the field are ignored (except between numerical digits) so 50% is equal to 50 % , but 5 0% is an error.

[NiteRide]

Thanks @EricClaeys -
I missed you comment earlier but that works for me. I submitted a PR for a function that does we need (I think).