TDeint and TIVTC

[Chainmax]

I think the source doesn't show a strict cycle after bobbing. You can check a sample [link removed].


[edit]Nevermind, I get an error message saying that 2<=cycle<101 :(.

[tritical]

I forgot that I had it limited internally to a maximum of 300 (the 101 in the error msg is incorrect). I'll try and put up a new version tonight with that limit removed and an option to disable crc checking in tfm/tdecimate. Also a new version of TDeint with a fix for mode 2 with yuy2 input.

[Chainmax]

Great, thanks :). Do you want me to put the link to the sample again so you can check it out?

[tritical]

[link removed], changes:
TDecimate:
+ Removed maximum limit on cycle value (upper limit is now the # of frames
in the video)
+ batch option now disables input file crc checking (applies to all modes)
+ Minor changes to tfm match and d2v aided decimation routines
+ Display crc values in error msg when crcs don't match

TFM:
+ Added batch option (disables input file crc checking)
+ Display crc values in error msg when crcs don't match

For large cycle values (>30 or 40) I would definitely recommend doing an initial mode=4 pass to generate a stats file and then using that as input. Putting up the clip again would probably be a good idea... even if I can't help someone else might have an idea. I'd try modes 0/2/7 and see if any give satisfactory results... if not then give smart decimate a try.

TDeint will have to wait another few days.

[Chainmax]

I'll give this new version a try, thanks :). You can download the sample here (http://www.31012.com/~azulftp/VTS_01_4.demuxed.m2v).

[tritical]

[link removed], changes:
+ added expand parameter
+ added slow parameter and slow=1/2 matching modes from tfm
- fixed a typo causing mode 2 to crash with yuy2 input

expand will consider all pixels horiztonally within 'expand' distance of a combed pixel to be combed as well (default is 0). I saw Mug Funky mention that idea a few times and since it was quick to add I went ahead and did it. This should be the last rc release of TDeint, as I have nothing else planned that will actually go into it. I am still working on an improved motion detection algorithm, but it will be separate (though still usable within tdeint by the emask parameter).

[anonymez]

thanks tritical :)

[Chainmax]

Awesomeness, thanks :) http://smilies.vidahost.com/otn/wink/thumb.gif.

By the way, in which cases would TDeint(mode=1).TDecimate(to input framerate) be preferable to TDeint(mode=2)?

[foxyshadis]

Cool, a few new tweaks to test out.

[Mug Funky]

niceness! the expand feature works great!

the line:
tdeint(1,order,expand=4,tryweave=true,cthresh=3,mi=24,mthreshl=4,ap=2)

works exceptionally well, and believe me i tested it :)

one thing you might like to try is get some still footage (or even a still), and fade it out slowly.

like:

freezeframe(0,1000,500) #(or whatever frame)
separatefields().fadeout0(2*x).weave()

tdeint(whatever)

where x = the period of time you'd like to fade out.

i noticed without ap set, fades get passed through, even if they exceed the motion threshold (ie x = 256/mthreshl)

that's now really the only stumbling block of tdeint, and AP catches it pretty well, so i'm happy anyway :)

thanks again for the update

[tritical]

I'll look into the fade out problem. TDeint with mtnmode set to a 5 field check shouldn't weave anything that changes by more than the motion threshold over a two field (of the same parity) period, and defintely shouldn't weave anything that changes by more than that from one field to the next (of the same parity).

The new motion mapping should do much better on fade outs. It has an option that allows using a 6, 8, 10, 12, 14, or 16 field motion check... 6 checks one field and two field steps, 8 and up check one field and three field steps. Plus, instead of trying to weave everywhere it computes an inter and intra based edge or complexity mask and only attempts to weave where weaving would actually improve over using simple cubic or linear interpolation. Any of those pixels that can't be weaved are then interpolated using edi. I've been doing some experiments trying to train an edi for deinterlacing filter using a combination of sofm classifier and modular neural networks, but it hasn't been able to beat eedi2 yet.

[Chainmax]

Wow, TDecimate(cycleR=2003,cycle=5000) slows things down a lot :eek:. I'll stick to TDecimate(mode=7,rate=29.97) for now :D.

[Didée]

Something about "motion threshold" in related filters. Remember about the formerly mentioned two-thresholds method? Nah, how un-smart.

