Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
Donate
Contact info
Forum
 
Other projects
   Altirra

Search

Archives

01 Dec - 31 Dec 2013
01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004

Stuff

Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ 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.

Comments

Comments posted:


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.

VDMod_Resize
http://prdownloads.sourceforge.net/virtu..

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


Er...

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

Comment form


Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
Name:  
Remember personal info?

Email (Optional):
Your email address is only revealed to the blog owner and is not shown to the public.
URL (Optional):
Comment: /

An authentication dialog may appear when you click Post Comment. Simply type in "post" as the user and "now" as the password. I have had to do this to stop automated comment spam.



Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.