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.

 Doom9's Forum TDeint and TIVTC
 User Name Remember Me? Password
 Register FAQ Calendar Search Today's Posts Mark Forums Read

 Thread Tools Search this Thread Display Modes
 27th March 2007, 04:38 #961  |  Link tritical Registered User   Join Date: Dec 2003 Location: MO, US Posts: 999 I might add the smart thresholding idea to TDeint. When you talk about the min/max of the neighborhood do you mean within the same field or both fields? say the x's are the top field pixels, the o's are the bottom field pixels, and we're trying to create the missing pixel 'c'. The neighborhood for determining the min/max for the motion threshold for 'c' would consist of which pixels? Code: ``` frame 0 frame 1 frame 2 xxxxx xxxxx xxxxx ooooo ooooo ooooo xxxxx xxxxx xxxxx ooooo c ooooo ooooo xxxxx xxxxx xxxxx ooooo ooooo ooooo xxxxx xxxxx xxxxx``` Maybe you could just copy the above diagram and indicate the needed pixels by making them bold. I was thinking it would be the 3 x's above and below 'c', but want to make sure. EDIT: I've been looking at this a little more and I don't quite understand why the threshold is based on the range (max-min) of the neighborhood. Let's say we have the following 9 pixel neighborhood from a single field: abc def ghi if we allow 1/4 pel motion for pixel 'e' and assume linear interpolation will give an accurate result for this motion. Then the possible values for the new 'e', assuming only vertical or horizontal motion for the moment, would be: 0.75*e+0.25*b 0.75*e+0.25*f 0.75*e+0.25*h 0.75*e+0.25*d Which would mean the threshold for 'e' should be the max of: abs(e-(0.75*e+0.25*b)) abs(e-(0.75*e+0.25*f)) abs(e-(0.75*e+0.25*h)) abs(e-(0.75*e+0.25*d)) i.e. max(abs(e-b),abs(e-h),abs(e-d),abs(e-f))*0.25 and for half pixel motion it would be: max(abs(e-b),abs(e-h),abs(e-d),abs(e-f))*0.5 That reasoning can then be extended to simultaneous motion in both vertical/horizontal directions. Last edited by tritical; 27th March 2007 at 20:46.
31st March 2007, 16:59   #962  |  Link
Didée
Registered User

Join Date: Apr 2002
Location: Germany
Posts: 5,390
First of all, generally: I don't claim that things should be done in exactly the way as they're done in MCBob; heaven forbid. In MCBob it's a rough compromise for speed's sake, because some things are just too inefficient when done by limited means of scripting.

What I want is to raise the general idea, because it seems quite feasable. If we have an idea of the local detail level - and that "idea" is rather easy to get by spatial evaluation -, then the allowed range for pixel variance can be derived from it. After thinking a little over it, making the thresholds dependend on the present local variance seems much more logical to me, compared to simply allow "this_fixed_value" for just everything ...

Specifically:

Quote:
 The neighborhood for determining the min/max for the motion threshold for 'c' would consist of which pixels? ... I was thinking it would be the 3 x's above and below 'c', but want to make sure.
Hereby ensured.

Quote:
 I've been looking at this a little more and I don't quite understand why the threshold is based on the range (max-min) of the neighborhood.
Using the maximum difference to the center pixel (like you suggested) theoretically is more precise. I used local min/max for two-andahalf reasons:

a) it was much faster. min/max I get with mt_lutxy(mt_inpand,mt_expand). for max-diff I'd need mt_lutxy(mt_lut_xy(clip,clip.mt_inpand),mt_lutxy(clip,clip.mt_expand)).

b) the center "doesn't exist" yet. The center is the pixel we want to construct.
Therefore: calculating the maximum difference of the neighborhood to the interpolated-from-the-neighborhood center value, in the end is the same as taking min/max of the neighborhood, and divide by 2.

c) the "double sized" value of min/max is levelled out trivially: if we want to allow 1/4 pel motion as being static, this means 1/4 pel between neighbored top/bottom fields. But the field motion check is done between same-parity fields, i.e. the doubled distance. So, to allow 1/4 pel between two directly neighbored fields, the motion check has to allow 1/2 pel between same-parity fields ... that's the point where the "bigger" result of min/max gets levelled out. (That's not fully exact science, sure ... but after trying, it seemed to suffice.)

