jr,

I was referring to progressive source (and project properties), rendering to a resized progressive output.

Maybe I'll bold that in the original post as it was kind of buried in the text.

Since no deinterlacing is occuring, I would think we should set deinterlace method to "none", but I seem to remember somewhere someone recommending setting the "Deinterlace Method" upon resize - even if no deinterlacing is done. Again, this *could* just be a figment of my imagination.

...Jerry

This is really easy to test. I just did it again, and it takes less time than it will take me to write this.

Put some progressive HD material on the timeline. Set the Vegas project properties to progressive, and set the deinterlace method (in project properties) to either "blend" or "interpolate." Render to 720x480 progressive output. So, you are re-sizing progressive to progressive, but still telling Vegas to deinterlace.

Repeat, but set the project properties "deinterlace method" to none.

In my tests, as I expected, when I put the results back on the Vegas timeline, they looked identical, and both looked just fine (i.e., no unusual artifacts)

Repeat the above two tests, but this time start with some HD interlaced footage. Make sure to match the project properties so that the field order is specified correctly, i.e., in this case do NOT set project properties to progressive but instead set it to either upper or lower field first (probably upper, since this is HD video). Then, do the same two render tests and put the results back on the Vegas timeline.

This time you will see a huge difference. As JR said, the video you rendered with deinterlace method in project properties set to none will look AWFUL, with all sorts of combing artifacts. The extent of these artifacts depends on the amount of re-sizing.

So, if you keep the deinterlace method set to blend or interpolate, you should be OK with just about any input footage, although if you are absolutely certain that ALL the footage on your timeline is going to be progressive, go ahead and set it to progressive. Their might be some situations in which this will produce a better result.

However, if you have interlaced footage anywhere on the timeline DO NOT use "none" for the deinterlace method.

As usual, my explanations are too long, but hopefully the above is still clear, despite the length (it takes too long to edit).

johnmeyer,

Good analysis! It begs the question... If setting a Deinterlace Method makes no difference in Progressive to Progressive renders and it is necessary for Interlaced to Progressive, is there ever a situation where Deinterlace should be set to "None"?

...Jerry

is there ever a situation where Deinterlace should be set to "None"?I cannot cite a specific example from my own experience, but as I stated above, I have a sense that there might be some situation -- perhaps when blending two tracks of different-resolution progressive footage, each at different frame rates -- where you would get different results using "none" than with one of the two de-interlace settings.

It is probably worth stating why all this deinterlace stuff is important when re-sizing.

The reason that it is important is that when you reduce the number of pixels in a video, the re-sizing algorithm has to decide where to put each new pixel so that the underlying image at each moment in time looks more or less the same as the original, albeit at lower resolution, and therefore without as much detail. The problem with interlaced video is that the odd field is at both a different moment in time, and in a different spatial place than the even field.

In many ways, you have to think of the odd fields as being essentially unrelated to the even fields. If you think this way, then you can understand that if you combine them both together into a single frame and then re-size the combined result in one operation, the resizing algorithm uses information from both fields to determine where to put each new pixel. As a result, you end up getting a combination of information from different points in time, and different places in space. Look out!! When resizing video that contains a lot of motion, you end up with warped vertical lines, herringbone patters, and all sorts of garbage if you use the "frame" that results from combining the even and odd fields together.

The results of doing this are not just bad, but can often be spectacularly bad. Unusable.

The simple solution is to treat the even fields as one video stream, and the odd fields as a separate, unrelated video stream. So, re-size the even fields separately from the odd fields, and then mix them back together. This works, and avoids huge artifacts, but as objects move from top to bottom, you end up losing resolution, because the re-sizing algorithm only has information from every other line, and therefore cannot create a new pixel in the lower-res version that is placed very accurately. So, you lose detail and sometimes get various, although usually comparatively small, artifacts.

