Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
1st March 2013, 15:13 | #1 | Link |
Registered User
Join Date: Aug 2008
Location: Isle of Man
Posts: 588
|
When is it good to deinterlace first?
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 Last edited by Guest; 1st March 2013 at 19:09. Reason: rule 12 |
1st March 2013, 17:15 | #3 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
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)
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 1st March 2013 at 17:22. |
1st March 2013, 20:04 | #5 | Link |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,691
|
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): Code:
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() } Last edited by johnmeyer; 2nd March 2013 at 23:07. Reason: reference Gavino's later post |
1st March 2013, 20:41 | #6 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
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/
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? |
2nd March 2013, 16:28 | #7 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
That does not apply to those spatial filters where the output pixels may depend on input pixels from a different field (eg Blur()). |
|
2nd March 2013, 19:10 | #8 | Link |
soy sauce buyer
Join Date: Mar 2010
Location: United Kingdom
Posts: 164
|
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. |
2nd March 2013, 19:27 | #9 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
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 ?
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 2nd March 2013 at 20:10. |
2nd March 2013, 23:09 | #10 | Link | |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,691
|
Quote:
I added an edit to my post above to reference your later post. |
|
3rd March 2013, 01:25 | #11 | Link |
Anime addict
Join Date: Feb 2009
Location: Spain
Posts: 673
|
I think that proper it is:
Load source Deinterlace Crop Resize Spatial denoiser+Dither Temporal Denoiser+Dither Others as tweak
__________________
Intel i7-6700K + Noctua NH-D15 + Z170A XPower G. Titanium + Kingston HyperX Savage DDR4 2x8GB + Radeon RX580 8GB DDR5 + ADATA SX8200 Pro 1 TB + Antec EDG750 80 Plus Gold Mod + Corsair 780T Graphite |
4th March 2013, 12:11 | #12 | Link | |
Registered User
Join Date: Oct 2001
Location: Thailand
Posts: 259
|
Quote:
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. |
|
4th March 2013, 13:03 | #13 | Link | |
Registered User
Join Date: Aug 2008
Location: Isle of Man
Posts: 588
|
Quote:
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 also? |
|
4th March 2013, 15:07 | #14 | Link |
Registered User
Join Date: Aug 2008
Location: Isle of Man
Posts: 588
|
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. |
4th March 2013, 18:46 | #16 | Link |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
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. |
4th March 2013, 19:11 | #17 | Link |
Registered User
Join Date: Aug 2008
Location: Isle of Man
Posts: 588
|
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.
What do you mean here? Are you talking about adding blur/aliasing on purpose, or what am I missing? Last edited by fvisagie; 4th March 2013 at 19:13. |
Thread Tools | Search this Thread |
Display Modes | |
|
|