mirror of
https://github.com/microsoft/PowerToys.git
synced 2026-04-03 09:46:54 +02:00
7e791f2815
## Summary of the Pull Request This PR fixes an Image Resizer issue where **Fill** mode operations were silently aborted when **Shrink Only** was enabled (the default) and scale was 1.0 on one dimension, resulting in files that were renamed according to the intended target size but which actually contained the original, unmodified image. This also fixes a latent bug regarding square images and the **Ignore Orientation** setting, and improves the readability of the core `Transform` method. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #43772 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments ### Fix **Shrink Only** logic preventing the correct cropping of images **Issue:** When using **Fill** mode, the scaling factor is calculated based on the larger dimension to ensure the image fills the target box. In scenarios where one dimension matches the target and the other overflows (e.g. shrinking a 100x100 pixel image to 50x100), the calculated scale factor is `1.0`. The previous `ShrinkOnly` logic included this: ```csharp if (_settings.ShrinkOnly && _settings.SelectedSize.Unit != ResizeUnit.Percent && (scaleX >= 1 || scaleY >= 1)) { return source; } ``` This correctly prevents `ShrinkOnly` operations from returning upscaled result images, but it also exits too early for cases where the user is cropping the image across one dimension only, leaving the other at scale 1. Effectively, the later cropping code is never run and instead of returning the cropped image, the original is returned. The _intended_ target dimensions are correct, which results in the filename parts not matching the resulting image size. **Fix:** The logic has been split between upscaling and cropping, so: 1. If the scale on either dimension is > `1.0`, return the source (explicitly preventing upscaling for **Shrink Only** mode). 2. If the scale is <= `1.0` then check if the original dimensions exceed the target dimensions. If a crop is required, proceed with it even if the scale is exactly `1.0`. ### Fix for square images triggering orientation swap **Issue:** The "Ignore Orientation" check in the original code used a compound boolean check: ```csharp (originalWidth < originalHeight != width < height) ``` This clever but less than readable statement detects orientation mismatches. The section also includes a logic issue. When the original image was square, `originalWidth < originalHeight` evaluated to `false`, treating it as Landscape. If the target dimensions were Portrait, the logic detected a mismatch and swapped the target dimensions incorrectly, which would crop the height instead of the width. 'Fortunately' this bug was masked by the first bug, as the crop code would never be reached anyway. **Fix:** The orientation detection routine was refactored to explicitly check for Landscape vs. Portrait states. Square images are now naturally excluded, as they have neither Landscape nor Portrait orientations. This now prevents the dimensions from being swapped. ### Refactoring/readability The main `Transform` method has been cleaned up: - Replaced widespread use of `var` with `double` and `int` for dimension and scale calculations. - Replaced the non-obvious XOR orientation check (`a < b != c < d`) with named booleans (`isInputLandscape`, `isTargetPortrait` etc.) to make the intent more self-documenting. - New and expanded comments throughout. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Three new unit tests have been added to `ResizeOperationTests.cs` to cover the **Fill** mode edge cases: 1. `TransformHonorsFillWithShrinkOnlyWhenCropRequired`: Verifies than an image requiring a crop but no scaling is processed correctly (tests that the original bug report is resolved). 2. `TransformHonorsFillWithShrinkOnlyWhenUpscaleAttempted`: Confirms that when `ShrinkOnly` is set, any upscaling operations are still blocked. 3. `TransformHonorsFillWithShrinkOnlyWhenNoChangeRequired`: Verifies that the system returns the source if neither scaling nor cropping is required. I also manually verified the bug fix with a test 4000 x 6000 pixel source file with 1920 x `Auto` **Fill** mode and **Shrink Only** settings, mirroring the original user's settings, and their source and target dimensions.