When is it good to deinterlace first?

[fvisagie]

Hi All,

I've seen suggestions that e.g. Deshaker deinterlaces and reinterlaces less well than something like QTGMC and Select... + Weave. But are there other operations that also work better once the material has been deinterlaced? Do time or motion-based operations like MV analysis, MC etc. get thrown a little by the fact that a frame contains fields from two different points in time? For which operations is it best to deinterlace first?

Many thanks,
Francois

[fvisagie]

Another one I know of is deinterlacing before converting from YV12, to prevent chroma upsampling error if I understand correctly.

[LoRd_MuldeR]

Whenever you apply filters that operate on progressive frames, you have to deinterlace first (if input is interlaced). And of course it's a good idea to do that with a "high quality" deinterlacer, like QTGMC.

Applying a filter, which assumes progressive frames, on interlaced video will most likely destroy the content! So you have to deinterlace first, no matter what. You could re-interlace afterwards, if really needed.

Only time to can apply filters directly on interlaced video is when (a) the filter explicitly was written to operate on interlaced material or (b) the filter has a special "interlaced" mode you can use.

If, in case (b), the filter simply does a Deinterlace+Filter+Weave, then you are most likely better off by applying QTGMC first and then calling the filter in "progressive" mode. Although that probably is slower.

(BTW: Depending on what filter you are applying, it may also be reasonable to use SeparateFields() + YourProgressiveFilterHere() + Weave() instead of deinterlacing+re-interlacing)

[Gavino]

Only time to can apply filters directly on interlaced video is when (a) the filter explicitly was written to operate on interlaced material or (b) the filter has a special "interlaced" mode you can use.
However, although not explicitly stated in the documentation, you can safely use simple spatial filters that operate on each pixel individually, eg Levels(), ColorYUV(), Tweak(), etc.

[johnmeyer]

I think the following is a correct answer to your question -- at least to a first approximation:

Spatial only (as Gavino already said) [edit]see Gavino's note in his post below
no deinterlacing necessary.

Resizing
deinterlacing mandatory

Temporal filters without resizing
separatefields()
your filter
weave()

I welcome any corrections. I'm pretty sure the first two are correct, and the real issue is accurately defining those situations where the separatefileds()/weave() combination is all that is necessary. There are lots of potential pitfalls because some filters may do things "under the covers" that require the equivalent of resizing.

It is obviously worth doing this correctly because doing an unnecessary deinterlace needlessly degrades the video, but failing to do it when it is required will completely and totally screw up the result.

Or, to put this in the opposite sense: the separatefields()/weave() has very little downside when it is done in situations where it is not needed, whereas doing a deinterlace when it is not needed (and when you intend to watch on a display capable of correctly handling interlaced material) will pointlessly degrade the result because deinterlacing is a tradeoff that always degrades the video.



The following may be of some use (I copied this from this forum many years ago):

ApplyInterlacedFilter(last, "blur(1.5)")

function ApplyInterlacedFilter(clip v1, string filter)
{
v2 = separatefields(v1)
selecteven(v2)
even = Eval(filter)
selectodd(v2)
odd = Eval(filter)
interleave(even,odd)
return weave()
}

[StainlessS]

Thread on such:
http://forum.doom9.org/showthread.php?s=&threadid=59029


See jdl-interlace.avsi by Stickboy here:- (JDL_UnfoldFieldsVertical, JDL_FoldFieldsVertical)

http://avisynth.org/stickboy/

[Gavino]

Spatial only (as Gavino already said)
no deinterlacing necessary.
I said no deinterlacing was necessary for simple spatial filters, in particular where each output pixel depends solely on the corresponding input pixel.

That does not apply to those spatial filters where the output pixels may depend on input pixels from a different field (eg Blur()).

[06_taro]

If you really need to filter interlaced stuffs, and your filter is neighbour-pixel awared (not simple levels, tweak, as mentioned above), I personally recommend you to use a comb-adaptive method:
1. filter as if input clip was progressive, result=f_P
2. use separatefields.filter.weave or any other hacky methods to do field filtering, result=f_I
3. merge two results with a local comb mask, to use f_I in comb areas and f_P in non-comb areas.

This method will reduce possibility of some filter generating comb effects in originally non-comb areas, which is usually not what you intend to achieve. If your input interlaced clip is a pure video clip, i.e. 60 separate fields per second, not create by pulldown, then the comb mask may also be substituted by motion mask, as normally only static areas can be safely weaved into non-comb area, while some field filters may result in weird artefacts in those areas. If your input is pulldown clips, not using this method may also destroy the patterns of telecine.

