exist any filter specially done for (deinterlace) flicker

[Didée]

Comparison of beta2 and alpha3: >LINK< (MediaFire, ~15 MB)

Sorry I forgot to Subtitle(). beta2 is to the left, alpha3 is to the right.

( Clip has been processed with Xvid settings that I use to watch out for bob shimmer: Hi-bitrate matrix, *no* B-frames. These settings are very sensitive to [differences in] bob shimmer, even when the eye can't notice easily.

Compressed individually, beta2 is 20% smaller than alpha3. That's an obvious indication that alpha3 has more bob shimmer. Exactly as expected. )

[der_groschi]

I'm following the discussion for some time now and i've read a lot about TGMC not being well suited as an input for srestore.
However, i still use it to feed srestore (with a simple TDeint(Mode=1) as detection clip) since with many sources where TDeint+EEDI2 and similar filters fail badly, TGMC still gives me a sharp, stable and flicker-free result.
Now my two questions are:
1) What about other advanced Bobbers (MVBob, MCBob, etc.)? Is there any good alternative to treat field-blended material?
2) Are there any tweaks for TGMC to make it work better for that purpose?

[txporter]

Originally Posted by der_groschi

I'm following the discussion for some time now and i've read a lot about TGMC not being well suited as an input for srestore.
However, i still use it to feed srestore (with a simple TDeint(Mode=1) as detection clip) since with many sources where TDeint+EEDI2 and similar filters fail badly, TGMC still gives me a sharp, stable and flicker-free result.
Now my two questions are:
1) What about other advanced Bobbers (MVBob, MCBob, etc.)? Is there any good alternative to treat field-blended material?
2) Are there any tweaks for TGMC to make it work better for that purpose?

I am glad that you posted your question. I hadn't seen the threads indicating why it was incorrect to use TGMC to bob field-blended material that needs to be srestore'd. I have been doing exactly that and I find the output to be good. After you posted, I tried to search for this subject and I found this thread and then this post by Didee.

This is the script that he recommended using. I don't know exactly what each piece of it means. Maybe Didee will step through it?? (please ) It looks like he is using TGMC to create the final output, but using a thrice bobbed clip to detect which frames are blended. I don't understand what is happening with the 3 bobs.

mpeg2source("VTS_02_5.d2v")
o    = crop(0,56,-0,-56)
tgmc = o.tempgaussmc_beta1u(1,1,1,edimode="nnedi2",blocksize=16,sharpness=1.33,SVthin=1.25,truemotion=true)
bob1 = o.bob(0,0.5)
bob2 = bob1.clense(reduceflicker=false).merge(bob1,0.5)
bob3 = bob2.mt_adddiff(mt_makediff(bob2,bob2.clense(reduceflicker=false),U=3,V=3),U=3,V=3)

tgmc.Srestore(frate=25.0,dclip=bob3)

[Gavino]

Originally Posted by txporter

It looks like he is using TGMC to create the final output, but using a thrice bobbed clip to detect which frames are blended. I don't understand what is happening with the 3 bobs.

...
bob1 = o.bob(0,0.5)
bob2 = bob1.clense(reduceflicker=false).merge(bob1,0.5)
bob3 = bob2.mt_adddiff(mt_makediff(bob2,bob2.clense(reduceflicker=false),U=3,V=3),U=3,V=3)
...

There's only one bob in there.

[txporter]

Originally Posted by Gavino

There's only one bob in there.

Ok, right. I see that. Still don't understand what is happening there exactly.

Clense is a function of RemoveGrain that performs temporal min-mix clipping for RemoveGrain, correct? I can't find any good information on the input parameters for Clense.

The merge function is used to then average (0.5) the luma and chroma channels of the two clips (the straight bob'd clip and the bob'd version that has been processed through clense), right? What is this actually doing?

Then bob3, seems to take bob2 (bob1 that has been clensed) and then clense it again, and then take the difference between the singly clensed and doubly clensed clip. I think that the U=3 and V=3 means that both luma and chroma should be processed. THEN, the difference between the singly clensed and doubly clensed clip is merged into the singly clensed clip. Why? Isn't this just the doubly clensed clip? This is where I have the most confusion.

The final srestore arguments, I think are more straightforward. It looks like it uses the TGMC clip as the output clip but srestore uses the clensed/bob'd clip to determine which frames to throw out/keep. What I don't understand totally (besides what I have shown to be beyond my comprehension above) is why the TGMC clip itself isn't suitable for the srestore function all on its own.

[Revgen]

^Unless you are using lossless mode, TGMC doesn't retain the original fields. The bobber you use needs to retain the original fields in order to use SRestore.

[txporter]