What I tried is: Instead of triggering motion just blindly "smallerthan [fix] is still, biggerthan [fix] is motion", make it adaptive as in "build E = {local max-min span}. smallerthan 20% of E is still, biggerthan 40% of E is motion, inbetween is inbetween".

Seems to work quite nice.:) For a scripted preview, just merge weaved and interpolated by the following mask:

mt_lutxy( motion_diff, min_max, "x 1 - y 1 + / 0.2 - 0.4 0.2 - / 255 *")

[tritical]

@Chainmax
Was that with or without first generating a stats file and using it as input?

@All
Well, I'm just about ready to release the new motion mask filter, but thought I'd explain the algorithm here and see if anyone has suggestions on improving it.

First, assume we have a sequence of top and bottom fields such as:
t t t t t t
b b b b b b

0 1 2 3 4 5 <= frame numbers

and that we want to generate a frame from the top field of frame 3... i.e. we need to create a bottom field to go with the top field of frame 3.

The first thing that happens is that an edge or complexity mask is created, using local variance, edge magnitude, and laplacian value, for the top field of frame 3. The mask marks each pixel as either 0 (flat) or 255 (not-flat). A slight dilation is then performed on the mask (any 0 pixel with at least 4 neighbors that are 255 is changed to 255).

Next, a mask for the bottom field is generated from the top field mask by marking any pixel whose 2 vertical neighbors in the top field are 255 as 255 and 0 otherwise. A pixel will also be marked 255 if either of the pixels in that location from the neighboring bottom fields has a difference to the two vertical neighbors in the top field of > fthresh. That last part is so that we don't miss detail that is present only in the bottom fields (say a single pixel tall horizontal line). The bottom field mask is then eroded (removes any 255 without at least 2 horizontal neighbors that are 255) and dilated (fills gaps up to 3 wide between 255 pixels).

At this point we have a mask of the bottom field indicating all pixels that are worth trying to weave (marked as 255). We then run the motion check on each of the indicated pixels. The motion check can be 6, 8, 10, 12, 14, or 16 fields (6 requires 3 static fields of each parity, 8 requires 4 of each parity, etc...)... it looks at all combinations behind, ahead, and across the current field. The motion check is optionally run on an externally denoised version of the input clip (if none is given it is run on the input clip itself). During the motion check, the threshold is adjusted on a per pixel basis based on the magnitude of the vertical gradient at the point we are trying to weave. In this case, that means for each bottom field pixel we difference its two vertical neighbors in the top field to get the vertical gradient. The threshold is adjusted between mt1 and mt2 based on ht1 and ht2... when the difference <= ht1 then the threshold = mt1, when the difference >= ht2 then the threshold = mt2, and if the difference is inbetween ht1 and ht2 then the value for the threshold is linearly interpolated between mt1 and mt2.

The output of the motion masking is a mask indicating at each point whether we should weave or not, and if so, from the previous field, the next field, or average of the two. If it was decided not to weave at a point, then it is marked to be interpolated using edi (plain linear or cubic is used for the flat areas). This mask is then post-processed to removed any pixels that are marked to be weaved but that don't have at least 2 horizontal neighbors that will be weaved. Optionally, the pixels to be interpolated with edi can be expanded outwards (i.e. mark all horizontal neighbors within 'expand' distance).

@Didée
Could you elaborate a little more? I don't exactly understand how you are making the min_max clip... is it the min and max differences for that pixel location within the neighboring 'x' amount of frames? Could you post the script lines you used to make the motion_diff and min_max clips?

[Chainmax]

@Chainmax
Was that with or without first generating a stats file and using it as input?
...

Without. I was not talking about the encode by the way, merely trying to jump to specific frames too much time as my machine is puny and the script is monstrous already.
How does the creating of the stats file work? If I need to make a whole encode that's out of the question as I have no HDD space for a lossless intermediate file.

[ChiDragon]

Thanks for adding the batch option. :D

I've just run into another problem though. The help file says:
"You can specify an ovr file and an input file at the same time. Matches and combed frames given in the overrides file will take precedence over those in the input file."

Shouldn't this also apply to frames set as clean in the overrides file? I'm trying to override the input file's setting of combed frames that really aren't, but it's using the input info. It works fine if I don't tell it to use the input file at all, but then I'll get some false matches.