Somehow, talking about it seems to make it more complicated than it really is ...
__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)

 3rd April 2007, 15:23 #965  |  Link Terranigma *Space Reserved*     Join Date: May 2006 Posts: 953 You and Didée makes this all seem like jibber-jabber. I'll give the new mmask a try. Thanks for the .dll and thorough explaination.
 3rd April 2007, 23:12 #966  |  Link tritical Registered User   Join Date: Dec 2003 Location: MO, US Posts: 999 I noticed two bugs in buildMM() that would cause it not to weave pixels when it should have. I updated mmask.dll (same link as above). I also changed the default for 'length' in buildMM() to 10. mmask() was also changed so that instead of requiring diff < min(cthresh,othresh) it's now diff <= min(cthresh,othresh) and the default for 'minthresh' was changed to 4 (was 5 previously).
 4th April 2007, 23:50 #967  |  Link ChiDragon Registered User     Join Date: Sep 2005 Location: Vancouver Posts: 610 Cool, if I set length=12 with this mmask thing it fixes a short sequence that causes huge artifacting normally. I guess that's not really a test of the new thresholding though? I'm guessing if TDeint by itself could be set to 12-field check it would also be fine on these frames (but then I don't really understand most of this discussion).
 5th April 2007, 05:24 #969  |  Link ChiDragon Registered User     Join Date: Sep 2005 Location: Vancouver Posts: 610 I uploaded the clip.
 5th April 2007, 07:24 #970  |  Link tritical Registered User   Join Date: Dec 2003 Location: MO, US Posts: 999 @ChiDragon Thanks . @All I updated mmask.dll again, only changes were a few optimizations. Atm, using tdeint w/ createMM()+buildMM() is about 3x slower for me than using tdeint w/ its internal motion-masking. It can probably be sped up some more, but considering it's doing a 10 field check (by default) vs tdeint's 5 field check and is using per-pixel adaptive thresholding, 3x slower seems pretty reasonable.
 5th April 2007, 14:02 #971  |  Link Adub Fighting spam with a fish     Join Date: Sep 2005 Posts: 2,685 Well, it looks like I might have to start checking this out. Thanks alot for the new filter Tritical! __________________ FAQs:Bond's AVC/H.264 FAQ Site:Adubvideo
 6th April 2007, 19:30 #972  |  Link tritical Registered User   Join Date: Dec 2003 Location: MO, US Posts: 999 Updated mmask.dll again. Changes were all to mthresh(). 'type' now has options 4 and 5, which use 4 and 8 neighbors respectively, but use the range (max-min) of the neighborhood instead of diff to the center pixel. I also added four new parameters: mtqL, mthL, mtqC, mthC which can be used to set hard thresholds instead of using adaptive thresholds. mtqL sets the quarter pel threshold for luma, mthL sets the half pel threshold for luma, mtqC/mthC are the same but for chroma. If these parameters are set to -1 (the default) then an adaptive threshold is used, if they are between 0 and 255 inclusive then the value of the parameter is used as the threshold for every pixel. The above changes to mthresh() were also included in createMM(), whose type parameter can be set to 4 or 5, and which now has mtqL, mthL, mtqC, and mthC parameters. I'm planning to create one filter called tMM() that does everything internally so that deinterlacing would simply be: tdeint(order=xx,mode=xx,field=xx,emask=tMM(order=xx,mode=xx,field=xx))
 6th April 2007, 23:56 #973  |  Link tritical Registered User   Join Date: Dec 2003 Location: MO, US Posts: 999 Didn't take long... TMM.zip. It includes a readme and source code. Basic usage examples: bobbing, tff: tdeint(mode=1,order=1,emask=TMM(mode=1,order=1)) bobbing, bff: tdeint(mode=1,order=0,emask=TMM(mode=1,order=0)) same rate, keep top field, tff: tdeint(order=1,field=1,emask=TMM(order=1,field=1)) same rate, keep bot field, bff: tdeint(order=0,field=0,emask=TMM(order=0,field=0))
 6th April 2007, 23:58 #974  |  Link Terranigma *Space Reserved*     Join Date: May 2006 Posts: 953 I'll try this out, thanks. Hey, any news on what we've discussed via pm? Update: Very nice work tritical. Would it be possible to use tmm with, lets say, bob() to make it adaptive? If so, how would I go about doing that? By the way, you forgot to add another bracket at the end of the second example =P tdeint(order=0,field=1,emask=TMM(order=0,field=1) Last edited by Terranigma; 7th April 2007 at 00:15. Reason: To Give Credit :)
7th April 2007, 00:28   #975  |  Link
tritical
Registered User

