§ ¶Field order confusion in VirtualDub
Why are the "even field first" and "odd field first" labels in VirtualDub reversed?
Well, actually, they're not, depending on how you label scan lines.
The even field in VirtualDub corresponds to the field that has the upper set of scan lines, and the odd field is the one with the lower set. The reason is that internally VirtualDub numbers scan lines so that the top scan line is scan line 0. That means the even field consists of 0, 2, 4... and the odd field is 1, 3, 5..., meaning that the even field is positioned higher than the odd field. If you consider scan lines to be numbered starting from 1, then this would be backwards and thus confusing. When this issue was raised, I did some searching around and didn't see a clear consensus on scan line numbering, so the plan is to abandon even/odd terminology in UI and just use top/bottom instead across the board.
If you're confused about the field order of a clip, the best way to check it is to use bob deinterlacing to double it to field rate and then check if you get motion juddering. The mode that gives you the smooth output is the correct one. You can do this in VirtualDub via the "bob doubler" filter in 1.8.0+, or the "deinterlace" filter in 1.9.2+. Unfortunately, there are a few places where I've goofed the field order settings at times; the bob doubler had this backwards until 1.8.2, and I've just been informed that it's currently backwards in the new IVTC filter in 1.9.x. I'm working on making sure everything's correct for 1.9.3.
It would be nice if VirtualDub could do that field order detection on its own. Say by running few dozen frames through bob deinterlacer and checking for juddering :)
Igor Levicki (link) - 17 06 09 - 11:33
The detection algorithm would be order of magnitude more complicated than the filter itself.
Although it would be really nice to have a reliable motion-estimation algorithm built into VirtualDub as it's a non-trivial basis which can be used for many nice filter functions.
Apart of that I agree that using top/bottom field is more self-explanatory (and IMO also widely used) than even/odd.
Kasuha - 18 06 09 - 04:11
I'm not sure it would be that hard, since we're only talking about a binary output and it's consistent over a number of frames. Just comparing the correlation between fields might be enough, because there's likely to be a significant difference between images that are 3 field times apart instead of 1 field time apart even without motion compensation. I wouldn't know where to put such a feature, though.
Motion estimation is something I've been interested in but haven't gotten around to working more on. I think the main problem is that ME is sooooo slooowwwwwww.
Phaeron - 18 06 09 - 23:25
Another problem would probably be where to do motion estimation, too - more times than I would have liked, applying motion estimation-based deinterlacing filters would produce perfectly clean images - but with a one-frame time difference between chroma and luma (mostly noticeable on cartoons, for example): having 'color ghosts' is a very strange experience.
So, motion estimation would be even slowwwwerrrrr if done 'properly': on both luma AND chroma channels! Yeugh...
Mitch 74 (link) - 27 06 09 - 04:24
Someone that have time and a good CPU and GPU may like this feature and don't bother if it is slow. :D
ale5000 - 12 07 09 - 10:46