You might wanna take a look at this scene too, it's using the clean D2V matches but finding them to have MICs around the 600-1000 range due to the fine lines on the ceiling.

[ChiDragon]

In fact the input file has "l" for those matches too, although they show up as "c (OVR)" and "p (OVR)" using display. How does TFM know whether to use c or p if the input says l?

I did get it to work, by also overriding the matches for those frames. Doesn't really make any sense to me why that would be necessary though...

Erm... now using an ovr file in TDecimate is causing it to ignore all hints. It sees every match as "p" and doesn't know where the d2vdups are. Using the previous version fixes this.

[tritical]

@Chainmax
By stats file I just mean tdecimate(mode=4,output="stats.txt"). To generate it, remove (or comment out) everything after tdecimate in your script, change the tdecimate line to the one above, open the script in vdub, and then go to "run video analysis pass"... no intermediate file is necessary. Then just change the tdecimate line back to what it was originally, add input="stats.txt" to it, and uncomment out all the other lines. That way it wont have to process 5000 frames everytime you seek to frame in a new cycle.

@ChiDragon
I was able to reproduce the problem with tfm where combed frames marked as 'l' or 'h' in the input file (l/h basically mean c+) would not be overridden by an ovr file marking them as not combed. The reason is that it correctly sets the combed flag to 0, but it doesn't reset the match to 'c'. Therefore, when tfm grabs that frame's match during execution it sees 'l' or 'h' which it takes to mean c +. I'll fix that in the next version. For now you'll have to override the match for the frame as well.

Also, you said that the display info would show an 'l' or 'h' match as 'c' or 'p'? If it ever shows it as anything other than 'c' that is definitely a bug. Could you provide a step by step way that makes it show as something other than 'c'?

On the tdecimate problem could give the exact script you used? I can't duplicate the problem and I can't see any changes from the last version that would cause it.

[Chainmax]

@Chainmax
By stats file I just mean tdecimate(mode=4,output="stats.txt"). To generate it, remove (or comment out) everything after tdecimate in your script, change the tdecimate line to the one above, open the script in vdub, and then go to "run video analysis pass"... no intermediate file is necessary. Then just change the tdecimate line back to what it was originally, add input="stats.txt" to it, and uncomment out all the other lines. That way it wont have to process 5000 frames everytime you seek to frame in a new cycle.

I will try it as soon as possible then, thanks for the tip :) http://smilies.vidahost.com/otn/wink/thumb.gif.

[tritical]

@Mug Funky
I looked into the fade problem and what's happening is that internally tdeint has a threshold such that if the pixel from either the previous or next field has an abs() difference of < 4 to both of the vertical neighbors in the current field it weaves it regardless of motion. So if mthreshL is 6, and you do:

blankclip(length=100,color=$ffffff,pixel_type="YV12")
separatefields()
fadeout0(2*73) # fades from 235 to 16 over 146 frames
weave()

the difference per field of the same parity is (235-16)/73 = 3. With the 5 field check, tdeint checks both single frame and two frame steps... so it should still detect all pixels as moving. However, since the per field (not same parity) difference is only 1.5, which is < 4, it weaves the pixels. In fact, with that < 4 limit the longest fade it would not weave is:

4 = (235-16)/x
x = 54.75

so roughly

fadeout0(2*27)

in this example. I removed that < 4 bit and it indeed handles everything up to

fadeout(2*73)

as expected. I'm not sure why I put that < 4 part in there, it might have been for speed, but I'll remove it in the next version. The reason AP tended to catch the fades is that all the pixels that were weaved due to the < 4 part, but that failed the motion check, were treated as moving for aptype=1/2.

[ChiDragon]

@tritical:
My mistake with the l/c/p thing, the "l +" matches show up as "c (OVR)" and "COMBED FRAME". The ones that show up as "p (OVR)" and "COMBED FRAME" are listed in the input file as "p +". The "p +" ones ARE shown as "l" in TDecimate's display listing though, except when PP=1 (then they're "p").

