AVISynth port of Gunnar Thalin's Smooth Deinterlacer

[Xesdeeni]

Announcing the AVISynth port of Gunnar Thalin's Smooth Deinterlacer. When operating in YUV mode, it is considerably faster than the VirtualDub version.

http://home.bip.net/gunnart/video/AVSPorts/SmoothDeinterlacer/

Features: Fast, area-based deinterlacing
Programmable edge detection to help eliminate false deinterlacing
Programmable static interframe detection to help eliminate false deinterlacing
Color coded mode to show deinterlacing during parameter tweeking
Log file to track interlaced frames (programmable percentage threshold)
Works in RGB or YUV color spaces
Works with interlaced frames or successive field input
Can provide output at the input frame rate (like Gunnar's Area-Based Deinterlace plugin for VirtualDub) or double the frame rate (like the Smooth Deinterlace plugin for VirtualDub)
All parameters are optional
See SmoothDeinterlacer.txt for details.

Xesdeeni

[wotef]

looks very interesting, thanks for your work

- note you may want to edit the documentation (very thorough, btw) on showlace as a boolean where default=false?

- how'd you sum up the differences between this and tomsmocomp given that both are adaptive deinterlacers for true video?

i used tomsmocomp and the vdub deinterlace smooth on a few captures to create progressive vids and gave up cause i couldn't get rid of certain artifacts that occurred sometimes with tomsmocomp and vdub deinterlace smooth was sooo sloooow

More generally, how is deinterlace smooth different from deinterlace area based given that in your version, now, the user can keep the input frame rate?

[Xesdeeni]

- note you may want to edit the documentation (very thorough, btw) on showlace as a boolean where default=false?Oops. That one got by both Gunnar and I. Since I don't want to bug Gunnary too much (he's being very kind to host the filter), I'll probably wait until I have a reason to update the filter itself before I correct this.- how'd you sum up the differences between this and tomsmocomp given that both are adaptive deinterlacers for true video?There are lots of adaptive deinterlacers out there. I didn't actually look into how they all did what they did. I just tried them and found I liked Gunnar's Area-Based Deinterlacer best (at that time). Since I needed deinterlacing for my standards conversion, I used that. I initially had a very complicated script, so I decided to port the Area-Based Deinterlacer to AVISynth. I also hoped things would speed up a bit. But I still haven't looked at other deinterlacer's code, so I can't speak to how they work.i used tomsmocomp and the vdub deinterlace smooth on a few captures to create progressive vids and gave up cause i couldn't get rid of certain artifacts that occurred sometimes with tomsmocomp and vdub deinterlace smooth was sooo sloooowIs it faster in YUV space as an AVISynth plugin?More generally, how is deinterlace smooth different from deinterlace area based given that in your version, now, the user can keep the input frame rate?Gunnar added the static detection to the Area-Based Deinterlacer when he created the Smooth Deinterlacer. He also added the static detection. Other than that, they are the same. The AVISynth port is also the same, but it gives you the frame rate option.

Xesdeeni

[sh0dan]

I can't see in your changelist, that you changed the width/pitch bug.

if you put crop(16,16,-16,-16) just before the filter, output is distorted.

This is because you use width instead of pitch, when jumping down a line. pitch can in some cases (as here) be significantly bigger than width. This is the case after this crop, and also to create better alignment for assembly code.

[stickboy]

One of the suggestions I made to Gunnar (and which he implemented in a build he sent me) was that the filter append to the log file instead of overwriting it each time.

Alternatively (or additionally), allowing the user to specify the logfile name would be even better.

[Xesdeeni]

One of the suggestions I made to Gunnar (and which he implemented in a build he sent me) was that the filter append to the log file instead of overwriting it each time.

Alternatively (or additionally), allowing the user to specify the logfile name would be even better.I'll look that this for a future release, but in the mean time, you should be able to rename the log file from one run before starting another.

Xesdeeni

[stickboy]

I usually enqueue several processing jobs in VirtualDub's job list and let the whole thing run overnight. Is there a way I can automatically rename the log files between jobs?

I guess I could put each Avisynth script in a separate directory...

[sh0dan]

Adding date/time to the filename seems like the easiest solution.

[stickboy]

I dunno. I'd prefer named log files that get appended to.

If the filenames were autogenerated from the date+time, I foresee myself with a bunches of accidentally created log files...

[Defiler]

Awesome. I've wanted this for a long, long time.

[sprit]

I'm trying out a couple of deinterlacers and decided to try this one too. Sometimes there is some ghosting in both smart- and smoothdeinterlace that I would like to get rid of, but how? The "aura" is red when enabling showlace so I tried rising lacethresh but that didn't work - really high values made a ringing type of aura instead.
I've attached a grab from VD using a script like this:
greed = video.GreedyHMA(1,0,0,0,0,0,0,0)
decomb = video.FieldDeinterlace( blend=false )
vd = video.ConvertToRGB()._VD_SmartDeinterlace(0,0,20,100,0,0,0,0,1,0,0,1).ConvertToYUY2()
toms = video.TomsMoComp( 1, 5, 0 )
smooth = video.SmoothDeinterlace( tff=true, blend=false )

