Current version

v1.10.4 (stable)


Main page
Archived news
Plugin SDK
Knowledge base
Contact info
Other projects


Blog Archive

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:

[Prototype resize filter config dialog]

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:

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:

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:

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.


This blog was originally open for comments when this entry was first posted, but was later closed and then removed due to spam and after a migration away from the original blog software. Unfortunately, it would have been a lot of work to reformat the comments to republish them. The author thanks everyone who posted comments and added to the discussion.