> "Can someone tell me if this statement is 100% true?"

No it is not 100% true. There are many ways to deinterlace and that statement only refers to the method known as "Interpolate Fields" In Vegas. There is also a "Blend Fields" method in Vegas that does not reduce vertical resolution. Some 3rd party deinterlaces use other methods.

> "One more question, why cant interlaced footage on the timeline just be rendered out as true interlace footage with out deinterlacing? "

It can if you don't do any processing to it. Deinterlacing would only occur if you apply a plug-in that requires progressive video. In that case, Vegas would quietly deinterlace the video, have the plug-in process it and re-interlace again.

~jr

"Just set the "deinterlace method" in the "Project Properties" to either "blend" or "interpolate." In this case, it doesn't matter which one. (The method chosen only really applies when converting interlaced to progressive, which is not what your doing. I always use interpolate.) Set rendering quality to "Best" which tells Vegas to use the higher quality Bicubic rescaling algorithm and you're "good to go.""Over on another forum, this subject recently came up. I responded with essentially the same advice as John's - which I've gleaned from this forum over the years.

However, a poster responded with, "What if the source footage is HD progressive & rendered to SD Interlaced? How should the the Deinterlace Method be set?" My response was, "I don't know whether Vegas uses it or not for resizing in this case, but set it to either blend or interpolate as it will not be used if not needed."

Comments?

...Jerry

That's about it. The only problem with shooting progressive and delivering interlaced comes from having too much vertical resolution and that in turn causing problems with aliasing and line twitter.

A better low pass filter for Vegas would be a very good thing. This very issue has driven me nuts at times.

Bob.

... Deinterlacing involves removing one field and duplicating the other. This effectively reduces the vertical resolution by half, but is necessary to remove the jaggies if your video has motion/camera panning or transitions.As others have already stated, your statement is not entirely correct. However, some of the responses are also not "100% true" either, so let me try to sort things out.

The odd and even fields which make up each interlaced frame have two important differences from each other: they each come from a different moment in time; and they each represent a different place in space (being offset from each other by one scan line).

If you want to apply a filter (fX) to interlaced video, then in most cases that filter must be applied separately to the even fields and the odd fields, and then the results combined back together. This must be done because the two fields were captured at different moments in time. If you modified each pair of fields all at once, then you would be averaging together these two moments in time, and the fX would produce incorrect results.

This is what John Cline described, and he is correct, but only when applying effects (and even then, this approach is sometimes not correct, as when the fX averages frames from multiple moments in time).

However, you asked about resizing interlaced video from HD to SD. In this case separating fields, doing the resizing on each field, and then recombining, will produce seriously flawed results. I didn't realize this until a few years ago when I started reading hundreds of posts over at doom9.org. It was then that I realized that you cannot resize interlaced video because you need both spatial and temporal information to be from the same moment and place. Otherwise, the resizing algorithm cannot accurately decide where to place specific pixels in order to recreate fine details from the original video, but using a different number of pixels. This problem exists whether up-resn'g or down-resn'g, and is worse when the scaling is not a multiple of two.