[Xesdeeni]

I've noticed this effect too, but it's in the basic algorithm that Gunnar created. I think it is from the interpolation of the lines from the dominant field to fill in the missing lines. However, are you sure it doesn't sometimes appear in the other deinterlacers as well?

You'll notice that the dominant field differs from deinterlacer to deinterlacer. The smart deinterlacer and the smooth deinterlacer use one of the fields, while the others use the other field. That's why all the images don't have the exact same position. In the case of this frame, this causes the interpolated lines to fill in the object rather than remove it for the other deinterlacers.

I'm not certain, but I believe I see the same type of "ghosting" inside the object on the others. If the object were moving the other direction, or the field polarity were reversed (not field-swapped, but the field order was actually the opposite), the "ghosting" should appear inside the object on the smart and smooth deinterlacrs, and then be outside the object on the others.

I think you can simulate this reversal using the same footage by separating the fields, trimming the first field, complementing the parity, and then re-weaving the resulting fields.

Xesdeeni

[sprit]

Originally posted by Xesdeeni
I've noticed this effect too, but it's in the basic algorithm that Gunnar created. I think it is from the interpolation of the lines from the dominant field to fill in the missing lines. However, are you sure it doesn't sometimes appear in the other deinterlacers as well?
Well, I used to be, but now that I know what to look for the others have it as well. Thanks for the explanation!
I think you can simulate this reversal using the same footage by separating the fields, trimming the first field, complementing the parity, and then re-weaving the resulting fields.
Yup, I tried videoVD = video.SeparateFields().Trim(1,0).ComplementParity().Weave() on the "VD"-filters and all of the deinterlacers get the ghosting on the same side (and the streams get in "sync", too).

[neuron2]

Carefully inspect the individual fields. The ghosting may be there in the source fields, and not caused by the interpolation.

[Xesdeeni]

Donald is right. I should have been clearer: When interpolating, any anomalies in the result must come from the pixels used as a source for the interpolation. Unfortunately, for many of the sources of video we use, there is some interaction between colors of adjacent lines. DVDs can be encoded as frames (instead of fields), and the 4:2:0 nature of DVDs means that adjacent line pairs both contribute to the colors. PAL digital camcorders also use 4:2:0 (although in some cases they can separate the fields selectively). But most consumer-level digital camcorders usually have a single CCD, which requires interpolation of individual red, green, and blue elements to fill in the entire picture, so there is much interaction between colors in adjacent lines, whether PAL or NTSC. All of this means that when we reconstruct a frame from one field, we will inevitably have some distortion caused by the data in the other field.

Xesdeeni

[TheUnforgiven]

can someone put this filter somewhere else.
gunnar thalin site is banned (proxy censorship)!! in my country

[neuron2]

Originally posted by TheUnforgiven
can someone put this filter somewhere else.
gunnar thalin site is banned (proxy censorship)!! in my country Here you go.

[TheUnforgiven]

many thanks neuron

[cybernut]

Hi Xesdeeni
I think I may have found a problem. My test footage from a miniDV(NTSC) has static pictures in it. The first 14 frames (in VDub) are fine but starting at frame 15 the interlace the combing rears it's ugly head. It almost looks like it switches fileds half way through (I see the figure moving forward a bit). I tried the same clip with TomsMoComp and everything is fine. I forced Tff=False to do bottom field first from my camera. I can upload some pics if that would help. Any ideas?

Clive

[Xesdeeni]

Unfortunately yes, I'll need to see some footage to figure out what's wrong.

Xesdeeni

[cybernut]

Hi Xesdeeni
Here is a picture from frame 6, 13, 18. It is a one second still NTSC "photo". I captured the 3 frames in Vdub and copied to Coral Draw the relevent parts. Frame 6 is ok but you start seeing tearing at frame 13 and it is complete by 18. I can send you the clip if that would help. I'm not sure where to upload it.
My Avs script:
LoadPlugin("C:\WINNT\system32\MPEG2DEC.dll")
LoadPlugin("c:\program files\avisynth2\plugins\SmoothDeinterlacer.dll")
AviSource("C:\!capture\testfile.avi")
SmoothDeinterlace(Tff=False)

Clive

Edit: It seems the .jpg didn't attach properly or the mods haven't approved it yet. PM me with an email address if you still need the picture. Looking at it last night with the deinterlace tools of Tmpgenc, I'm wondering if there was a half frame cut off. I disabled the Tff=False and that didn't seem to help... so I'm not sure.
C

[TheUnforgiven]

@Xesdeeni
any plans for yv12?