Closed crutkas closed 11 months ago
My inspiration was always a multi-page task dialog. I'd mock up a UI using the TaskDialogIndirect function and copy the look into XAML. I hope that API gets a Fluent refresh too...
Here's my attempt!
Maybe make it resemble the UWP Photos app? :)
If multiple images are selected, maybe present them in a grid? :)
Wow!!!!
Here's my attempt!
Hard to make it any better than this!
@zeealeid Looks stunning, love it <3!
@crutkas Can we use XAML Island for this feature as well? I'd be happy to start some XAML work to turn @zeealeid's concept into reality!
We should be able to do it without even an island with WinUI 3. In theory settings will be same way
If we do the work inside a 19h1 xaml island now, we could ship this at Build with winui3
I made a working XAML proto based on @zeealeid's awesome UX concept. I made some changes to the proposed gridview.
Maybe a listview could show some relevant information such as filenames and the ability to de-select images? Additionally, information such as the original dimensions (and the new ones?) could be shown as well.
Light theme:
UX alignment with PowerRenamer? It would be nice to have a common UX for these configuration/action windows within PowerToys. Since we're also working on bringing Fluent to the PowerRename powertoy (issue #1053), aligning the two might be useful?
XAML can be found in this repo. Happy to port the right stuff over once we have a working XAML Island project.
Where it says "Ignore the orientation of pictures" is this the equivalent of "Constraining Proportions", where width or height is set automatically to maintain the aspect ratio when entering a value?
Where it says "Ignore the orientation of pictures" is this the equivalent of "Constraining Proportions", where width or height is set automatically to maintain the aspect ratio when entering a value?
think that is the actual verbiage there now. @bricelam would be able to verify
Not exactly. You can’t “constrain” the values in the UI since every image may be a different aspect ratio. Instead it has Fill, Fit, and Stretch to maintain the original ratio, crop, or stretch.
Ignore orientations is for when you have several photos where some are landscape and some are portrait. If it’s checked and you specify 1024x768, the portrait ones will be 768x1024. If it’s not checked, they’ll be 576x768.
It'd be great as part of this improved UX to have an option/mode for interactive crop. I'm going through a bunch of photos from my camera now to optimize them for a digital picture frame. This means adjusting the aspect ratio of every photo and re-framing each image.
If I could set the resolution/settings for my final output, but then just speed through each image and move and resize a crop region with the fixed aspect ratio around to get the frame I want for that image and click next, that'd be great!
There's an Image Cropper component in the Windows Community Toolkit which could handle the UX for the crop.
@hawkerm IMO, this is starting to overlap the Photos app's capabilities. Image Resizer is a batch process for multiple selected images - unless you are proposing a batch crop operation - it may be better to keep the suggestions for batch processes, rather than something designed for single image selections.
@mdtauk this is still about batch processing. I want all the photos I've selected to have an aspect ration of 16:9
or in my case a specific size of 1280x800
. However, if the image isn't already in the right aspect ratio and thus can't be scaled without some crop (or just an option to review all anyway),
I want to quickly just be able to 1) choose that crop - be it a segment slid out of the original photo or extracting a partial inner part of the photo, then 2) click next and have it automatically apply and scale and move to the next.
With Photos, I'd still have to 1) navigate to each photo, 2) hit the crop button, 3) select the aspect ratio (and I don't even get to see/choose what the actual pixel resolution of the output I'm making is there), and then 4) click the save button...
I agree with @hawkerm on this one. Having some more features (like cropping) would be super nice.
The other day I wanted to crop desktop screenshots, so I could remove the taskbar. Had to do this manually, which was cumbersome.
I also want to propose a 'custom' variant: just a slider so I can make pictures 25% smaller. This is handy in situations where large images (such as my 4k resolution screenshots) are too big to share. Having a quick slider/UI to decrease the width manually without define exact pixel sizes (while keeping the aspect ratio) would be great.
@niels9001 In that case, the cropping interface from the toolkit would need to be reconsidered. You can't guarantee every image being cropped will be of the same size and aspect ratio.
The values for each edge should probably be referenced as a minus value.
Pixel values or percentages make the most sense.
Would there be a visualisation of what the new image sizes will be for the list of images about to be processed?
If a crop and resize operation is taking place at the same time, does the resized size chosen, affect the image before or after the crop?
Yeah, it would require a lot of thinking. Not sure if this is in scope at all.
If we move towards WinUI with the ImageResizer UI, let's make sure we design a UI that can be extended later on with additional features.
It'd be great as part of this improved UX to have an option/mode for interactive crop. I'm going through a bunch of photos from my camera now to optimize them for a digital picture frame. This means adjusting the aspect ratio of every photo and re-framing each image.
If I could set the resolution/settings for my final output, but then just speed through each image and move and resize a crop region with the fixed aspect ratio around to get the frame I want for that image and click next, that'd be great!
There's an Image Cropper component in the Windows Community Toolkit which could handle the UX for the crop.
Good idea but out of scope here for this issue . Please create a new issue.
Here's an updated mock-up for ImageResizer based on my previous concept.
Would be nice if we can somehow predict what the new file size would be and preview that. This also takes into account that whatever changes you make (on the selected template) can be saved as a preset by ticking the CheckBox.
I'm in love with it. This looks great 👌
I've been thinking about this for a bit. Should the list be on the left or right? I feel like the UX is flipped. Is there another spot we can point to for reference?
The main work here is left based, where most spots in the UX it is right based in Windows.
I've been thinking about this for a bit. Should the list be on the left or right? I feel like the UX is flipped. Is there another spot we can point to for reference?
The main work here is left based, where most spots in the UX it is right based in Windows.
I think that makes sense. You mean something like the earlier concepts posted, right?
We can easily swap them around. I'm looking for a similiar example - only thing I can come up with are the properties panels in e.g. Blend, Visual Studio. In a minimized state, we can hide the entire preview pane and only show the config bar.
imo the options on the right would be better because most of the photo-editing apps (like Lightroom, Photos app etc) have the options on the right so, placing options on the right would make it more in-line with the photo-editor in the Photos app. I think that would make the user feel right at home :)
The photos app has a right-hand sidebar with it's photo editing options.
Also should the file list view adapt it's items view? If there are only a few photos, could they appear as thumbnails in a grid - rather than a details view?
In @niels9001's mockup, the list view shows some info like the resolution and file sizes. That is quite helpful imo. I think if there's a single image selected then there should be a big preview of the image with info below it. :)
@mdtauk @zeealeid Thanks for the feedback!
I think we could support different grid/listview templates. As @zeealeid pointed out the idea behind the listview is to mostly show details (like new dimensions).
In a minimized mode, we could even collapse the entire Preview pane, so only the properties panel stays.
Other feedback, band the data grid.
The area on the left could mimic File Explorer, with its multiple views, DataGrid headers for a details view, but the information below the thumbnail for a grid view, if the space and amount of images allows.
The preview text is not needed essentially. You could show the size of the images in normal text style until you alter the values in the sidebar - then display the updated values in bold accent coloured text. This would signify what is changing.
Maybe also have a "reset" button on the right, to put everything back to default, so you can toy around with the settings before committing the batch action.
Did some tweaks based your recommendations - see the latest version in light/dark above.
I think preview pane could support some other views, but maybe not crucial at start. Having a preview of the new width / height would come in handy I imagine. I left out the filesizes for now, since that requires some additional thinking on how to do it.
WinUI 2.4 source code here: https://github.com/niels9001/ImageResizerUX
Hopefully we can re-use most of this XAML once we move to WinUI 3 :).
Oehw, I'm excited to see when it gets "published" :) One idea for the view: Maybe a few buttons on the top to select "small icons", "large icons", "details"? Or try to use the same thing Explorer has, if possible. Some headers above the Detail view would be nice too, like "Filename | Original size | New size". Also: #tracker label for this issue.
If the text on the button says Resize, but the action is "Resize and close", then that's not correct. Would it be better to update the text to match the action, or to change the action to match the text? My vote is for Rename only. That makes it possible to do several different resizing actions quickly after each other - for those who need it. That does mean some kind of visual confirmation would be necessary, because the user needs to see that the action is done, and we can't rely on the File Explorer window being in field of view. Closing can be done with the [X] in the title bar, Esc or maybe an extra Close button. (Same principle for Power Rename and FZ Editor)
@bricelam @crutkas @niels9001 what is the current plan for the new UI? I'm asking because we are currently working on the Image Resizer accessibility bugs and since there are a few, we would like to make sure we are not doing this work for nothing ;)
These are the Priority-1 (there are no Priodity-0) https://github.com/microsoft/PowerToys/issues?q=is%3Aopen+is%3Aissue+label%3A%22Product-Image+Resizer%22+label%3AArea-Accessibility+label%3APriority-1
@enricogior, we should discuss options. Depending on the amount of work, we can have the discussion with the team
Did some tweaks based your recommendations - see the latest version in light/dark above.
I think preview pane could support some other views, but maybe not crucial at start. Having a preview of the new width / height would come in handy I imagine. I left out the filesizes for now, since that requires some additional thinking on how to do it.
WinUI 2.4 source code here: https://github.com/niels9001/ImageResizerUX
Hopefully we can re-use most of this XAML once we move to WinUI 3 :).
Like the mock-up.
@niels9001 Issue needs tag-fix: in-progress
@niels9001 Suggestion: use MDL2 E799
"AspectRatio" for the [fil/fill/stretch] button.
Also you can use E74E
"Save" and EA35
"Save copy" (instead of "BackToWindow")
Idea: what about including the file format settings in the right pane? Could be handy when you want to use a different, custom format, just for one single time.
@niels9001 Have you found time to look at my input in your fork? Just curious.
@niels9001 Have you found time to look at my input in your fork? Just curious.
This is currently not actively worked on due to WinUI limitations - I'll make sure to look at any outstanding PRs if we continue any work - seems like good suggestions to enhance. Might be useful to come up with a spec beforehand as well, to determine what additional (UX) features we'd like to enable.
Here's my latest take on Image Resizer vNext. Mostly a UI refresh adopting W11 Fluent, while adding a new feature: the ability to easily tweak a preset and save it within the editor itself.
WinUi 2.6 (UWP) source code here: https://github.com/niels9001/imageresizerux
@Cleancodedeveloper Moving the WinUI discussing to this topic :).
1.0.1 seems ro solve quite some bugs, with 1.0.2 incoming according toTwitter. Also 1.1 should launch before July (based on the announcements made in the Community call and roadmap) so it might be nice to try to see if it holds up?
it might be nice to try to see if it holds up?
Okay, I'm in. Are the mockup up-to-date? There is one open PR in your repo (https://github.com/niels9001/imageresizerux).
I really like the simplicity of your latest mock up (https://github.com/microsoft/PowerToys/issues/1053#issuecomment-929929516) and would vote to implement it like this.
it might be nice to try to see if it holds up?
Okay, I'm in. Are the mockup up-to-date? There is one open PR in your repo (https://github.com/niels9001/imageresizerux).
I really like the simplicity of your latest mock up (https://github.com/microsoft/PowerToys/issues/1053#issuecomment-929929516) and would vote to implement it like this.
Yup, that repo contains the latest code!
My idea was to add a ImageResizer.Logic and a ImageResizer.WinUI3 project. The logic project will contain the everything from the previous ImageresizerUI project except the UI/XAML stuff. Your mockups would be added to the WinUI3 project.
Not as easy as I thought it would be.
ImageResizer uses a lot of stuff from System.Windows.Media.Imaging (PresentationCore.dll)
There are a lot of changes regarding Encoders. We had separate encoders classes before
new BmpBitmapEncoder();
new GifBitmapEncoder();
new JpegBitmapEncoder();
new PngBitmapEncoder();
new TiffBitmapEncoder();
new WmpBitmapEncoder();
But now it is only BitmapEncoder which seems to be able to encode everything but the API is entirely different.
Other classes I badly miss are
TransformedBitmap();
BitmapMetadata();
BitmapSource();
CroppedBitmap();
My desperate attempt can be found here: https://github.com/CleanCodeDeveloper/PowerToys/tree/imageresizer-winui3-migration
+1 Switching from WPF to Windows.Graphics.Imaging
is a big chunk of work. Especially given its async
-only nature.
I also suspect we can get a significant perf improvement by using a custom SynchronizationContext since resizing is about 50% CPU and 50% I/O.
Here's my latest take on Image Resizer vNext. Mostly a UI refresh adopting W11 Fluent, while adding a new feature: the ability to easily tweak a preset and save it within the editor itself.
WinUi 2.6 (UWP) source code here: https://github.com/niels9001/imageresizerux
As discussed, we might be able to pull this off by moving away from the deprecated ModernWPF
to WpfUI
. Will investigate.
Not WinUi3?
Not WinUi3?
That would require a rewrite - which for this app, is probably not worth it😣. I was able to come very close to the UI proposal in the OT with WpfUI.. which is mostly style changes only. If all things check out that should give us a way to modernize the look and feel of other WPF utilities (like ColorPicker and FancyZones) and bring them inline with the W11 look and feel.
I had a look into migrating Image Resizer to WinUi 3 but as niels said, this would be a rewrite and I did not had the time to do this so i gave up.
This was done in: https://github.com/microsoft/PowerToys/pull/26858
PowerToys should do its best to look like a system level integration. Image Resize is a great example of where we can be but needs a little bit more polish.
Latest Fluent Design concept by @niels9001
WinUi 2.6 (UWP) source code here: https://github.com/niels9001/imageresizerux