What are the benefits of using the bob/clense chain than simply bobbing with yadif or tdeint and using that for blend detect and then using tgmc for the interpolation?

[der_groschi]

Originally Posted by Revgen

^Unless you are using lossless mode, TGMC doesn't retain the original fields. The bobber you use needs to retain the original fields in order to use SRestore.

You mean because the blend-detection will get screwed up? That's what the TDeint'ed detection clip is for. But from what i remember, TGMC's motion compensation is a little useless on fieldblended sources.

[txporter]

Also interested to hear. I ran a clip (PAL=>NTSC) through TGMC.Srestore(frate=25) and again through TGMC.Srestore(frate=25, dclip=yadif) with yadif=Yadif(mode=1, order=1). I then did a Stackhorizontal on the two clips. I don't see any obvious issues with just running without the detection clip. Even when stepping through using the following comparison script. Some stuff highlights as different, but nothing that I can visually notice as a problem.

a=mpeg2source("video-1.d2v")
b=mpeg2source("video-2.d2v")

sub = a.subtract(b)
substrong = sub.levels(122,1,132,0,255)

return StackVertical(StackHorizontal(a.subtitle("TGMC.Srestore"),b.subtitle("TGMC.Srestore(dclip=Yadif)")),
 \ StackHorizontal(sub.subtitle("Difference"),substrong.subtitle("Difference amplified")))

If you are interested, you can download the 2 different stacked videos here.
stack-2plots.mp4 = TGMC vs TGMC(dclip=yadif)
stack-4plots.mp4 = same + differences

[der_groschi]

Also interested to hear. I ran a clip (PAL=>NTSC) through TGMC.Srestore(frate=25) and again through TGMC.Srestore(frate=25, dclip=yadif) with yadif=Yadif(mode=1, order=1). I then did a Stackhorizontal on the two clips. I don't see any obvious issues with just running without the detection clip. Even when stepping through using the following comparison script. Some stuff highlights as different, but nothing that I can visually notice as a problem.

Interesting videos. While both clips appear to look equally good in a quick visual comparison, every small difference means that srestore picked a different frame or made a different decision in its duplicate detection. Since (from my experience) TGMC tends to make blends almost dissappear, it's actually very hard to tell if srestore picked the right frames. Thanks to your nice demonstration, i can see it does not. So i would definitly say it's safer to feed srestore with a clean detection clip. From that point of view, didee's suggestion looks very reasonable to me.

[aegisofrime]

Didee: Would it be safe to say that now that you have a multicore PC yourself, there might be a multithreaded 64-bit version of TGMC in the works?

[txporter]

Originally Posted by aegisofrime

Didee: Would it be safe to say that now that you have a multicore PC yourself, there might be a multithreaded 64-bit version of TGMC in the works?

TGMC is just an avisynth script that uses other plugins. There was some talk in the ThreadRequest thread about attempting to incorporate that into the script itself, but that isn't limited to 64-bit. I wouldn't expect TGMC to be overhauled just because Didee has a new rig and a 64-bit system. Perhap, he will be able to tweak things a bit better because he has access to a machine with multiple cores. /shrug

[txporter]

Redid the speed comparison tests using AVS2AVI rather than x264 and included testing on a 480i and 1080i clip.

Test machine:
Q6600 cpu
4GB Ram
Avisynth 2.5.8 MT 32-bit (set)
Vista Home 64
AVS2AVI v1.39 (had to use LAGS encoding since I was getting crashes with null, so still not perfect)

Both clips were 2mins of source material [MPEG2].
aviscript (default settings example - NO setmtmode was used on any of the runs):

MPEG2Source("video1.d2v")
TempGaussMC_beta2(2,2,1,4,0,4,edimode="EEDI2",Smode=2,SLmode=2,Sbb=1,SVthin=1.0,pelsearch=2)

Table key:
fps [?x] default - speed comparison to default settings
%fps improvement - speed comparison to default for edimode changes, and then speed comparison to previous run for various bicubic edimode runs. Zero sharpening was compared to Smode/SLmode=1 run.

I included conversion time for folks to get an idea how long they can expect conversions to take.

Two highlighted percentages are the two settings that show the largest difference in fps for HD source vs SD source

Order of speed improvement gains:

        SD                 HD
1. edimode=bicubic   1. tr1 2=>1
2. edimode=Yadif     2. edimode=bicubic
3. tr1 2=>1          3. edimode=Yadif
4. edimode=nnedi2    4. edimode=nnedi2
5. edimode=nnedi     5. edimode=nnedi
6. SLmode 2=>1       6. rep2 4=>0
7. tr2 1=>0          7. SLmode 2=>1
8. sbb 1=>0          8. tr2 1=>0
9. pelsearch 2=>1    9. sbb 1=>0
10.rep2 4=>0         10.rep0 4=>0
11.no sharpening     11.pelsearch 2=>1
12.rep0 4=>0         12.no sharpening
13.SVthin 1.0=>0     13.SVthin 1.0=>0
14.tr0 2=>1          14.tr0 2=>1
15.Smode 2=>1        15.Smode 2=>1