Actually the same thoughts also applies to interlaced chroma sampling, in which it is better to use different method to do sampling for comb/non-comb areas. You can find some more details in AutoYUY2. And in some new HD discs up-converted from old SD-mastered contents, using same field-based upscale method in both comb and non-comb areas will usually result in cross-upconv artefacts.

[StainlessS]

What if any problems arise out of using above posted Stickboy's (EDIT: Post #6) script funcs, so far
as I can tell, it deals with all interlaced (allows use with any spacial/temporal filters) without problems ?

[johnmeyer]

I said no deinterlacing was necessary for simple spatial filters, in particular where each output pixel depends solely on the corresponding input pixel.Actually, now that I think about it, that would include a lot of filters.

I added an edit to my post above to reference your later post.

[Overdrive80]

I think that proper it is:

Load source
Deinterlace
Crop
Resize
Spatial denoiser+Dither
Temporal Denoiser+Dither
Others as tweak

[Mole]

I think that proper it is:

Load source
Deinterlace
Crop
Resize
Spatial denoiser+Dither
Temporal Denoiser+Dither
Others as tweak

I think this would depend on if you are upscaling or downscaling. If you increase the size, I would denoise before resize and sharpen after.

But if downscale, I would denoise after resize, and possibly sharpen before.

denoise
upscale
sharpen

sharpen
downscale
denoise

Naturally, I'll include the standard disclaimer that in the end, it still depends on the nature of your source. For example how much you are resizing and the amount and type of noise.

[fvisagie]

What if any problems arise out of using above posted Stickboy's (EDIT: Post #6) script funcs, so far
as I can tell, it deals with all interlaced (allows use with any spacial/temporal filters) without problems ?

Ingenuous what he does! (In a way it seems similar to johnmeyer's ApplyInterlacedFilter() - Stickboy consolidates fields spatially and ApplyInterlacedFilter does so temporally.)

To a layman like myself it seems this approach might mess up temporal processing (which usually works with immediately adjacent images)? With this approach time-adjacent fields will be moved out of the way, and temporal filters will end up working with every 2nd field only?

Thanks for all the highly informative input so far, much appreciated. How about helping me out a little with handling non-square pixels (http://forum.doom9.org/showthread.php?t=167316) also? ;)

[fvisagie]

Resizing
deinterlacing mandatory


If all one wanted to do was geometrically changing clip geometry (i.e. something like crop or resize), would ApplyInterlacedFilter() work for "deinterlacing" in this case? Apart from the user needing to take care of adjusting crop and resize parameters for field size, in my layman's view this should then be able to correctly operate on each field in isolation without interference from the other?

However, I suspect this is possibly somewhat of a moot point in my usual DV->DVD workflows that include deshaking, temporal denoising etc. - I might as well properly deinterlace with something like QTGMC and be done with it for the rest of the workflow as Overdrive80 and Mole suggest. Although making sure always helps if only to aid learning.

What is the role of Dither in denoising? Does it have benefit anywhere else? Feel free to point me to a good read lest I contaminate this thread.

[fvisagie]

What is the role of Dither in denoising? Does it have benefit anywhere else? Feel free to point me to a good read lest I contaminate this thread.

I found it on the Avisynth external filters page, thanks.

[2Bdecided]

Especially for motion-compensated denoising, I have got much better results with proper deinterlace, denoise, re-interlace.

SeparateFields().denoise.weave isn't as good
Working on odd and even fields in two separate videos isn't as good
(the above two can be catastrophically bad if the noise in odd fields is consistently different from noise in even fields).

poor deinterlace, denoise, re-interlace is slightly inferior for adding blur/aliasing.

You need to deinterlace before any filter that risks getting the contents of one field into the other field (e.g. vertical blur, vertical sharpen, vertical resize, vertical anti-alias, anything motion compensated etc etc), or any filter that ideally needs access to the true temporal resolution of interlaced video (i.e. individual fields) (e.g. fade).

Cheers,
David.

[fvisagie]

Thanks very much, David. Fade never even crossed my mind, and that's the one "effect" I do actually use a few times in most videos.

poor deinterlace, denoise, re-interlace is slightly inferior for adding blur/aliasing.


What do you mean here? Are you talking about adding blur/aliasing on purpose, or what am I missing?

[2Bdecided]

What do you mean here? Are you talking about adding blur/aliasing on purpose, or what am I missing?I mean using that process adds blur/aliasing when you do not want it to.

Cheers,
David.

[fvisagie]

Thanks for clearing that up!