<h2 dir="auto"><g-emoji class="g-emoji" alias="memo" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f4dd.png">📝</g-emoji> Provide a description of the new feature</h2>
<p dir="auto">Basically the title. This would make it feel more consisten and avoid some confusion.</p>
<p dir="auto">If you'd like to see this feature implemented, add a <g-emoji class="g-emoji" alias="+1" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f44d.png">👍</g-emoji> reaction to this post.</p>
<h1 dir="auto">Summary of the new feature/enhancement</h1>
<p dir="auto">Implement the ability to allow the user to request that Resize create multiple image sizes in one operation rather than doing them selectively.</p>
Although there are probably several ways this feature could be used, the main purpose would be to allow a user to quickly and efficiently create various images to be used in a website that requires images of different sizes, mainly for products to be sold over the internet.  The user would start by gathering or creating the necessary images (front, back, ...) views of one or more "products".  This could be done by taking photos of the product or copying one (or more) from one or more vendor (manufacturer) site(s).  The original images would be stored in a subfolder of the main folder (ie. /Images/Original).  
<p dir="auto">The necessary enhancements to the Resize application and use explanations are as follows:<br>
0. Allow the user to identify the location of the original image files which would have been created as part of the original image gathering or creation process.</p>
<ol dir="auto">
<li>
<p dir="auto">Allow the user to select one or more of the original images from which a master image would be created and stored in an appropriately name subfolder below the high-level folder (/Images/Masters)</p>
</li>
<li>
<p dir="auto">Support of a new image category called the Master image with the ability to define its' sizes.<br>
This would be the output image of the resizing of the original image either larger or smaller<br>
resulting in a common size of the master image regardless of the size of the original image.<br>
The aspect ratio of the original image shall be maintained.  The master image should be large<br>
then the subordinate images.</p>
</li>
<li>
<p dir="auto">Resize the selected original images to the Master image size(s) and save them in the Master image folder.</p>
</li>
<li>
<p dir="auto">Similar to the existing method define the sizes for all to be resized image category (Small,<br>
Medium,...)</p>
</li>
<li>
<p dir="auto">Provide a checkbox for each resizable image such that one or more can be selected.  Resize the Master image for each size selected and save them to a previously selected folder (not defined here but can be defined in an appropriate place).  The converted image would have its'<br>
sized fixed tot the file name as is done now.  All resized images could be stored in the same output folder</p>
</li>
</ol>
<h1 dir="auto">Proposed technical implementation details (optional)</h1>

<p dir="auto">The intent here is to allow the user to create a standard-sized master image(s) from the original image(s) of various sizes and once done to create various other sizes (Small, Medium, ...) from the Master image which could be done in bulk once the correct image sizes for each category were determined. Although the above use case appears that the process is sequential the implementation shall allow the process to be done on a step by step basis as long as the definitions exist and the appropriate files are available.  Once the created files are ported to the target website they can be deleted from the working directory if desired as they can easily be recreated from the master image and even resized as required.</p>
<p dir="auto">Because there are many possibilities on how this can work a more complete requirements definition would be necessary for the implementation.  My belief is that before that can be better defined an interest in undertaking this effort is desired by the developer(s).  While this request was written as am enhancement to the resize it is entirely possible that a better implementation (if undertaken)  would be a completely separate module (Bulk Resize).</p>