What most re-sizing algorithms try to do instead is to temporarily fill in the missing field for the even fields (and same thing for the odd fields) with something approximating what would be there if the other field was captured at the same moment in time. This approximation can be done in an infinite number of different ways, each with a different tradeoff. The two offered in Vegas are "interpolate" and "blend." If you don't want to use those, you can instead use one of two different free plugins, one provided by Mike Crash (smart deinterlacer), and the other is the Yohng Yadif deinterlacer based on the code for the AVISynth Yadif plugin.

Once the "missing field" has been constructed, you then resize the result. This result, since it temporarily has both the original even field plus the artificially-generated odd field that has been "interpolated" or "blended," is actually a full frame. After re-sizing, the algorithm throws away the odd field that had been constructed with the sole purpose of helping the re-sizing algorithm be more accurate.

Same thing is done with the odd field, giving you an interlaced, re-sized video.

If you are instead not only re-sizing, but also changing from interlaced to progressive, then you don't throw away the fields that were created for resizing but, since you now have twice the number of frames as the original (because each field has now been made into a frame) you end up throwing away every other frame to get back to the original frame rate. Or you can keep all the frames and end up with double-framerate video. This is one way to go from 29.97 interlaced to what is called 60p.

While I have defended interlaced video many times in these forums (it looks great if you just edit it and then render out to something that is the same size, such as going from SD video to DVD), there is no argument from me that when it comes to these types of operations (re-sizing): interlaced video has a severe handicap compared to progressive.

Thank you, John. I always learn a lot from your posts!

...Jerry

The only time I can think where I ever have set the deinterlace method to "None" was when I used Mike Crash's Smart Deinterlace plugin. It basically does a better job at deinterlacing than does Vegas. I haven't used it in a while so I can't remember how well it works when resizing is involved.

> "If setting a Deinterlace Method makes no difference in Progressive to Progressive renders and it is necessary for Interlaced to Progressive, is there ever a situation where Deinterlace should be set to "None"?"

I agree with John, in practice, I can't think of any reason to set this to None.

This setting does NOT tell Vegas to deinterlace your footage. What it says to Vegas is if, by some chance, you do something, and for whatever reason, you need to deinterlace... this is the method to use. That's why John Meyer saw no difference rendering progressive to progressive; Vegas had no need to deinterlace and so it ignored the method because it wasn't needed. It just sets the method to use, when and if Vegas needs to deinterlace.

~jr

This setting does NOT tell Vegas to deinterlace your footage. What it says to Vegas is if, by some chance, you do something, and for whatever reason, you need to deinterlace... this is the method to use.

Well, that explains why that setting doesn't turn OFF deinterlacing and allow me to save an unsullied still from the timeline. Stills saved from an NTSC timeline seem to be automatically and manditorially deinterlaced (or blurred, in practical terms) no matter what I do.

Still, it makes me distrust Vegas' deinterlacing logic if there are times when it does it and can't be turned off.

<edit>In addition to my problem extracting a clean still for use elsewhere, I'm also concerned that there are some circumstances where deinterlacing could happen twice within your edit</edit>

Rob

I've never been totally satisfied with the resizing method in Vegas. I'm just not keen on interpolating or blending fields before a resize (which is an interpolation itself).

I still get my best results in VirtualDub using the resize filter. (I've tried various AviSynth scripts too, but found no advantage there...) This with a tad bit of sharpen gives a very crisp clean output. Of course, it's a PITA extra step, but I'm willing to do it to get the quality I want.

I've never been totally satisfied with the resizing method in Vegas. I'm just not keen on interpolating or blending fields before a resize (which is an interpolation itself). I still get my best results in VirtualDub using the resize filterWell, if you use the resize filter built into VirtualDub, you will notice that it has a box labeled "interlaced" which you can check. If your source video is interlaced, you must check this or else you will, depending on the resize amount, get absolutely horrendous artifacts in the resulting re-sized output. And, if you check it, guess what? The Virtualdub filter does exactly the same thing as Vegas: it creates those even and odd fields using some sort of algorithm.



You might get different and, perhaps, better results with the VD filter. It certainly has several nice features which help you pick resize percentages that are MUCH "friendlier" to the resizing process ("codec friendly").