Join Date: Dec 2003
Location: MO, US
Posts: 999
I've told about 5 people that I'd look into something for them and haven't gotten around to any of it due to working on this motion-mask thing. Anyways, I did download tprivtc earlier in the week to try and fix the problems you mentioned, but it turns out that it uses fstream.h functions for doing the file/text stuff so I couldn't get it to compile straight away with vs.net 2003 (which doesn't have fstream.h and switching to iostream+fstream didn't fix everything) so I put it away for later. I'll probably mess with it tommorrow.

Quote:
 Very nice work tritical. Would it be possible to use tmm with, lets say, bob() to make it adaptive? If so, how would I go about doing that?
Not sure in what fashion you mean, but the main problem with using it in conjunction with bob() via some type of masking would be that bob shifts both fields. If you just want cubic interpolation with motion-adaptation then TMM w/ tdeint(mode=1,type=0) would work.

thanks for the heads up on the typo in the read me.

Last edited by tritical; 7th April 2007 at 00:31.

7th April 2007, 00:34   #976  |  Link
Terranigma
*Space Reserved*

Join Date: May 2006
Posts: 953
Quote:
 Originally Posted by tritical Not sure in what fashion you mean, but the main problem with using it in conjunction with bob() via some type of masking would be that bob shifts both fields. If you just want cubic interpolation with motion-adaptation then TMM w/ tdeint(mode=1,type=0) would work.
That's what I meant. I'll try your suggestion there instead.

7th April 2007, 01:18   #977  |  Link
Chainmax
Huh?

Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
Quote:
 Originally Posted by tritical @ChiDragon Thanks . @All I updated mmask.dll again, only changes were a few optimizations. Atm, using tdeint w/ createMM()+buildMM() is about 3x slower for me than using tdeint w/ its internal motion-masking. It can probably be sped up some more, but considering it's doing a 10 field check (by default) vs tdeint's 5 field check and is using per-pixel adaptive thresholding, 3x slower seems pretty reasonable.
Only three times slower? That's still ~20% faster than SecureBob/Old TDeint+EEDI2, ~220% faster than MVBob and ~310% faster than MCBob! tritical, you're a genius .
__________________
Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it.

 7th April 2007, 03:18 #978  |  Link foxyshadis ангел смерти     Join Date: Nov 2004 Location: Lost Posts: 9,356 You might still want to use eedi2 with tdeint's edeint parameter though, which will slow it down a bit more. Using emask+edeint, there's hardly any reason to keep tdeint around though. __________________ There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. ~ Ed Howdershelt
 7th April 2007, 16:11 #979  |  Link Chainmax Huh?     Join Date: Sep 2003 Location: Uruguay Posts: 3,103 Well, like I said, this is still ~20% faster than Old TDeint+EEDI2. Besides, someone here said that using EEDI2 with the edeint parameter yielded a softer picture than plain TDeint. Not to mention that EEDI2 has artifacts of its own. __________________ Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it.
 7th April 2007, 17:39 #980  |  Link canuckerfan Registered User   Join Date: Jul 2005 Posts: 318 so are we better off leaving out EEDI2 or is it best left to our discretion?

 Tags tdeint, tivtc

 Thread Tools Search this Thread Search this Thread: Advanced Search Display Modes Linear Mode

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is Off Forum Rules
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home Announcements and Chat     General Discussion     News     Forum / Site Suggestions & Help General     Decrypting     Newbies     DVD2AVI / DGIndex     Audio encoding     Subtitles     Linux, Mac OS X, & Co Capturing and Editing Video     Avisynth Usage     Avisynth Development     VapourSynth     Capturing Video     DV     HDTV / DVB / TiVo     NLE - Non Linear Editing     VirtualDub, VDubMod & AviDemux     New and alternative a/v containers Video Encoding     (Auto) Gordian Knot     MPEG-4 ASP     MPEG-4 Encoder GUIs     MPEG-4 AVC / H.264     High Efficiency Video Coding (HEVC)     New and alternative video codecs     MPEG-2 Encoding (HD) DVD, Blu-ray & (S)VCD     One click suites for DVD backup and DVD creation     DVD Rebuilder     (HD) DVD & Blu-ray authoring     Advanced authoring     IFO/VOB Editors     DVD burning Hardware & Software     Software players     Hardware players     PC Hard & Software Programming and Hacking     Development     Translations

All times are GMT +1. The time now is 00:10.

 Doom9.org - Archive - Top