I just checked and the problem with TDecimate and hints only happens when batch=true in TDec (batch=true in TFM doesn't matter). For what it's worth, this occurs even if the ovr file is blank.

[tritical]

Reproduced it now. I originally added the batch parameter to tdecimate as a way to be able to load a script with tdecimate(mode=5,...) without having complete input files... that way you could set up the two pass mode=4/5 process in vdub's job control all at once. For that too work, it had to set some internal arrays to fake, but usable, values. The problem is that if mode isn't set to 5 then tdecimate thinks the values are good and uses them. Anyways, I forgot to have it check that mode is indeed set to 5 before setting the arrays to fake values. It'll be fixed in the next version. Thanks for the reports.

The "p +" matches showing as "l" in tdecimate is how it is suppose to work. Specifically, any combed frame, regardless of the match, should show up as either "l" or "h" in tdecimate if pp>1 in tfm. If pp=1, then only combed c matches will be translated into "l" or "h" and the others will stay as they are. It's not a pretty system, but it gets the job done :).

[Chainmax]

@Chainmax
...Then just change the tdecimate line back to what it was originally, add input="stats.txt" to it, and uncomment out all the other lines. That way it wont have to process 5000 frames everytime you seek to frame in a new cycle.

I don't understand that. The stats file was created and the Mode2 and Mode0 scripts are:

MPEG2Source("X:\wherever\myvideo.d2v")

Trim(0,1982)+Trim(2355,0)

SeparateFields().DeBlock_QED().ColorYUV(off_y=-3,gain_y=20,cont_u=0,cont_v =51.2,opt="coring").Weave()

Interp = SeparateFields().EEDI2(field=3,maxd=29,nt=80,pp=3)
TDeint(mode=1,order=1,type=3,mtnmode=3,tryweave=true,edeint=Interp,slow=2)

Crop(22,4,688,554,align=true)
Lanczos4Resize(656,448)

TDecimate(mode=2,rate=29.97,input="stats.txt")

MPEG2Source("X:\wherever\myvideo.d2v")

Trim(0,1982)+Trim(2355,0)

SeparateFields().DeBlock_QED().ColorYUV(off_y=-3,gain_y=20,cont_u=0,cont_v =51.2,opt="coring").Weave()

Interp = SeparateFields().EEDI2(field=3,maxd=29,nt=80,pp=3)
TDeint(mode=1,order=1,type=3,mtnmode=3,tryweave=true,edeint=Interp,slow=2)

Crop(22,4,688,554,align=true)
Lanczos4Resize(656,448)

TDecimate(cycleR=2003,cycle=5000,input="stats.txt")

The Mode0 version, just like before, can't even load the video. The Mode2 version nets an access violation error pointing to the TDecimate line :(.

[tritical]

There seem to be a few logic errors in the mode 0/1 code making it still go through and request all the frames in the cycles even though it has all the stats info. I'll fix that.

On the mode 2 access violation, does it occur on load or during processing? and is it only if you use an input file?

[Chainmax]

The access violation occurs when trying to load the script. Upon editing the script and commenting out the stats loading portion the script loads fine.

[tritical]

Could you add "debug=true" into the tdecimate line, have DebugView open, and then try to load the mode 2 script that crashes? Post the output you get back here... should give some idea of where the problem is since I can't seem to reproduce it.

[Chainmax]

I bet it's just one of those random Avisynth issues, but I'll try your suggestion as soon as I can and report back.

[ChiDragon]

@tritical:
Would it be possible to add a "flags" option for D2V match use that only checks scene changes for being combed? Like a limited flags=4. Checking with flags=1, scene changes seem to be the only places where there are combed D2V matches in my files.

By the way, I've noticed some frames reported as d2vdups by TDecimate that aren't dupes at all. I haven't seen it actually decimate these frames, so I guess it doesn't matter, but I thought it was weird.

[tritical]

A flags option that checks the d2v matches for combing only around scenechanges would be possible to add.

To diagnose the d2v dup problem I'd need the d2v file and an output file from tfm generated with a run using:

mpeg2source("d2v.d2v")
tfm(d2v="d2v.d2v",output="output.txt",+any other options)

Also, a list of some of the frames being incorrectly reported.

The requirement to be a d2v dup is that the combination of the match used in tfm and the rff flags in the d2v file indicate that one field is present in both the current and previous frame.

[zoinbergs]

Hey guys! I got a quick question for ya.. hopefully it means a quick answer is on the other end...

I'm currently trying to field match some 25p footage that has been 3:2 telecined from 20fps, and it's fields are (unfortunately) blended.

Here's a quick example:

http://www.sendspace.com/file/zp3t0z


Could anybody possibly define some basic terms for TFM (I believe I would need to use) to give me a push in the right direction?

Somebody told me that TFM can match field blended frames, so I presume I'm in the right place, am I not?

I've been trying for days to get "restore24" to work, as that is exactly what I need to do (if one were to consider my footage 3:2 pulldowned from 23.976 to 29.97), but I just cannot seem to get my script to work with it! You can have a look at my thread here on it if you'd like:

http://forum.doom9.org/showthread.php?t=117006

I've almost given up on restore24, and am looking for any possible alternatives. TFM and TDecimate look promising I must say! Wow can you guys code!

.....................................................................

So I believe I can start with TFM(mode=7) right? I read that in the handy tutorial, but that's all I've figured out so far.

Any and all help is most definitely appreciated, and is considered to be priceless for me! I would be forever in debt to somebody who can help me figure this one out.

Thank you in advance, and keep up the AWESOME work. :)



