§ ¶Video filter: resize
It isn't fair for me just to pick on other peoples' UIs, so time for an example from my own program.
Rolling a configuration dialog by hand isn't a lot of fun. You need to code at least two paths for data, one going into the dialog controls, and another going out; if the settings are persistent, you need another two paths to and from the Registry or some other backing store. Also, typically not all controls are pertinent for all configurations, so additional logic is needed to track changes and enable or disable controls as needed. Finally, the settings in the dialog need to be validated against acceptable bounds for each datum. This adds up to a lot of code, which makes it annoying to add features to the existing UI, and I've been working on ways to reduce this. One such way is to implement "data exchange" routines that can either read or write data to a particular store; this then reduces the number of places where you have to keep track of variables, UI control IDs, etc. for each dialog.
The "resize" video filter has been in need of an overhaul for a while, so I decided to add some needed features and use it as a test bed for some of the new methods. Unfortunately, wrapping methods alone isn't enough to cure some of the usability problems that cropped up.
The main problem with the current resize filter is that it only allows absolute sizes. This is fine when you're targeting a particular size, but not when you want to preserve or target a particular aspect ratio, or want a certain multiple of the current size. After spending a while hashing out all the little issues with adding features to resize, this is what I came up with:
There are a few things missing yet in the dialog implementation, such as the % buttons not being hooked up yet and accelerators being absent, and it hasn't been appropriately squished down in size yet, but it's mostly functional.
Now, there is one important problem with adding features to resize that should be noted here: compatibility with existing scripts has to be preserved. This requirement arises since VirtualDub scripts request filters by name and I try to write the internal filters in the same way as external ones, i.e. little or no special-case support from the engine. That means the new resize filter still has to accept an image size, image filter mode, interlacing checkbox, frame size, and fill color, in order to avoid breaking existing job queues and scripts. If this were an onerous issue I'd just fork the resize filter, as the main resampling engine has already been refactored out, but I don't think it'll be a big deal to avoid this.
The problems addressed by the new design are:
- You can now specify a new size as relative from the source size.
- The new size can also be computed from either the source aspect ratio, or a specified aspect ratio. In fact, matching aspect ratio is the default.
- A different default can be saved.
- The frame size too can be computed by ratio as well as absolute size.
- The frame size can also be used to crop instead of just letterboxing, avoiding the need for a second filter instance to crop and calculating centered parameters for that crop.
There are a couple more features missing that I want to get in, primarily an option to round the frame size up to multiples of 4/8/16, but that shouldn't be too hard. The trickiest part is trying to cram them in without making the dialog too big or too cluttered.
Unfortunately, when I implemented the dialog and actually tried using it, I found the following problems, mostly related to the filter preview window:
- VirtualDub filters can be configured without an input source video. This allows a filter chain to be set up beforehand for multiple videos without having to be recreated for each. Unfortunately, this causes problems for the relative % buttons. If the image width is set to 640 pixels and Width% is suddenly checked, you probably don't want the filter preview new relative width to be 640%. And having two different absolute and relative size fields that correspond to the same pair of edit boxes feels like a baaaaad idea.
- Similarly, when Width% is unchecked, you don't want the new width to be 100 pixels. But what to set it to, if no source frame size is available?
- To avoid really bad cases, the dialog updates on KILLFOCUS notifications for the text edit windows instead of CHANGE. This works decently well for the width/height widgets... except if you happen to type 640240 and select another control before you've fixed the mistake. Then VirtualDub tries to allocate a 640,240 x 240 bitmap....
- The default for the aspect ratio is 4:3, and another common desired ratio is 16:9. Well, if you type 16 and then hit TAB, the preview window now updates with a ratio of 16:3, which tends to cause widths in excess of 3,000 pixels.
- Some fields can be temporarily invalid. Setting the aspect ratio denominator to zero is invalid, except if you're going toward a radio button to disable it. The current video resize dialog validates width/height on KILLFOCUS (yuck).
- The current resize filter requires the frame size to be at least as large as the image size. This can't be validated in the dialog anymore, because it's possible to make the image size relative and then change the source size outside of the dialog.
- Radio buttons in Windows have to be contiguous in order to find each other for auto-check functionality. This meant I couldn't place the letterbox/crop frame size edit boxes in between the frame mode options, breaking my normal book-order rule for tab order.
- The first set of aspect ratio options determines whether height is specified or computed, so it enables and disables the "new height" field. Unfortunately, this field is above the aspect ratio options, which feels counterintuitive -- I normally prefer all enabling to go downward, with the presumption that options are set from the top down. I don't think inverting this would be any better; size feels best at the top.
- Aspect ratio and size options are somewhat duplicated between the image size (top half) and the frame size (bottom half). I couldn't see a way to combine them, though, given conversions between 4:3, 16:9, and 16:10, though, and splitting them apart into separate filters is even worse (compatibility problems with the current resize filter, and unnecessary slowdowns for the crop case).
At this point it's tempting to crawl back into bed and just stick my head under a pillow. It's nice and warm there.
Here's what I'm thinking so far for solutions:
- Modify the core video filter engine so that FilterActivation::src contains valid width/size if known when configureProc is called on the filter. This may actually already be mostly true, but it's not guaranteed by the API, and the values are probably random if no video is loaded. Once this is done, the resize filter can have more sensible behavior with regard to toggling the Width% and Height% options.
- Modify the video preview window to refuse to auto-preview if the frame size output from the current filter exceeds a certain size, something like max(screen size, 1920x1080). This would prevent any filter from blowing up in the preview on typing accidents. An option would be added to Preferences to disable this behavior, and the error that would result otherwise would note the presence of this option.
- Let random garbage be entered in any of the fields. Validate only on OK, when (re)initializing the filter, and when saving settings.
- The frame size can be smaller than the image size. If it happens, it's no longer an error and a centered crop occurs instead.
I think these will help address the worst usability problems, although I won't know for sure until implementation.
I'm also looking at simplifying the filter modes list. In particular, the idea would be to eliminate the Bilinear and Bicubic options and alias them to the Precise Bilinear and Precise Bicubic (A=-0.75) settings for compatibility. The reasoning is that purposely aliasing a multi-tap filter probably isn't a common need, and for interpolation cases the settings are equivalent anyway. Eliminating the "precise" tag might cause confusion with existing how-tos that people have written, though.
Note that one feature I haven't considered here is presets, besides the one you get via "save as default." The reason I haven't considered presets is that those could probably be done in the core for all filters, not just resize, so it makes more sense to implement it there.
I think what you're missing is an "Apply" button. You shouldn't apply settings automatically, as you might end up doing what you mentioned, creating valid yet system-halting parameters.
An apply button is logical, used in quite a few similar situations so the user should be familiar with the concept and you can route all the field-validity tests into one location.
Blight - 27 03 06 - 06:37
Have you looked at the "VDMod_Resize" filter in VirtualDubMod? I especially like the option to round to multiples of 16. Personally, I prefer VDMod's dialog to your working model above.
Simon E. - 27 03 06 - 14:44
1. For completeness "Compute width from ratio:"
2. Instead of check boxes for % Width, % Height why not split the fields in 2 and have both Width and %Width locked together, i.e. Update 1 and the other follows.
IanB - 27 03 06 - 20:21
Integrating the cropping (before applying the filter) in the resize filter is a nice idea (no need for null_transform before resize).
Afa you currently redesign the dialog:
I mostly use the resize filter to letterbox to a specific size (after cropping some lines).
Therefore it would be useful to have a fast setting in the "Size options" to use the source size (while disabling the rest of the "size options").
Another nice-to-have would be, to be able to save defaults for the destination letterbox size as well as for other width/heigth settings in the dialog.
pjs - 28 03 06 - 03:08
I like to include warning messages on my dialogs that become visible when the text entered in a field is invalid, but don't prevent you from typing in said text (e.g. the aforementioned zero in a denominator), and then have actual error dialogs on Apply or OK. Windows does something like this with the warning bubbles while changing a filename in explorer, if an invalid character is typed, except that it prevents you from entering the character, also (Personally, I hate those bubbles.. they accomplish the same kind of goal but I find them too in-your-face. ... of course, with my way I have extra blank space on a dialog that holds the error message... you just can't win sometimes.)
Eric - 28 03 06 - 13:37
One way to deal with absolute/% is to have the values computed automatically from the existing value i.e. if the image width is 640, you enter 320 for the desired width, then hit %, the entry changes to 50. If they've entered an absolute value though, you should remember it until they change the % value - it would be disconcerting to enter 321, check and uncheck %, and end up with 320 ...
I'd also only have a single % checkbox - I'd be hard-pressed to think of a case where I wanted to specify a % width and absolute height (or vice versa).
Aspect ratios - have you considered using an editable popup menu/combo box? Pre-populate it with the most common values (e.g. 4:3, 16:9) but allow the user to specify other values. I think it's possible to have additional controls in the edit box, so if you *really* wanted you could have two numeric fields separated by a colon ...
As noted, the simplest way to handle things is to have an "Apply" button. People are used to them, and if one is present they will not expect any changes to take hold until they hit it. But if you do go for an "Apply" button, be careful not to fall into the trap that so many other Windows programs do (including MS Office programs ...). If the user clicks "Cancel", *all* changes to the dialog need to be cancelled, including those that have already been applied.
Tim - 28 03 06 - 15:18
I say if it is simply a matter of creating dialog with more user variables, then cram the living heck out of the whole box. Heaven knows ms-win is littered with it!
Otherwise seems to me what is missing is a clear distinction between items on the user-end side. For instance, why not categorize possible variables according to essential (ratio-pixel-percentage, that whole cubit setting, ect.) and make it a policy of replacing the idea of snazzy UI's (if anything, skinning should be, similarly, an option for the -user- to have fun with) with an options dialog. (Like a 'Options' button for the whole UI box in question.) If that is the issue here, at least.
This is more work. But here's some points in its favour:
- logically, new additions will just add to the Options
- without concentrating on UI aesthetics, the program remains static apart from Options
- Options is not just a matter of technique, but also carries something even bigger - a ever growing knowledge base (help function, how to kind of stuff)
- as you develop around Options, regular users follow suit, which expands the discussion of new ideas and implementation
- the added feature of userA being able to fly through and, say, resize quickly while userB can get into detail, like the divide by factor 4/8/16 (which should be Optional and not mandatory, as I found with Mpeg2)
Maybe even think of it as mandatory variables and such versus optional? Anyways, with the whole UI thang, optioning with all that Visual crap seems oxymoronic. It is like a filter for the Filters, if you know what I am writing. Personally, I think Visual is mostly an excuse to attract developers, but is ultimately endangered (skinning is clearly the exception - which if not made simple to design and use with the upgrades, forget it - very mutually appealing).
£ - 02 04 06 - 15:29
Take a look at Photoshop's resize interface. It's smart and effective and I like it. So you could (per example) ask the user to select the type of data in the field (through a drop-down list), be it pixel or percent. Or even ratio.
Mind you there is no single perfect solution but keeping it small and concise is always prefered (i.e.: no matter how much engineering goes into an interface, someome will mess it up, so just concentrate on making as hard to misunderstand as possible).
Louis Horvath - 03 04 06 - 12:42
FWIW I'd suggest perhaps using (at the top?) a "Maintain Aspect" checkbox or alternatively radio buttons for Maintain. Calculate, disabled/disregard. Use those to activate/disable portions of dialog. Might make it easier all the way around, as used in other apps., & IMHO quicker/easier then drop-downs.
Mike - 10 04 06 - 13:08
A little suggestion on the "Cropping" interface: a nice status-bar with resulting WidthXHeight (Aspect ratio) would be geat. I always have to switch to Windows' calculator to find out the right 4:3 width for a specific height (height * 1.(3) ), then substract it from the current width, then divide by 2 to find out what to put in VirtualDub's crop interface...
Chitza - 01 06 06 - 16:59
Hi. Great work with the VD!
A suggestion: an option to JUST letterbox the frame, without resizing it. If I have a 624x352 movie, I should be able to letterbox it, mantaining the width and just inputing the final ratio. The filter should, then, apply the letterbox to 624x468 for a 3/4 ratio. Thanks!
Daniel Trezub - 13 04 07 - 09:38
When you comput height for a source image of 720x576 with a PAR of 4:3, the image is extended to 768x576 to look 'correct' on a square pixel device. Where do the extra 48 pixels come from? How are the 720 pixels 'spread across' the 768?
Lester - 04 12 08 - 11:48
First of all, the dialog only accepts frame aspect ratio, not pixel aspect ratio. You can use the resize filter to adjust for changes in PAR as well as it's the same resampling operation either way, but the dialog won't really help you do that as it works in frame aspect.
The way the current resize filter works is that it resamples the image to the size specified in the top half and then converts it to the frame size in the bottom half, if they differ. If you choose 4:3 in the size portion, then you'll get the image stretched to 768x576 with the resampling filter you specify. If you choose 4:3 in the framing options, then you'll get the 720x576 image just copied over with black bars on the side. You can also mix the two to get a blend of both resampling and letterboxing or cropping.
As for the resampling itself, it's the same bog-standard point sampling, bilinear, or bicubic filter kernels you'd find anywhere else. The continuous filter kernel is offset by the desired source offset, sampled according to the positions of the source pixels it overlaps, and then the source pixels are weighted and blended according to the kernel.
Phaeron - 05 12 08 - 04:15
I use resize to display HD, 1920 x 1080 at 691 x 389, but want to output edited file at original size. How do I do that?
dan kainen - 23 01 17 - 11:10