[txporter]

Originally Posted by txporter

What are the benefits of using the bob/clense chain than simply bobbing with yadif or tdeint and using that for blend detect and then using tgmc for the interpolation?

I think I found some answers to this question in this post from Didee and perhaps a bit more in this one. As I understand it, it seems that ReduceFlicker/Clense are used to combat the bob shimmer that is seen in basically every bobber (except TGMC) so that srestore has as clean a detection clip as possible to pick out the correct frames.

[txporter]

Originally Posted by der_groschi

Interesting videos. While both clips appear to look equally good in a quick visual comparison, every small difference means that srestore picked a different frame or made a different decision in its duplicate detection. Since (from my experience) TGMC tends to make blends almost dissappear, it's actually very hard to tell if srestore picked the right frames. Thanks to your nice demonstration, i can see it does not. So i would definitly say it's safer to feed srestore with a clean detection clip. From that point of view, didee's suggestion looks very reasonable to me.

I am still trying to understand what is best for the detection clip. I encoded the same clip using a simple bob(0,0.5) as dclip, using yadif(mode=1, order=1) as dclip, using the 3 stage bob parameters as dclip (couldn't get reduceflicker=false to work so had to kill that part), and using only the tgmc bob input.

Stack of those 4 clips + source + avs can be found here. I included the frame number on each frame so that we can see which frame was chosen by srestore. I do see that sometimes a different frame is chosen for the TGMC input and sometimes different for yadif and sometimes different for bob(0,0.5) and other combinations. It looks to be picking either the odd or even frame. I don't know which is right.... I don't see blends in any of the outputs. Using a detection clip definitely results in faster detection for Srestore though (compared to using the TGMC bob as input).

update: moved this discussion to the Srestore thread

[Didée]

The following settings (all together) fixed the issue:

blocksize=8,
search=5,searchparam=4,dct=5,
SCth1=270,SCth2=144

I can't evaluate right now which is the most responsible ... my guess is that the scenechange detection was triggering when it shouldn't. But it would need closer examination to nail it down.

* * * *

Couldn't really look at the content yet, but ... isn't that MFlowFPS-style deformation in there?

[Redsandro]

Originally Posted by Didée

I'm getting tired of it, so throw it out in the wild ...

TempGaussMC, version beta-2.

Just like to say thanks, this is pretty awesome!
It does a very nice job on faster motion footage. On low motion footage it's a bit too clean for my taste. Feels like it's removing some valuable high frequency data. Makes the oldskool method tempting, but overall this is very nice!

The oldskool tdeint method is the other way around. Higher motion removes high frequency data probably because of ugly interpolating or something that looks like it.

The smoothing/cleaning on TempGaussMC can probably be toned down, but I am too lazy to read through the different topics about this.

For reference purposes, here's what I used:

SetMemoryMax(1024)
AviSource("test.avi")

ColorMatrix(dest=2,hints=false,interlaced=true)
LoadPlugin("D:\Program Files (x86)\AviSynth 2.5\plugins\nnedi2\nnedi2.dll")
LoadPlugin("D:\Program Files (x86)\AviSynth 2.5\plugins\mvtools\mvtools2.dll")
LoadPlugin("D:\Program Files (x86)\AviSynth 2.5\plugins\VerticalCleaner\VerticalCleaner.dll")

AssumeTFF()
TempGaussMC_beta2(2,2,3,EdiMode="NNEDI2",qual=3)

Oldskool:

## RED DGDecode Template 2008-04 (last update: 2009-11-28) http://www.Redsandro.com
# Keep it down, dunno if it helps, I don't notice swapping if set to 1 and I don't know optimal value for HD content.
SetMemoryMax(8)
AviSource("test.avi")

# Deinterlace
LoadPlugin("D:\Program Files (x86)\AviSynth 2.5\plugins\TDeint\TMM.dll")
LoadPlugin("D:\Program Files (x86)\AviSynth 2.5\plugins\TDeint\TDeint.dll")
LoadPlugin("D:\Program Files (x86)\AviSynth 2.5\plugins\nnedi2\nnedi2.dll")
AssumeTFF() # HDV
# Normal
tDeint(order=-1, emask=TMM(length=6),edeint=nnedi2())
# Double Frame rate
#tDeint(mode=1, emask=TMM(mode=1), edeint=nnedi2(field=-2))