EDIT: My prayers have been answered with the wonderful tool FixBlendIVTC!!!! Have a nice day guys, and thank you anyway!

[ChiDragon]

Well, I started opening a bunch of instances of VDub for the false d2vdups as I found them, until I noticed that they disappear when the script is reopened! This is true for the 7 or so that I found up to that point. What the...

[tritical]

Declaring a d2v dup requires that tfm knows the match that was used for the previous frame. If you reopen a script or seek to a frame without processing the frame before it (and you aren't using an input file), then it doesn't have that information... in which case it wont declare the frame a d2v dup. What is the script you're using?

[ChiDragon]

Actually, I was using an input file. I did try seeking once, forward and back, to see if the d2vdup would reappear and it didn't.

V = MPEG2Source("J:\PVR Extractions\211.d2v")
A = NicMPASource("J:\PVR Extractions\211 T01 DELAY 0ms.mpa")
AudioDub(V,A)
AmplifydB(15)

Trim(1589,4289)+Trim(8092,27742)+Trim(56212,75941)+Trim(81492,101986)+Trim(107616,109331)

TFM(d2v="J:\PVR Extractions\211.d2v",trimIn="cap3_TI.txt",mode=0,slow=2,micmatching=0,PP=5,blockx=32,blocky=32,MI=160,input="cap3_TFM.txt",ovr="I:\cap3_TFM_ovr.txt")
TDecimate(mode=1,dupThresh=0.4,hybrid=1,vidThresh=3,vidDetect=1,input="cap3_TDec.txt",ovr="I:\cap3_TDec_ovr.txt")

Crop(4,4,-18,-4)
LanczosResize(512,384)


I'm actually using the previous version of TIVTC BTW, to avoid that hints issue.

[tritical]

Could you send me the following:

211.d2v
cap3_TI.txt
cap3_TFM.txt
cap3_TFM_ovr.txt
cap3_TDec.txt
cap3_TDec_ovr.txt

Even if it goes away after moving around a few frames, if just getting it the first time (opening the script and requesting a set of specific frames in a specific order) is reproducible then that should be enough.

You can zip the files and email them to me as an attachment, or upload them to:

66.189.231.68:17252
user/pass: upload/upload

or if you have a place to host then that's fine too. I'd like to get this issue figured out before releasing another version as the d2v dup detection is a major part of the decimation routines. There are some safety checks in place that will keep it from doing anything really stupid (a d2v dup also has to have a difference metric <= to the lowest in the cycle for most stuff), but having it correct would be best.

[ChiDragon]

Sorry, I wasn't clear about the seeking thing. When I said "I did try seeking once, forward and back, to see if the d2vdup would reappear and it didn't" I meant that in reference to reopening the script in VDub via F2. Seeking back and forth when a false d2vdup does appear doesn't cause it to go away, only reopening the script does.

I thought I mentioned this before, but I guess not: the false dupes only seem to occur in cycles where there already is a real d2vdup.

I actually deleted those files once I was done with that encode, sorry... But I've found a place in another ep that I can reproduce by seeking a specific way.

Open the script in VDub, "Go To Frame" 4133 (all frame numbers are post-decimation), seek forward to 4275, then backward to 4147 and the first false d2vdup occurs, at the end of the cycle. Seek back further, to the next cycle, and there's another at the end of the cycle. The start of this cycle is at 4140 (2 cycles after the initial frame sought).

If you seek further in the initial forward-seeking, to say 4300, there are more false d2vdups, now appearing in the backward-seeking as early as 4195 and continuing each cyle backwards until 4140. More false dupes can be added by going further forwards and then backwards again, even without first reopening the script.

Those results are when an input file is used for TDec (input/no input for TFM gave the same results either way). If no input file is used, the false d2vdups appear "sooner" in the backwards-seeking (4133->4300=4243 rather than 4195).

Using this:
TFM(d2v="J:\PVR Extractions\212.d2v")
Trim(1709,4412)+Trim(8906,30480)+Trim(34974,50748)+Trim(55692,73536)+Trim(78932,101454)+Trim(107747,109462)
TDecimate(display=true)
Rather than this:
Trim(1709,4412)+Trim(8906,30480)+Trim(34974,50748)+Trim(55692,73536)+Trim(78932,101454)+Trim(107747,109462)
TFM(d2v="J:\PVR Extractions\212.d2v",trimIn="cap7_TI.txt")
TDecimate(display=true)
causes them to appear one cycle "sooner" still, at 4247.

Using that final script with no TrimIn file, I decided to try using Go for both 4133 and 4300 rather than seeking to 4300, and the result was d2vdups as early as 4295 (2 cycles before 4300) when I did backwards-seeking from there. Seeking backwards seems to be the key, at least in this instance; just jumping forward and backward with Go didn't cause it.

Weirdness all around... Hope my explanation of this isn't too confusing.

[tritical]

Could you test this build: [link removed] and see if it fixes all the false d2v dup detections? The false detections were caused by a combination of random access, hints, and a bug in the d2v dup decision code. It also has the fixes for all the other issues.

[ChiDragon]

It all appears to be fixed, thanks! :D

[tritical]

Only 18 months since v1.0 beta 1 ;)... here is [link removed]. Changes:
+ added blend deinterlacing option (type = 4)
- changed denoise default to false
- pixels detected as moving, but with absolute difference < 4 to both vertical
neighbors are no longer automatically weaved (should fix problems with slow fades)