The only way to do scaling by factors other than two is to deinterlace, where this operation is defined not as removing a field and then replacing it with a duplicate of the adjacent field, but instead as removing a field and replacing it with an estimate what what that field would have been if the video had been shot as progressive (60p in modern terminology). This estimate can be done by blending or interpolating (Vegas' two options) or by much more esoteric, but far better, motion estimation technologies.

The differences between doing this correctly and doing it wrong can be stunning. Some of the worst video I have ever received in my restoration work has come from people who have resized without doing any of the above-mentioned steps. The resulting video is virtually unwatchable, with strange morphs and movement in moving objects, and a general feeling that the video has lost all its details.

When working within Vegas, just set the deinterlacing to interpolate if your video has lots of motion, or blend if it is relatively static, and let Vegas do the rest of the work. Under no circumstances (when working with interlaced video) should you ever set the deinterlace property to "none," even if your final output is progressive.

If you want to get the ultimate quality, then read some of the recent posts in this forum by Nick Hope about resizing and the use of a very advanced, but difficult-to-use tool called QTGMC. The results of that can be stunning.

All of Nick's posts on this subject are worth reading.

Finally, I wish the Sony engineers would finally take some of this stuff seriously. This is supposed to be a pro product, and in this age of various resolutions and delivery formats, the need to up- and down-res video is an essential ingredient of any workflow. Simple interpolate and blend are nice consumer-grade approaches to the problem, but they most definitely are not "pro."

> "Under no circumstances (when working with interlaced video) should you ever set the deinterlace property to "none," even if your final output is progressive."

Well, maybe with one exception: when you use PsF footage in progressive project. What do you think?

If you are using PsF footage then with any luck Vegas will be given correct flags and see it as progressive. If that's the case then Vegas will combine the fields into frames and work with it exactly as it would with "P" footage. If the footage is not correctly flagged then it is still quite easy to manually fix this in Vegas and then it will be dealt with correctly.

Of course if pulldown has been used to store 24p in 60i then depending on the type of pulldown things can get messy or not. Shooting 24pA means pulldown can be removed with no loss.

Bob.

"If you are using PsF footage then with any luck Vegas will be given correct flags and see it as progressive"I know for a fact that, when setting project properties, the use of "match media settings" indentifies PsF footage shot on my Canon Vixia as interlaced - one must manually change the project properties to progressive.

Of course, what Vegas recognizes on the timeline and when rendering may be a completely different story.

...Jerry

"However, you asked about resizing interlaced video from HD to SD. In this case separating fields, doing the resizing on each field, and then recombining, will produce seriously flawed results. I didn't realize this until a few years ago when I started reading hundreds of posts over at doom9.org. It was then that I realized that you cannot resize interlaced video because you need both spatial and temporal information to be from the same moment and place. Otherwise, the resizing algorithm cannot accurately decide where to place specific pixels in order to recreate fine details from the original video, but using a different number of pixels. This problem exists whether up-resn'g or down-resn'g, and is worse when the scaling is not a multiple of two.

This sounds like an interesting subject. Reading through what you've said though it seems to me that several things are getting mixed up that shouldn't be.

What I've seen being done with some filters, NOT the ones in Vegas, is assuming interlaced video can be processed as half height frames e.g. 720x240. That can produce a horrid mess and is what Vegas appears to do when the de-interlace method is set to none.
If the de-interlace method in Vegas is set to interpolate each field is interpolated to full raster and each 720x480 frame is processed discretely. This is the correct approach, it really isn't de-interlacing at all, the pipeline is running at as 60p, not 30p. You do not need anything from any field other than the current one to correctly process the current field.

You can get a better looking outcome by using motion vector de-interlacing to get the full frames, this is true. It is also fraught with danger.

If you start with video from a less than high end HD camera you're going to be pretty safe. I sure don't own a high end HD camera with top shelf glass however I've already seen how you can get a really bad outcome that's a nightmare to fix. Shooting 720p50 with the EX1 to deliver 576i50 is very problematic and that's the same as what could happen doing a MV de-interlace before scaling.

That's probably why neither Vegas or any other NLE does not do this.
I'll go a bit further regarding your statement of "Simple interpolate and blend are nice consumer-grade approaches to the problem, but they most definitely are not "pro." "

If this were true then Vegas would not be being used to deliver high budget TVCs from footage shot on the best HD interlaced cameras money can buy and it is. Now, yes, I've had some pretty horrid results out of Vegas and for a long time I blamed it all on Vegas. The HD looked great and the SD looked pretty poor. What was actually wrong was the HD was horrid to start with, I just wasn't viewing it correctly. This I think is a huge trap that a lot of us have been falling into. The reality is even the expensive cameras like the EX1 are more than capable of shooting very poor HD. Under ideal conditions sure, you can wrangle footage out of them almost as good as the best cameras and lenses money can buy but open the iris fully or zoomed right in or right out and all that changes. A lens that'll hold 1,000 lines resolution fully open over the full range of focal length costs 5 times as much as an EX1 and that's where it all begins.

Bob.

If this were true then Vegas would not be being used to deliver high budget TVCs from footage shot on the best HD interlaced cameras money can buy and it is.I wasn't disparaging Vegas' ability to correctly and professionally edit HD when the output is HD. Instead, my criticism was intended to be targeted specifically at Vegas' ability to correctly and professionally change resolution. I stand completely behind my criticism: when re-sizing video, "blend" and "interpolate" deinterlacing will create inferior results to what can be obtained with motion estimation.

We went through this at some length in several of those Nick Hope threads a few months back, complete with tests and examples.

The real problem with deinterlacing and resizing in Vegas, which as John is quick to point out has already been abundantly documented, is that Sony doesn't have any history (that I know) of incorporating GPL tools and libraries into their editors, even though that license permits commercial use with certain conditions.

So for better HD to SD, or even 1080i to 720p for the web, we can't use x264, yadif, Lanczos, EED12, MCDEINT, QTGMC, and others except by frameserving or exporting out of Vegas to external processors and encoders.

There is also nothing preventing adventurous types from attempting to modify these tools to be used inside Vegas as plugins, although I suspect it would take a lot of work, and the range of options available say, as compared to Avisynth, would probably be limited. Fortunately there are frontends like Handbrake (for people like me) and MeGUI (for the Johns and Nicks of this world) to make our lives a little easier.

"The best things in life are free."

there is a free Yadif port for Vegas 10:

http://yohng.com/software/yadifvegas.html

I have it installed, but still I am using the free Mike Crash Smart Deinterlacer. Apart from being very slow, it works well for me Vegas 9-32. In fact, I left my computer running overnight to de-interlace a long .M2t that I shot several years ago, and am doing the same with another one this morning.

Still, I'm curious whether the yadif would be better. Does anyone know?

I did some tests with



and the



These are with the "out of the box" settings, I made no special attempt to optimize either of them.

See for youself.

I also ran a comparison of the Vegas deinterlace methods:



and



as well as




from musicvid and group.

@ John Dennis: thanks for the effort you've gone to post these comparisons.

I looked mainly at the Smart Deinterlace and the Yadif; but really couldn't see much difference.

Questions:
When you put them back on the Vegas TL, one over the other, then mute the top track so that the other shows at the same point in the clip, do you see any difference between these two?

Also, is the Yadif faster than the Smart Deinterlace?

"is the Yadif faster than the Smart Deinterlace"

Yadif is quite slow. To my eyes it certainly yields better de-interlacing than anything native to Vegas. It is easier to use than the Smart De-interlacer and produces less artifacts.

Bob.

But were talking about resizing interlaced to interlaced, not interlaced to progressive. Except for the unavoidable loss of detail going from 1920x1080 to 720x480, I've never had any problem with the way Vegas handles it. Interlaced NTSC video has a temporal resolution of 59.94 images per second, Vegas splits the frames into their separate 1920x540 fields (which are then, by definition, progressive), resizes the fields downward to 720x240 using Bicubic interpolation, then reinterlaces the 59.94 fields per second back into 720x480 29.97 fps interlaced frames and adds the anamorphic widescreen flag. Except for the obvious loss of spatial resolution by going from a large image size to a smaller image size, the temporal resolution does not change. Converting interlaced to progressive while maintaining the original size requires any deinterlacing method to "guesstimate" information which was not there to begin with and there is no perfect way to do this. Resizing interlaced to interlaced requires no guessing whatsoever, you're tossing out spatial information only, not creating information which was not originally there. What could possibly be simpler? Except for the possible risk of some line twitter due to thin horizontal elements in the image, where is the chance for Vegas to mess this up?

... Vegas splits the frames into their separate fields (which are then, by definition, progressive), resizes the fields downward using Bicubic interpolation, then reinterlaces the 59.94 fields per second back into 29.97 fps interlaced frames. ... Converting interlaced to progressive while maintaining the original size requires any deinterlacing method to "guesstimate" information which was not there to begin with and there is no perfect way to do this. Resizing interlaced to interlaced requires no guessing whatsoever, you're tossing out spatial information only, not creating information which was not originally there. What could possibly be simpler? Except for the possible risk of some line twitter due to thin horizontal elements in the image, where is the chance for Vegas to mess this up?

It is not a question of Vegas "messing up," but as I keep trying to get across, the "separatefields --> resize odd fields/resize even fields --> reinterlace" approach you very nicely described will not produce the best possible results. Yes, it is true that doing it this way avoids the truly horrendous outcomes you will get if your editing software attempts to resize both fields at once, as you would if the frame were progressive. However, the approach you describe will not produce correct results unless you happen to be resizing by exact multiples of two.

Why?

Well, it all has to do with details which don't fall exactly on pixel boundaries.

Suppose you have some very fine detail that is nicely displayed by a half dozen adjacent scan lines. Suppose further than this detailed object is moving. Because the video is interlaced, the odd and even lines will capture that detail at different moments in time. OK, lets resize this video to a lower resolution that is only thirty percent less.

Question: where should the resizing algorithm place the moving pixels in order to attempt to maintain as much of the original detail as possible?

If you resize the odd fields independently from the even fields you only have half as much information to deal with and therefore, even when doing a relatively slight resize of only thirty percent less, you are actually going to lose at least fifty percent of the information needed to recreate the detail, even before you start the resizing operation. If instead you had progressive video of the same resolution as your interlaced video, that resizing algorithm could use information from the two adjacent scan lines to make a vastly superior judgment as to where to place pixels in order to recreate that fine detail. Instead, all that information is completely and totally lost, and the resizing algorithm will create a scaled result that looks soft and lacks detail.

This is precisely the effect that dozens and dozens of people keep reporting in this forum whenever they make a DVD from their HD sources. Until Nick Hope led the crusade to understand this and to develop some techniques to deal with it, most people just assumed that “that’s the way it has to be.”

Not so. The results of downsizing from HD to SD resolution in Vegas are poor because Vegas does not use the vastly superior, professional approach that Nick has detailed in his posts, and which are the subject of countless posts over at doom9.org, videohelp.com, and other common forums where such things are discussed.

As the results posted in Nick’s long threads show, the difference in results is quite substantial and not subtle.

As to your comment that " any deinterlacing method to 'guesstimate' information which was not there to begin with and there is no perfect way to do this," that is absolutely a true statement, but it is also misleading. Even the worst deinterlacer is going to put you ahead of the game compared to "separate --> resize --> reinterlace" approach. As you begin to approach the theoretical perfection of a deinterlacer that can recreate the video as if it were shot progressive, you also approach the best possible resizing. And some of the modern deinterlacers are getting to be amazingly good, and are starting to approach that theoretical perfection.

Of course you then have to compare the dozen or so different re-sizing algorithms to see which one works best. I've read articles and posts about this until my eyes glaze over and my conclusion is that, compared to doing a great job of deinterlacing, the differences between re-sizing algorithms is relatively minor, that is unless you use bilinear, which does in fact stink. This explains why you should never use Vegas' "Good" quality rendering when resizing because it uses bilinear whereas "Best" uses bicubic.

I've been doing HDV to DVD since I got my camera back in 2008. No client ever complained, my family never complained, I can't complain. On every set, TV, DVD & BD player I've tried it on, it always looks better in every situation: motion, still, etc. Everyone who've I've shown it to says the same thing. Maybe it's just the footage I shoot or the way I'm shooting. Maybe it has to do with most people I know still use tube tv's.

I know exactly what you're saying, I've seen it if I downres CGI footage vs just render it at a lower resolution. I've just never had it be an issue in anything I've tape recorded and downresed.

To keep this thread from going off topic, I moved my comments to this thread. Please post any interlaced to progressive comments there.

"Well, it all has to do with details which don't fall exactly on pixel boundaries"

That problem applies as much to progressive scan video as interlaced video. This is a problem with all digital sensors that the designers try to improve on.


"If you resize the odd fields independently from the even fields you only have half as much information to deal with and therefore, even when doing a relatively slight resize of only thirty percent less, you are actually going to lose at least fifty percent of the information needed to recreate the detail, even before you start the resizing operation. If instead you had progressive video of the same resolution as your interlaced video, that resizing algorithm could use information from the two adjacent scan lines to make a vastly superior judgment as to where to place pixels in order to recreate that fine detail. Instead, all that information is completely and totally lost, and the resizing algorithm will create a scaled result that looks soft and lacks detail."

This makes no sense at all. Nothing is trying to decide where pixels should go. It is trying to decide what belongs in each pixel, NOT the other way around.


In all of these discussions one vital fact seems to get ovelooked. Interlaced video has a limit on vertical resolution. The limit is around 80% of full raster, anymore than that and you will get problems. Using mechanisms that attempt to achieve better outcomes risk breaking that limitation.
Now you feed substandard interlaced HD into a scaling system and you will get substandard SD out, that's just a fact of life. Sure you might well be able to wrangle more out of the process but if you use the same process on very good interlaced HD you will run into problems.

I've never been slow to put the boot into the SCS coders but on this one I strongly suspect they have known what they are doing.
If you doubt that then please show me another NLE that does it better. I cannot tell the difference between Vegas, FCP and PPro in this regard. Are all those coders stupid, lazy or clueless. TBH the only comments I've read is Vegas seems to produce superior SD from HD. For a while at least Ppro was making hash of it and Adobe do know a thing or two about image processing.

Bob.

My brother is currently the senior editor for the IndyCar series and I have a lot of extremely high-motion 1920x1080 interlaced footage directly from their HD cameras as 220Mbit DNxHD. This footage has been shot with ridiculously expensive cameras with equally ridiculously expensive lenses and looks much better than anything being delivered to anyone's home, highly detailed with pixels flying all over the place. I have resized this using the split field > resize individual fields > reinterlace method using only Vegas and compared it to widescreen footage shot with high-end broadcast SD cameras from just a few years ago. I have viewed this on a professional standard-definition interlaced CRT broadcast monitor. The Vegas-resized HD footage looks every bit as good, if not significantly better than native footage from the SD cameras. This is further reinforced with my own HD racing footage which was shot with a camera that humans can actually afford. Maybe I'm just being dense but if there's a problem with the Vegas method of resizing interlaced to interlaced footage, I'm just not seeing it.

But have you compared it to the "best" method suggested by Nick and others? Can you do even better than pure Vegas?

This makes no sense at all. Nothing is trying to decide where pixels should go. It is trying to decide what belongs in each pixel, NOT the other way around.I give up. I obviously have completely failed to describe the problem. I guess it is why I was never tempted to go into teaching.