[anonymez]

finally ;)

thanks tritical

[Mug Funky]

thanks tons!

will try it out immediately.

[edit]

awesome performance on fades! picture doesn't bob around, but smoothly comes up the way it should. excellent. i can significantly raise my thresholds now.

the uppermost line appears to behave strangely on odd fields (when deinting top-first stuff). it appears to be getting weaved.

[Terranigma]

Thanks for the awesome update to this great deinterlacer :cool:

[ChiDragon]

Hmm I tested TDeint with type=4 on telecined and 29.97 CGI material (which is all I have around at the moment) and it left artifacts all over.

[Mug Funky]

@ chidragon:

maybe check the field order? that's the obvious thing :)

only problem i have is the topmost line is being weaved at all times.

[tritical]

@Mug Funky
Yes, the top most line with field=0 and the bottom most line with field=1 is always weaved from the current frame. Its been that way since the beginning. I'll probably change it in the future.

@ChiDragon
Probably its not artifacts (in the sense that it's incorrect behavior) but just the fact that blur deinterlacing combined with motion-adaptation (especially bi-directional motion-adaptation) doesn't work that well or make a lot of sense. The current implementation, for pixels that are marked to be interpolated, simply weaves the pixel from the current frame and does a [1 2 1] vertical blur on it and its two vertical neighbors. With mthreshL=0/mthreshC=0 this gives identical results to blur(0,1) or blendfields(). If the the motion thresholds are > 0, then it ends up weaving stationary pixels and filling moving areas by averaging the current field and either the prev or next field (depending on whichever is weaved into the current frame).

It is possible to make the kernel more complicated... alignfields(mode=2) extends it out horizontally to become [1 2 1, 2 4 2, 1 2 1]... just apply a horizontal [1 2 1] to the vertical [1 2 1]. In fact, there is no reason to prefer averaging in only the field that happens to get weaved into the current frame... alignfields(mode=3) extends its mode 2 to include both the prev/next field in the averaging.

In my mind, the whole reasoning behind blend deinterlacing, like kernel interpolation, is to include information from the opposite parity fields. In the case that you are not using any form of motion-adaptation, this improves vertical resolution in stationary areas over using interpolation based solely on pixels from the current field. However, in moving areas you'll be averaging unrelated pixels and end up with a "ghosting" effect.

In the case of a motion-adaptive deinterlacer, you are already detecting stationary areas and weaving... so any place that you would apply the blending you already know is moving (except for incorrect detections). The same argument can be made for kernel interpolation. It includes information from fields of the opposite parity, which helps to improve resolution in stationary areas but creates "ghosting" in moving areas. The difference is that kernel interpolation doesn't average the other field in, but uses it for a sharpening effect (sort of like a [-1 2 -1] kernel). Therefore, it wont produce ghosting in flat areas like blending will, but it will produce ghosting around lines and edges in the opposite parity field. Generally, the effect is much less noticeable and ugly than blend deinterlacing, and is worth the added vertical resolution in stationary areas that are incorrectly detected as moving. Of course, some videos are naturally blurry and the ghosting creating by blend deinterlacing may not that objectionable.

Personally, I don't think blend deinterlacing has much place in TDeint, but it was requested so I added it :). Adding more complicated blending modes (sort of like alignfield's modes 2 or 3) could be interesting, but IMHO they would only really be useful without motion-adaptation.

[Terranigma]

Adding more complicated blending modes (sort of like alignfield's modes 2 or 3) could be interesting, but IMHO they would only really be useful without motion-adaptation.
Well could you perhaps add in a simple blending deinterlacer like blendfields(), one that works in YV12?

[tritical]

tdeint(type=4,mthreshL=0,mthreshC=0)

or

blur(0,1)

blur wont handle the first line or last line exactly the same, aside from that it is identical.


On another note about more complicated blurring kernels... taking the traditional blur deinterlacing, centering it on each field, generating the missing field pixel values by averaging pixels from the prev/next fields and then doing the [1 2 1] vertical blur has the added benefit of removing rainbowing/dot crawl in stationary areas. I'll probably go ahead and add that in the next release... it's basically alignfields(mode=3) but without the horizontal blurring.

[Terranigma]

thanks for pointing that out above. Then how about this: how about adding in a way we could use a custom sharpening filter (preferably tunsharpen) for deinterlaced frames.

perhaps something like this?
tdeint(full=false,slow=0,expand=0,sharp=true, sharpf="Tunfilter(62,10,60,0,0,256,3)",cthresh=3,ap=2,mthreshl=0,mthreshc=0,blockx=16,blocky=16,mi=64,type=4,
ovr="C:\Video.txt",ovrdefault=1)

to add sharpness back to the blended frames. :)
This is to speed things up, because I'd use ApplyRange(frame,frame,"tunsharp",62,10,60,0,0,256,3)
numerous times.
Just a suggestion.

[Didée]

how about adding in a way we could use a custom sharpening filter [..snip..] to add sharpness back to the blended frames. :)

Anyone ever noticed Vinverse (http://forum.doom9.org/showthread.php?p=841641#post841641)? It's just this: Make a small-range blur. Then, of this make an inverse blur at a wider range (speak: USM), /w configurable strength. Manipulate the result so that the 2nd one isn't allowed to add (remove) more than the 1st one previously did remove (add).
Compared to the ease of operation, the outcome is valuable. Try. One might say, it seems almost like a plugin function candidate. ;)

[tritical]

Would something like this work?

mpeg2source()
tdeint()
t1 = last.sharpener()
t2 = last.possiblysomeotherfunctionornothing()
tswitch(last,t1,t2)

where tswitch could read a hint from tdeint and then deliver frames from t1 or t2 based on whether the frame was deinterlaced or not. I think this would be more powerful and it would be slightly easier to implement.

[Terranigma]

Would something like this work?

mpeg2source()
tdeint()
t1 = last.sharpener()
t2 = last.possiblysomeotherfunctionornothing()
tswitch(last,t1,t2)

where tswitch could read a hint from tdeint and then deliver frames from t1 or t2 based on whether the frame was deinterlaced or not. I think this would be more powerful and it would be slightly easier to implement.

Yes that'd be great :cool: