PDA

View Full Version : Decomb 5.0.0 beta 15: Fix for crashing problem


Pages : [1] 2

Guest
29th May 2003, 05:11
A beta of New Generation Decomb is now available for your testing. Please carefully read the accompanying tutorial and reference manual as a lot of things have changed in Telecide(). FieldDeinterlace() and Decimate() are unchanged.

Get the beta here:

http://shelob.mordor.net/dgraft/decomb/decomb500b15.zip

As always, feedback will be greatly appreciated.

HomiE FR
29th May 2003, 06:24
Thanks neuron2. :)

I'll give it a try and I'll come back when I have some results.

EDIT :
I've tried Decomb 5.0.0 beta 1 with some anime source that I had, reading your tutorial to set the parameters. But I have a question : is the possibility to match the current frame with the next one gone ? I ask this because new generation Decomb has problems where the good old Decomb 4.10 beta 2 chooses to match the frame with the next one. And with show=true, Decomb 5.0.0 beta 1 doesn't show any information about "n" anymore, just about "c" and "p".

I've taken 2 screenshots, the first with Decomb 4.10 beta 2 which chooses to match the frame with the next one, and the second with Decomb 5.0.0 beta 1 which chooses to match with the previous one (it seems it doesn't care about next frame).
Sorry but the images are PNGs which are about 400 kb.
Decomb 4.10 beta 2 (http://perso.wanadoo.fr/homie.fr/decomb_410b2.png)
Decomb 5.0.0 beta 1 (http://perso.wanadoo.fr/homie.fr/decomb_500b1.png)

I hope you'll understand my problem. It seems obvious to me that Decomb 4.10 beta 2 performs better than Decomb 5.0.0 beta 1 on this source (I have this problem very often on the anime source tested).

The function calls were :
- Decomb 4.10 beta 2 : Telecide(post=false,blend=true)
- Decomb 5.0.0 beta 1 : Telecide(order=1,post=0,show=true)

It doesn't perform any better if I use guide=1 (I have some 3:2 pulldowns on this source). I have chosen order=1 accordingly to the test suggested in your Decomb 5.0.0 tutorial.

cipher
29th May 2003, 08:13
Damn great, DG!!!I've been waiting for this since I read your journal.
Infinite thanks!!
I'm gonna give it a shot, right away!:D

=======
Edit: So far it's just great!
I assume "vthresh" is similar to the "threshold" in v4. right? It seems to me that vthresh becomes more accurate now!(Maybe because it has more divisions than "threshold"?:)).
Edit in this edit: Beyond that, what previously version4 had to decide as combed frames (even at a very low threshold) now have been "decombed" as clean frames, progressive but no interlaced, and in my eyes they are indeed clean now:D

But one thing, DG, is "dthreshold" actually working? When I wasn't touching it, it was fine; but when I specified dthreshold=7 in Telecide(), vdmod reported "...Telecide does not have a named argument 'dthreshold'..."
My script was this:
LoadPlugin("MPEG2Dec3.dll")
LoadPlugin("Decomb.dll")
mpeg2source("01.d2v",cpu=4)
ConvertToYUY2()
Telecide(order=1,guide=1,vthresh=13,dthreshold=7,post=2,show=true)
Decimate(cycle=5,quality=3)

By the way, my material is a normal movie(well, an mtv), not an anime.
=======

~~~~~~~
2nd Edit:
Comfirmed by my friend, "dthreshold" didn't work. Instead, he found out that "dthresh" worked(at least no error reported by vdmod). The manual should've been updated now.:)

wotef
29th May 2003, 11:50
hi some feedback and questions

why is field dominance/parity now important?
is it working correctly? on some bottom-field PAL material i have, telecide(order=0) seems to leave more combed frames than telecide(order=1)

also, is telecide(post=1) meant to display some metrics? i don't see any

Guest
29th May 2003, 13:29
@cipher

1. Yes, dthreshold is now dthresh. It's mentioned in the Tutorial but I forgot to update the reference manual. Thank you for pointing it out.

@wotef

vmetric is displayed only when post != 0. When post=1 vmetric is calculated and displayed but not used.

Are you reading the journal at my web site? It describes why field order is now important. Basic summary: it's faster and less error-prone to do 2 comparisons rather than 3. Did you verify the field order using the technique I described in the tutorial? If so, and you still think there is a problem, please make a source clip available for my inspection.

@HomiE FR

Yes. The forward match is gone. At some scene changes you may generate a combed frame that will be deinterlaced. Is this occurring for you only at some scene changes? If not, please make a source clip available for inspection. I personally do not see this as a big deal as long as it is limited to some scene changes and since postprocessing is now so fast.

HomiE FR
29th May 2003, 14:02
@neuron2 : These problems don't only show up on scene changes, but all over the source (sometimes it's really visible, sometimes not) and postprocessing (deinterlacing?) can't do anything good to these frames. I've tried to lower the vthresh so that these frames are postprocessed, but it is not any better...
And I haven't any knowledge on deinterlacing, but the forward match wasn't supposed to be useful elsewhere than only some scene changes ? On the source I'm talking about, the forward match "n" was used very often ! And now the frames where "n" was used with Decomb 4 have the problems I've described above (maybe not all, but many since I can see the problem on different scenes).

I'm ready to give you a part of the vobs I'm playing with (a Z1 anime) but I don't know how you want the source clip. Do I have to cut the vob and give you a part, ar do I just compress the part unprocessed with MPEG-4 (XviD) @ quantizer 2 ? If you want a vob file, I don't know how to cut easily a vob where I want to (Google didn't find what I was looking for) so I will need your advice.

Thanks for checking my problem ! :)

Guest
29th May 2003, 14:18
@Homie FR

It's really important to get me this clip!

I need a good-sized VOB fragment. Use VOB splitter or other tool, available on doom9 download page.

Thank you!

wotef
29th May 2003, 14:19
didn't know about your journal til your reply - look forward to reading it!

i did some more testing on 10 random/different clips (all verified bottom-field dominant) and take back what i said

on 8 of these clips, specifying order=0 gave better frames

on the other 2 clips, there was no difference in quality between specifying either order (both left some residual combing at default settings) - and for these two, tomsmocomp seemed to fare better than telecide - presumably these were "true video" clips

Guest
29th May 2003, 14:24
@wotef

I can only comment on specific clips if you make them available for inspection.

You can tell if a clip is video by doing separatefields and then stepping through it. If there is motion only on every other field (or every second or third for 3:2 pulldown), then it is progressive. If there is motion on successive fields, it is video.

wotef
29th May 2003, 14:28
ah, thanks, ok, that helps a lot, yes they were both video

killingspree
29th May 2003, 15:10
Originally posted by neuron2
FieldDeinterlace() and Decimate() are unchanged.


so does this mean there is no difference in those two to their predecessors in v4? or did you just not change any parameteres?

thanks for the great new filters, going to do some testing now (:

steVe

JuanC
29th May 2003, 15:55
Originally posted by neuron2
... At some scene changes you may generate a combed frame that will be deinterlaced. Is this occurring for you only at some scene changes? For me it is ocurring at not some but almost every scene change. Also, I get many interlaced (and "out of pattern") frames in static scenes where only small objects/parts are moving...

Tweaking GThresh: The show / debug options output include two metrics: p and c. I understand they are Previous and Current. Am I right? It would then be great to see in the show/debug output the metrics for Predicted and Calculated. I've been using different values for Gthresh: 0, 10, 100, even 1000, and haven't been able to undestand the difference in behavior.

In latest betas of Telecide v4.10 I was using mm=2: matching mode considering only Current and Next. In general it was giving me better matches for my TV captures. Will there be an option to do something like that in Decomb 5.xx?

Great improvements! Thanks again, :J

HomiE FR
29th May 2003, 15:59
@neuron2 : I've cut a part of a vob where the artifacts are visible. It's about 72 MB. But I don't know how I can give it to you. We can do it through IRC I guess, or through ICQ or anything you want. My connection is a DSL line, so 128 kbps UP (16 KB per second).

My ICQ number is 76019744 if you want to contact me directly.

Guest
29th May 2003, 16:21
@killingspree

They are identical to the previous versions. Is that clearer than unchanged? :)

@JuanC

You have to provide a source clip if you want me to look at any issue.

P = Previous, C = Current

I will add display of the predicted and calculated metrics. Gthresh sets how big of a difference between those two can exist without preventing a pattern override. Set gthresh=0 and all overrides will be prevented. Set it to 100 and none will be prevented.

Setting mm=2 in old Telecide is exactly the same thing as not doing the backward match operation, i.e., it makes Telecide field order dependent. If you are having difficulty with a specific clip in this regard, please make the source clip available for inspection.

@Homie FR

I will send you FTP access details in a PM.

JuanC
29th May 2003, 18:39
Originally posted by neuron2
Setting mm=2 in old Telecide is exactly the same thing as not doing the backward match operation, i.e., it makes Telecide field order dependent. If you are having difficulty with a specific clip in this regard, please make the source clip available for inspection. As soon as I get home back from work I will chop a relevant part of one of my unprocessed mpeg2 tv captures, about 10-20MB, and I would also appreciate if you send me a PM with details on temporary FTP access. (I´ve got a slow cable connection)

Thanks, :J

Guest
29th May 2003, 18:57
It's not my FTP site and I have to go ask for permission every time.

Yours is small enough to break into two pieces using WinRAR and mail to me. Please do that and make each piece less than 10 Meg. Also, please retain the pieces until I acknowledge getting them all. Thank you. neuron2@attbi.com

HomiE FR
29th May 2003, 19:45
@neuron2 : I just sent you a PM. The vob file should be ok. Thanks for trying to locate the problem, I'll keep checking this thread for news ! :)

DoW
29th May 2003, 19:50
I was wondering about the handling of fade in/out in the new decomb, so I tested it on "Zone of the Enders: Idolo" and noticed that while the frame was mostly black with the white intro credits fading in, the vmetric was very small (started at vmetric=0.000000), and slowly increased as the credits bacame brighter (up to vmetric=31.xxxxx). The effect was that even though the credits had combing, telecide wouldn't detect them as combed, but when they reached their full brightness, it would detect them as combed, event though they were not.


Telecide(order=1, guide=1, vthresh=33, post=2, blend=true, chroma=true, show=true)
Decimate(cycle=5, mode=2, quality=3)


Not sure if this is a special case or what have you, but I figured Id point it out and be on the safe side. If Im wrong, please feel free to bring out the tar and feathers.

Guest
29th May 2003, 22:54
Originally posted by DoW
Not sure if this is a special case or what have you, but I figured Id point it out and be on the safe side. If Im wrong, please feel free to bring out the tar and feathers. Does Decomb 4 handle it any better?

killingspree
29th May 2003, 23:05
Originally posted by neuron2
@killingspree

They are identical to the previous versions. Is that clearer than unchanged? :)

oh well... thanks for the info... i guess /me was stupid once again. i just checked the new version on some captured pal material and it worked well.

thanks for your work
steVe

DoW
29th May 2003, 23:49
@neuron2:
Yeah, it handles it better. Using Decomb 4.10b2, I had to use threshold=4 to detect the combing in the intro credits. The vmetrics for the credits are high in comparison to the rest of the movie in that, the static credits (non-combed) have a vmetric of 31ish, while in the rest of the movie, the highest vmetric that a non-combed frame has is 22. Im kinda busy, so later tonight Im gonna look though ZoE some more and see if I notice anything else.

Shayne
30th May 2003, 02:44
Would just like to say excellent Tutorial and excellent results. Great thanks for all that hard work.

Guest
30th May 2003, 03:26
@Shayne

Thank you for your fedback.

@DoW

Can I get the unprocessed source clip of the fade?

@HomiE FR

I cannot duplicate your isses, especially that strange PNG image. I use this script and everything looks just wonderful with the VOB you sent me:

telecide(order=1,guide=1,post=2,vthresh=75)
decimate()

Please try beta 2 with post=2; perhaps the issue with video passthrough was biting you. Bear in mind that clip has some frames with detail that really looks like combing! You need a relatively high vthresh to handle that.

@killingspree

I didn't mean to imply you are stupid! :o
You've been very helpful to me in the past and I always appreciate your feedback.

@all

I have removed beta 1 as beta 2 is coming shortly.

Guest
30th May 2003, 04:06
I have released beta 2. See the link at the first post in the thread.

The post parameter has changed:

-----
post (0-5, default 2) controls whether and how Telecide performs postprocessing to clean up frames that come through the field-matching still combed:

post=0: Use this to totally disable postprocessing.

post=1: Use this to enable the metrics calculation and to display vmetric but not perform deinterlacing.

post=2: Use this to enable deinterlacing. Note that in this mode, the field matching occurs normally and the best matched frame is deinterlaced and delivered.

post=3: This is the same as post=2 except that the deinterlacing motion map is displayed in blue on the deinterlaced frames.

post=4: This is the same as post=2 except that instead of using the best field match for the frame, the original frame is deinterlaced. You would use this to pass video sequences through when you have a hybrid clip.

post=5: This is the same as post=4 except that the deinterlacing motion map is displayed in blue on the deinterlaced frames.
-----

Previously post=4 behavior was implemented by default. Now it has been divided into post=2 and post=4 (for hybrid clips). post=2 is the way Decomb classic works.

DoW
30th May 2003, 04:52
I split off a bit of the VOB (~56MB) that has the intro credits in it, plus a few frames that generate artifacts similar to what homie FR was describing earlier. I can toss it on my FTP (~16k/sec UL) if you want, PM me to let me know how you want me to get it to you.

EDIT:
b2 fixed on issue I noticed with a frame selection.

Guest
30th May 2003, 04:59
I'm wondering if the problem you and HomiE FR are reporting is coming from doing random timeline movements. Does it happen if you just play the clip straight through from the beginning, or just after moving around on the timeline?

DoW
30th May 2003, 05:05
-> forwarding

Guest
30th May 2003, 05:07
I've now duplicated the HomiE FR problem. It follows timeline navigation. I am withdrawing the beta for repairs. Please stand by.

HomiE FR
30th May 2003, 06:19
@neuron2 : Thanks, thanks, thanks. I'm standing by, no problem ! :) I was a bit "disappointed" (maybe not the right word, since it was actually working right) that you didn't see the arfifacts I get, but since you found them and understood where they come from, that's great (and fast also).

Guest
30th May 2003, 13:05
@HomiE FR

You're my man, HomiE!

I found the bug. I'm so stupid. I'll release a new beta this weekend. I want to also add a great new feature that will fix scene changes. If we detect a frame as combed, try the forward match before giving up! This gives us the benefit of (most of the time) doing only the one-way match but without messing up some scene changes.

I also want to look at the clips submitted by DoW and JuanC.

@all

I must say, you dom9'ers really are "the cat's meow" when it comes to testing.

killingspree
30th May 2003, 13:17
Originally posted by neuron2

@killingspree

I didn't mean to imply you are stupid! :o
You've been very helpful to me in the past and I always appreciate your feedback.

oops i guess i sounded a bit harsh (:
i wasn't offended in anyway!

oh and now i'm looking forward to the new release... i somehow missed beta2 so yes... i'll see what is coming up next...

off to do some other testing :-P

steVe

PS: sorry OT: @neuron2: have you seen/read the new and improved version of the capture guide?

Guest
30th May 2003, 16:25
Originally posted by killingspree
PS: sorry OT: @neuron2: have you seen/read the new and improved version of the capture guide? Is that the one that you translated and I proofread? :)

killingspree
30th May 2003, 16:28
" Is that the one that you translated and I proofread? "
that was the basis... but we released the new version (2.0) of the guide a few days ago. we added the complete NTSC part, postprocessing with avisynth and gknot, logo removal and many many more things (:
partly you'll hardly recognise it again!

steVe

HomiE FR
30th May 2003, 18:34
@neuron2 : :) I'm always ready for some testing, and when I mean that you're the one to thank I mean it. That's you who give us this great tool (I wouldn't be able to code one line of C++) ! I'm really happy that you found the problem and if you can even improve the scene changes with forward match, I think New Generation Decomb will beat up my anime source easily ! ;)
Standing by for your new version...

EDIT : bad typo...

N_F
31st May 2003, 00:25
Great work Donald! I haven't had any good material to really test it on, but from what I've read it seems really good. One thing though:

Have you considered how this top/bottom field thing one needs to examine will affect automazation programs like Gordian Knot?

Guest
31st May 2003, 01:04
Originally posted by N_F
Great work Donald! I haven't had any good material to really test it on, but from what I've read it seems really good.Be sure to use the beta 3 I am now posting!

Have you considered how this top/bottom field thing one needs to examine will affect automization programs like Gordian Knot? Sure. They will either require the user to specify the field order, or they will continue to use Decomb classic.

Guest
31st May 2003, 01:09
Decomb 5.0.0 beta 3 is now available. Please see the first post in the thread for the link.

It fixes the matching bug reported by HomiE FR and it will now try the forward match when a frame is still combed after current/backward matching and pattern guidance, thereby fixing the scene change problem. That only works when post != 0, but postprocessing is so blazingly fast that there's no reason to turn it off.

This kicks butt on HomiE's VOB:

telecide(order=1,guide=1,post=2,vthresh=75)
decimate()

I will now have a look at the clips sent by DoW and JuanC.

Note that I am still not fully happy with the pattern guidance and anticipate improvements there. But so far I think the field matching and postprocessing are really looking good, and FAST!

Guest
31st May 2003, 01:35
@JuanC

Your ducks clip is handled just fine by beta 3 with this:

Telecide(order=1,guide=1,post=2)

And if you set guide=0, your Friends clip looks fine.

JuanC
31st May 2003, 02:32
Originally posted by neuron2
@JuanC

Your ducks clip is handled just fine by beta 3 with this:

Telecide(order=1,guide=1,post=2)

And if you set guide=0, your Friends clip looks fine. Yes, It's a whole lot better now! :cool: My friends clip got almost zero interlaced frames now, better and faster!, than with previous versions of Telecide.

However I could use any advice on how to deal with the almost static scenes where only small parts are moving: if you take a look at frames from 88 to the end, on the clip with the ducks, you’ll see that it’s telecined, following the telecine pattern, but all frames are detected as progressive, “out-of-pattern” and thus passed intact. With the betas of Telecide 4.10 if I use guide=0,mm=2, they are correctly matched… Well, it misses just a couple o frames.

Again, thanks for your great, generous work. :) Juan

Guest
31st May 2003, 03:05
@JuanC

Almost zero is not acceptable. :)

Two things are happening. First, your clip is a noisy capture. If you set nt=50, it gets fixed. This script looks great:

Telecide(order=1,guide=1,post=2,nt=50)
Decimate()

But there is also the pattern guidance issue. I wrote above: "Note that I am still not fully happy with the pattern guidance and anticipate improvements there."

For now, nt=50 is your ticket. I'm wondering if I should have some noise tolerance by default. Decomb classic had some nt by default; that's why it worked.

Also note that pattern guidance is disabled for the first and last 9 frames of all clips.

Thank you once again for your valuable feedback.

Guest
31st May 2003, 03:50
@DoW

One of my basic philosophies is not to worry about things that cannot be perceived!

If you set vthresh=25, the worst frame is imperceptibly combed when viewed normally. OK, if you stop the clip, zoom in by 2 (which is a no-no for assessing combing!), you can see FAINT combing. No human being would ever notice it playing normally.

So others can see my point, here is the WORST frame in the fade; subsequent ones are deinterlaced. And realize that the fade is very quick; there's no way anyone will perceive any combing.

http://shelob.mordor.net/dgraft/misc/fade.jpg

If you handled that by using threshold=4 with Decomb classic, then you obviously ruined the rest of the movie.

DoW
31st May 2003, 03:50
Hmmm... wonder about ZoE. Might try a little nt there as well to see what happens. ZoE is such a weird source, I can see why most people hesitate to work on it. Havent gotten a chance to try 5.00b3 yet, thats on my list of things to do tommorow. Thanks for all your effort neuron2.

EDIT:
Actually, I used trim to do FieldDI on only that section, so it applied to only the credits (/me grumbles about ApplyRange sillyness, still working on that).

Guest
31st May 2003, 04:02
Originally posted by DoW
Actually, I used trim to do FieldDI on only that section, so it applied to only the credits (/me grumbles about ApplyRange sillyness, still working on that). That makes more sense, but I still say why bother? Anyway, you can force it much more easily with a Telecide override file.

JuanC
31st May 2003, 04:15
Originally posted by neuron2
... Two things are happening. First, your clip is a noisy capture. If you set nt=50, it gets fixed. This script looks great:

Telecide(order=1,guide=1,post=2,nt=50)
Decimate() Wow! This is just great! it works wonders!!!

Thanks again, Juan

HomiE FR
31st May 2003, 07:27
@neuron2 : I would like to apologize for something : my bug reports were NOT totally justified... :( The new beta version improved things, but when I tried again this morning I saw one more time these ugly lines when there was high motion (the artifacts that you didn't see first). Now I understand why you didn't see as much artifacts as I did : my brand new Avisynth 2.5.1 RC4 from sh0dan's page had a flawed ConvertToYUY2()... :( When you told in your last post that the new beta worked well with my clip, I did not question your statement and asked myself how things could go wrong with such a simple script. And ConvertToYUY2() was the only possible guilt. I used then YV12toYUY2() from MPEG2Dec3 1.06 from Nic and these artifacts went away suddenly (I checked a few times to be sure).

I'm sorry for having made a "false" bug report, but since it helped in some way (because of other artifacts in this clip) to improve New Generation Decomb I'm not so ashamed ! :) Moreover I think the scene changes look better now.

Thanks again neuron2, the clip is just perfect now. I'm now able to use Decomb on the full source, be sure that I'll come back if I spot any new problem (even though I'll double check my script and my Avisynth version before I do some bug reports ;) ).

Guest
31st May 2003, 14:38
@all

Beta 4 is released. It fixes a crash when the last frame needs to be deinterlaced. See the first post in the thread for the link.

@HomiE

Are you sure the ConvertToYUY2() is broken? Did you use ConvertToYUY2(interlaced=true) as required? If it is really a bug, have you notified sh0dan? Please advise me about this, as it affects my testing too!

Finally, why not avoid the conversion by using mpeg2dec (instead of mpeg2dec3) until YV12 support is added? You should really do that as it is much faster.

HomiE FR
31st May 2003, 15:06
@neuron2 : Too bad it was my fault. You're right, I had forgotten to put "interlaced=true"... :( I have first notified sh0dan about my "bug", but he told me to put "interlaced=true" just like you. And you are both right, the artifacts that were still there are now gone with "interlaced=true".

But about using MPEG2Dec instead of MPEG2Dec3, I will follow your advice. Thanks.

HomiE

Guest
31st May 2003, 15:14
@HomiE FR

Thank you for the clarification. Your feedback has been very helpful and even your mistakes are instructive and will help others. ;)

@all

There seems to be some confusion about post=2/3 versus post=4/5. Therefore, I have added the following text to the tutorial. I hope it clarifies things for you.

"There is one more important thing to say about postprocessing before we move on. There is a subtle difference between post=2 and post=4 which might affect you. The reference manual describes the differences in detail. Setting post=2 will often avoid making gross frame blends at scene changes, but it can make deinterlaced sequences jerky. Setting post=4 retains the smoothness of deinterlaced sequences, but will make frame blends at all scene changes."

Guest
31st May 2003, 16:55
I've started a FAQ for Decomb 5. Please see the first post in the thread for a link.

I will appreciate receiving suggestions for FAQ additions.

DoW
31st May 2003, 17:33
Originally posted by neuron2
That makes more sense, but I still say why bother? Anyway, you can force it much more easily with a Telecide override file.
Cause Im a crazy perfectionist (by virture of what I do in real life, 'cause mistakes are B.A.D. in the chem lab (when a chemist makes a mistake, the word 'evacuation' is usually used:eek: ). Seriously, thanks for all the work neuron2. As for the override, Im still kinda trying to learn that.

DoW
1st June 2003, 03:07
I think an addition on the usage of nt might be nice. I know that I'm experimenting with it, but I have no idea what sort of values are way high, low, etc.

Guest
1st June 2003, 03:59
It's already mentioned in the fourth question. Is it not enough?

Guest
1st June 2003, 14:46
I've released beta 5. Please see the first post in the thread for the link.

Pattern guidance has been improved. I'll be starting soon to write an account of pattern guidance at my website journal. It will exlain the issues and challenges, what can reasonably be expected and accomplished, and how Decomb actually performs its pattern guidance.

Executive summary: Pattern guidance is necessarily an approximate heuristic procedure. It can never be perfect. If it is too strong it can do more harm than good. Used in moderation it can improve matching.

Consider this: We have a new frame and the previous 5 are perfectly in lock with a 3:2 pattern. But the current frame blind match choice is out of this pattern. Do we override it? If it's a mismatch due to a small metric difference (due to noise or picture content spoofing the difference detection), we want to override it. If it's an actual pattern change, we don't want to override it. Decomb uses the gthresh mechanism to try to distinguish the cases. There are other things to try, e.g., see if the following frames have the same pattern as the previous 5. If so, then it's more likely that we should override. But no matter what you do, it always comes down to probabilities.

That's just to whet your interest so you'll read my journal. :)

HomiE FR
1st June 2003, 15:00
Yup that's really interesting. :) I'll try now your new beta 5, especially pattern guidance since it seems to be your point of interst for the time being. Thanks.

About the FAQ, I can't see now anything which could be added, I'll come back if I find something.

Guest
1st June 2003, 19:11
HomiE,

One of the scripts you sent me had gthresh=100. Don't do that. Anything higher than 15-20 starts to do more damage than good.

HomiE FR
1st June 2003, 20:00
Sorry neuron2, but I don't remember sending you any scripts. :confused: When am I supposed to have done this ? Maybe I do some tests with Decomb in my sleep but if this is the case I should go to a doctor I guess... :D

Seriously I don't think that I sent you any script, moreover I haven't played yet with gthresh, so I can't have sent you anything with gthresh=100 in it (besides my possible tests during my sleep obviously). :)

But your post made me learn a new thing about Decomb : never put gthresh over 20. If it was 100 I must have been totally asleep ! :)

Guest
1st June 2003, 20:17
Originally posted by HomiE FR
Sorry neuron2, but I don't remember sending you any scripts. :confused:
It seems I too am confused, because I mixed you up with JuanC. Sorry. But to be fair to Juan, I believe he was doing it to isolate a Decomb bug.

@JuanC

Don't use gthresh=100. :)

HomiE FR
1st June 2003, 20:41
No problem, neuron2. Moreover it seems that there is even less combed frames (which were already very few with beta 4) after Telecide. I guess patern guidance is doing its job even better. :) But I need to do some more tests to be sure.

cipher
1st June 2003, 20:44
@DoW

I've been ripping a lota music videos, and fading scenes are very common in mvs, which often drive me crazy, coz I have to set very low thresholds to deal with them, and that certainly is "ruining the rest of the movie".
However, I found that enabling "chroma=true" might be a little useful if we were trying to handle fading scenes better.

Below are two identical scenes from an interlaced fading-out frame, of whose vmetric values one was calculated without taking chroma into account, and the other was set to "chroma=true". You can see, with "chroma=true" the vmetric value increased by about 3(29.3%) in such a fading-out frame, which is good coz we really want a higher vthresh value(or threshold in Decomb classic).
fading.out.interlaced.chroma=false.vmetric=8.853428 (http://photos.gznet.com/photos/1111960/1111960-212RBl6Ko$.jpg)
fading.out.interlaced.chroma=true.vmetric=11.453900 (http://photos.gznet.com/photos/1111960/1111960-SSCHsRZKqH.jpg)

As a basis for comparison, here below are two identical frames from a "normal" scene. The difference in vmetric values between "chroma=false" and "chroma=true" is only 0.26(2.8%)
normal.chroma=false.vmetric=9.208037 (http://photos.gznet.com/photos/1111960/1111960-8FQh6P5aNz.jpg)
normal.chroma=true.vmetric=9.468085 (http://photos.gznet.com/photos/1111960/1111960-MS5vobLNwE.jpg)

That makes sense(edit: hmm...whether calculating vmetric difference in that way makes sense or not still needs validation, but you get the idea:D). Because usually in a frame that is fading out, what changes rapidly is luminance. If this frame is interlaced, the luma difference between two vertically adjacent pixels becomes less than what it should be in a "normal" scene, which telecide() find it hard to detect. But setting "chroma=true", now chroma has been considered, and I think the chroma and hue values of EACH OF these two pixels wouldn't differ too much than their "normal" states, and the vmetric value now becomes closer to a "normal" interlaced scene that has a higher vmetric. So it seems to me that "chroma=true" acts as an offset here to evaluate vmetrics more accurately in such fading scenes.
But, If I remember right, chroma=true was default in previous Decomb classic, but it has been changed to be false in current version. This is what I found in the doc:

It is useful for clips which have a large amount of luma/chroma interference, as might result from a poor comb filter. The interference can cause frames that are not combed to be detected as combed when chroma=true. By setting chroma=false, the effect of the interference can be eliminated.

As in my example above, a vmetric=11.4 even after enabling chroma is still very low(and the combs are really noticable when playback!). In addition, I don't really know if this method is universally effective to handle fading scenes.(ie.we need more tests).So just for curiosity, DG, is it practical to add a sort of switch, when enabling it, Telecide() becomes more sensitive to chroma and/or hue, after it detects a rapid/sudden but differentiable decrease/increse in luminance?(that's what I characterize fading scenes in terms of the three factors of color) :D
Please correct me if I'm wrong, and thanks!:)

gizmotech
1st June 2003, 22:51
Hmm, at this point will work begin on YV12 support?

Just curious. I look forward to seeing how fast it will run in YV12 mode. :)

JuanC
2nd June 2003, 02:04
Originally posted by neuron2
@JuanC

Don't use gthresh=100. :) Thanks, you're right, I used that before in my erlier tests. I don't use it that high anymore. :) :J

BTW, in order to tweak GThresh, It would be great to have the metrics for Predicted / Calculated in the show/ debug options. :J

Guest
2nd June 2003, 03:33
Originally posted by cipher
DG, is it practical to add a sort of switch, when enabling it, Telecide() becomes more sensitive to chroma and/or hue, after it detects a rapid/sudden but differentiable decrease/increse in luminance?(that's what I characterize fading scenes in terms of the three factors of color) I will not consider such changes in the absence of a clip that demonstrates a problem. You are welcome to submit one and I will give it careful attention.

Guest
2nd June 2003, 03:34
Originally posted by gizmotech
Hmm, at this point will work begin on YV12 support? As soon as user feedback indicates that the functionality is stabilized, I will add YV12 support. I hope that will be within days.

gizmotech
2nd June 2003, 03:50
I'm waiting with baited breath as my current tests with the patern matching on 5b4 was FANTASTIC. Handled stuff that 4.1b2 just died horribly on. Now I haven't check b5 yet, however I don't really see how it can get any better.

Once again thanks for the hard work. Greatly appreciated.

GizmoTech

DoW
2nd June 2003, 04:05
@cipher:
I am using chroma=true. I tried adding in nt=20 and it helped a good deal (ZoE has a pretty decent amount of mosquito noise in it) with detection. After some tweaking and using some manual overrides, Im gonna see if any of the frames that cant be handled correctly (because of poor TC in the source) can just be manually decimated out. As with all things, its a matter of tweaking:D.

cipher
2nd June 2003, 05:58
I will not consider such changes in the absence of a clip that demonstrates a problem. You are welcome to submit one and I will give it careful attention.

Yeah, sure! I have posted a vob section here (~12M). It's my FTP so the speed may be slow (Rogers AT&T, upload limit only about 20-22kb/s).
Not only DG, but anyone interested could also download it for inspection; but it would only be available for a couple of days. ;).
Thank you very much!!:)

Here is the vob splited (ftp://doom9:doom9@65.49.49.22/Tests.zip)

@DoW
I am using chroma=true. I tried adding in nt=20 and it helped a good deal
It's good to hear that. But it doesn't work for me.:) coz if I add some nt values, the vmetric drops quickly, probably because the clips in my hands are clean. But I have some animes that really have bad quality and I think setting some nt values would be of great help, thanks!

dsmith
2nd June 2003, 07:36
Not sure I can comment on Cipher's problem, but playing around with the VOB I noticed an oddity. If I set the override [frames 321,324,325; haven't done enough to tell if there's a pattern] to 'c', the Show info tells me it's forcing 'n', and if I set 'n', it tells me it's using 'p' (the default). If I set it to 'p', it says it's forcing 'p'. Not sure how to get it to select 'c'.

AVS script:


LoadPlugin("E:\DVDTools\AviSynth25\plugins\MPEG2Dec3.dll")
LoadPlugin("E:\DVDTools\AviSynth25\plugins\decomb5.dll")
MPEG2Source("E:\Clips\Video\Testing\cipher\test.d2v")
ConvertToYUY2(interlaced=true)
Telecide(ovr="test.tel.txt",order=1,guide=0,chroma=true,post=2,vthresh=14,dthresh=14,show=true)

Guest
2nd June 2003, 13:36
@cipher

I am downloading...

@dsmith

Thank you for pointing that out. Beta 6 fixes it:

http://shelob.mordor.net/dgraft/decomb/decomb500b6.zip

Guest
2nd June 2003, 13:52
@cipher

The idiots applied the fades with field granularity after 3:2 pulldown, which makes the fade sections interlaced.

What your clip shows is that the difference metric is great for field matching and not so great for comb detection. That leaves me two options: 1) go back to the previous metric for both matching and comb detection, or 2) try to normalize the metric for luminance level, as I did in the original Dup. I will experiment and choose the best of the two. I agree that the current behavior is not acceptable.

EDIT: There's a third option: 3) find a new better metric. :)

DoW
2nd June 2003, 16:32
@cipher:
Yeah, ZoE is pretty noisy for an DVD anime. Im experiencing a simliar problem to what you are with fading intro credits (fading in part interlaced, middle static part not, fade out interlaced). The vmetric is very low or zero when you have a background of almost all one color that is solid (black, gray, what have you) and the vmetric slowly increases as the credits fade in, and decrease on the fade out. For right now, Im gonna try using the override to ignore interlacing on the credits and then comming back and triming them off and using FieldDI() on them. Cant wait to see the magic that neuron2 pulls off, as he always does:D.

HomiE FR
2nd June 2003, 20:54
@neuron2 : It might be a bit off topic, but I have just found out your journal on your website (I had never looked at it before) and it seems really interesting ! :) Thanks for sharing your knowledge, I will try to understand what is explained there.

About beta 6 : it seems to me that new generation Decomb performs at least as good (and often better in my tests with the anime source I gave you) as old Decomb 4. Just my experience with it. I guess YV12 support is not too far away then ! :p

Ulm
3rd June 2003, 05:16
Just an FYI...

I've been having the dickens of a time with Avisynth 2.52 and Decomb (all versions).

If I just do a decomb with no other processing, there's no problem. However, if I convert the colorspace from YUV2 (Huffyuv, actually) to RGB32 (or YV12, I found), Avisynth starts to throw access violations out frequently, but seemingly at random. This was with both the 5.0 betas and the last 4.0 Decomb.

I backed off to 2.51 and Decomb 5.0 beta6, and I don't seem to be having the same problem. I'll know more after my process runs for a few hours.

Whether this would be a problem with Avisynth, Decomb, or a combination, I don't know. I can reproduce it pretty easily right now, if I can do anything to help.

Here's an example script that didn't work with Avisynth 2.52.


<SNIP>
AVISource("D:\Capture.avi")
Telecide(order=1, guide=1, post=2, vthresh=10, nt=50, blend=true, show=false)
Decimate()
dup(blend=true, chroma=false, threshold=5)
Crop(8,8,-8,-8)

ConvertToRGB32()
Levels(0,0.85,255,16,236)
MSmooth(threshold=10, strength=3, mask=false)
MSharpen(threshold=20,strength=100,mask=false)
<SNIP!>

If I remove the 'ConvertToRGB32()' (and everything that depends on RGB space) everything seems to work okay. Otherwise, seemingly random access violations while feeding either VirtualDub or TMPGenc (or feeding TMPGenc via Vdub's frameserver). BTW, I made sure it wasn't an issue with MSmooth or MSharpen. Any filter after the RGB conversion section will cause the access violations.

Otherwise, Beta 6 seems to work well for me, except that my source is heavily combed after the telecine is done. I have to set my vthresh fairly low to make sure they get postprocessed. I think it's either my cap card, or VCR jitters. Ah well.


Thanks...

cipher
3rd June 2003, 16:09
@DoW
Forget about my suggestion on enabling "chroma=true". Lately I've found its annormal behaviour:

Playing with Shania Twain's Any Man of Mine, when I set chroma=true I found:
1. Some frames which were not supposed to be combed were detected as combed, as DG mentioned in his docs.

2. At least one frame that I noticed had its vmetric value changed if I changed the "vthresh". The vmetrics, as far as I've understood,should've been INDEPENDENT of what "vthresh" we set.

3. And that frame I mention in 2) was combed, but the combs can't be de-interlaced well no matter how low the vthresh and dthresh were set. I mean, the "show" said it was "interlaced" so it must have been deinterlaced by post=2, but my eyes could still see the combs no matter how low a vthresh and/or dthresh was(actually, the combs didn't even change in my eyes when I altered the 2 thresholds).

4. vmetric of one single frame differed in Avisynth v2.51beta and v2.52, and the difference was huge.

Setting chroma=false made all these 4 strange behaviours disappear. Since the Decomb docs metion the instabilities of chroma=true, it's NOT a bug. And now knowing this, I take my word back and really recommend you not to use chroma=true. It's better a low threshold than a wrong decombed movie, right?:D And let's wait for DG's new idea on handling fades.:)

@Donald,
The idiots applied the fades with field granularity after 3:2 pulldown, which makes the fade sections interlaced.

So it's not even an inability of Decomb in anyways, even if we do a completely perfect IVTC on these stupidly-edited frames, we may not get rid of those lines, right?
But I'm still looking forward to your new beta, which can even beat those crazy badly-edited frames.:D

Edit:
Sorry, I was wrong, and Donald corrected me that the 2) I mentioned here was pretty normal, as:
The reason the vmetric can change with vthresh is if you force the desperation mode to pick the next (forward match frame 'n'), it gives you the metric for that match

Guest
3rd June 2003, 20:13
Originally posted by cipher
So it's not even an inability of Decomb in anyways, even if we do a completely perfect IVTC on these stupidly-edited frames, we may not get rid of those lines, right?The fields are matched as good as they can be. You can see that the actual action has had its 3:2 combing removed, but the fade effectively overlays a video clip on top of the 3:2 content. The old Decomb has exactly the same problem with this, and even FieldDeinterlace() by itself has trouble seeing the fade frames as interlaced unless you set threshold really low. And then if they are detected as interlaced, you need dthresh really low to fix them. The problem is that the field-to-field change is very small.

But never fear, I think I may have a new metric that will easily pick up these things.

For now, you could postprocess Decomb's output with TomsMoComp, but it will do smoothing (a kind of median filtering) on every frame.

DoW
4th June 2003, 01:03
Like Neuron2 was saying, you can use a low threshold and dthreshold to deal with it. Not to repeat, but previously in the thread I mentioned that I dealt with credits like these by trimming them and using using threshold=4 and dthreshold=4 in FieldDI. If Neuron2 says that hes comming up with a new metric, this may be a very mute point soon:D.

Guest
4th June 2003, 05:39
MetricX kicks butt on the cipher fade clip, giving a vmetric increase of 2000% (20 times) as soon as the fade starts! Field matching is unchanged. Get this: the new metric has no multiplies or divides and only 3 additions; all the rest is compares and boolean logic.

I have to regression test it against my test suite and then tie up some loose ends (support both field orders, chroma true/false) and then it looks good to go.

I'll describe the metric in my journal tomorrow.

@cipher

The reason the vmetric can change with vthresh is if you force the desperation mode to pick the next (forward match frame 'n'), it gives you the metric for that match.

cipher
4th June 2003, 10:04
Originally posted by neuron2
MetricX kicks butt on the cipher fade clip, giving a vmetric increase of 2000% (20 times) as soon as the fade starts! Field matching is unchanged. Get this: the new metric has no multiplies or divides and only 3 additions; all the rest is compares and boolean logic.

I have to regression test it against my test suite and then tie up some loose ends (support both field orders, chroma true/false) and then it looks good to go.

Can't wait~~~!:D
And trillions thanks!

cuisinart
4th June 2003, 18:48
Hi,

I was playing around with beta6 and noticed that enabling show=true always displayed metrics for _only_ p and c, regardless of the value of order=. As I understand it, when order=1 Telecide() will determine the best match between the current and next frame, which is equivlent to setting mm=2 in decomb4. I was wondering if I was missing something here; show=true should give a metric for n, correct? Or is the metric displayed for p actualy the metric for n? I tried to figure it out but just managed to confuse myself. :D

By the way, great job on the new decomb version! I've put it through my torture clips and noticed a definate improvement. Keep up the good work :)

EDIT:
Ah, I answered my own question, I think. Reading back on previous posts I noticed you mention that forward matching in now gone, except in special situations.

gizmotech
4th June 2003, 21:19
Quick Question,

@neuron2 What is the current default gthresh value? in the documentation it sais 30, however it also sais in the documentation that anything over 20 is starting to get dangerous.

Is the current default value 30, or something lower then that?

Gizmotech

Guest
4th June 2003, 22:10
Originally posted by gizmotech
Is the current default value 30, or something lower then that?
Current default is 15. I will correct the documentation.

The beta to be released shortly will have MetricX and display of the pattern guidance mismatch percentage to let you tweak gthresh.

HomiE FR
4th June 2003, 23:01
Waiting for MetricX... :) Thanks neuron2, I will test it against my anime source tomorrow if it's out.

gizmotech
5th June 2003, 02:15
@neuron2:
Just gonna report some VERY strange behaviour. (decomb 5b6) I've just created an AVS file for my encode, and stepped through a number of scenes in vdubmod to check and make sure the "mouth problems" are gone, and frame for frame they are completely gone. Now after having run this avs through a 1 pass divx somehow a frame which shows up in vdubmod running the avs as decombed is now combed.

So this frame, by avs prior to encoding, is perfect. After encoding, using the same avs is now combed. The unusual part is I've reproduced this 2 encodes in a row now. I'll wait for b7 for your new matriX and see if this trend continues. If it does I will send a vob segment and avs script.

Gizmotech

Guest
5th June 2003, 02:34
@gizmotech

Please post your script when describing problems. It saves me from having to guess at things.

The only thing I can think of is that you have pattern guidance enabled with a highish gthresh. Guidance is not completely deterministic in that starting from different points in the clip may give slightly different results.

EDIT: The magnitude of "slightly" increases with gthresh. :)

gizmotech
5th June 2003, 02:42
Appologies.


# PLUGINS
LoadPlugin("C:\newfilters\mpeg2dec3.dll")
LoadPlugin("C:\newfilters\decomb5.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\WarpSharp.dll")
LoadPlugin("C:\newfilters\convolution3d.dll")
# SOURCE
mpeg2source(idct=6,d2v="C:\CrestoftheStars\Episode5\Episode5.d2v")
YV12toYUY2(interlaced=true)
# IVTC
Telecide(order=1,post=2,guide=1,vthresh=34.5,nt=30,
dthresh=9,blend=true,gthresh=15)
Decimate(cycle=5,quality=3,mode=1)
# Smoothing
Convolution3d(preset="animeLQ")
# CROPPING
crop(8,0,704,480)
# RESIZING
BilinearResize(640,480)
# Sharpen
WarpSharp(depth=80, blur=3, bump=80, cubic=-0.6)


I'm honestly confused at this point as why would it show up correctly when the avs is viewed in vdubmod, however after the encoding process result in a bad dicision?
If nescessary I can post pics/small vobs to demo w/.
EDIT:
So basically you're saying that by skipping to various parts of the video in vdubmod it will change how it is attempting to perform patern matching? That will make it very difficult to preview a whole telecide run, as hitting stop at any point will restart the partern matching.

Guest
5th June 2003, 14:31
@gizmotech

As I hope to describe soon in my journal, you can either have poor deterministic pattern guidance or good slightly indeterministic pattern guidance. Have you established whether it is indeed a guidance problem? If the frame is rendered correctly with guide=0 in VDubMod, try an encode with guide=0 and tell me whether it is still rendered correctly.

@all

I am just finishing up the docs for the new beta. One thing I've noticed about the new metric: it is more sensitive and can pick up the fades but that makes it more sensitive to content that mimics combing as well. This only bothered me with one clip in my test suite, but I think it would be worthwhile to enhance the override capability to allow specifying the vthreshold to use for different frame ranges (perhaps other parameters as well, why not all?).

gizmotech
5th June 2003, 16:01
Alright. Looks like guide=0 fixed it. I look forward to reading that journal entry.

And adjustable vthresh by frames was actually something I was gonna ask about. I look forward to seeing it in the next release.

Gizmotech (Looking for that YV12 :)

Defiler
5th June 2003, 16:02
neuron2: I've had vastly better luck with hybrid footage using the new Telecide/Decimate. Thanks again for your efforts. The new parameters are extremely useful.

Guest
5th June 2003, 17:24
@Defiler

Thank you for the feedback.

@gizmo

OK, I will hold up the beta and add overridable vthresh.

DoW
5th June 2003, 18:34
@neuron2
Well, since your working on the override functionality, would it be possible to do both manual field selection and post override on the same frame (I tried last night and couldnt get it to work (if im missing something, please let me know)).
Also, the increased sensitivity to content that mimics combing, what would this do to the vob that I sent you from ZoE?

Guest
5th June 2003, 21:41
Originally posted by DoW
@neuron2
Well, since your working on the override functionality, would it be possible to do both manual field selection and post override on the same frame (I tried last night and couldnt get it to work (if im missing something, please let me know)).
Also, the increased sensitivity to content that mimics combing, what would this do to the vob that I sent you from ZoE? Why do you guys never give me the scripts and override files so that I have to either guess or ask for them???

You should already be able to combine the two overrides. Please post your overrides file. :)

What would the new metric do to your clip? I'll try it when I get home from work. But if I remember correctly, you were talking about that title fade that is impossible to see normally. I think it requires an extremely low vthresh to be detected. The best thing to do would be to set a normal vthresh and then override it very low during that portion.

I will also post the new beta then as I have the vthresh override working and all the docs done.

@gizmo

I haven't forgotten about YV12. But as long as functionality is changing I don't want to do stuff twice.

DoW
5th June 2003, 22:09
@neuron2:
Sorry for not posting the file, I was uber busy and late for a meeting. Came up with an idea about the override, I wanna try it first, and if it solves it, then I should try more things before I open my mouth.
I was refering to the section of vid where the image gets all these horizontal lines when its zooming in on the cannon, ~frame 528-880ish.

gizmotech
5th June 2003, 22:22
@neuron2

Don't mind me I'm just impatient. I look forward to seeing matriX in action, and trying out a vthresh overide script.

Guest
6th June 2003, 00:22
Here's the new beta:

http://shelob.mordor.net/dgraft/decomb/decomb500b7.zip

Please read the tutorial to see how to use the new vthresh metric.

This version adds:

* New combing metric that is more sensitive.
* vthresh manual overrides per frame range.
* display of pattern mismatch percent to tweak gthresh.
* gthresh, dthresh, vthresh now integers, not floats

Example of vthresh override:

500,650 v 35

Make vthresh 35 for frames 500 to 650, then restore the vthresh as defined in the vthresh parameter.

cipher
6th June 2003, 00:49
I knew it! I knew it would work miracles!!
And what I didn't know was that it is much more effective than I imagined!! The vmetric distinguishes the really combed fading frames and clean frames so easily that it's just like...WOW!

Tha~~~~nk you~~~!:D

Edit:
Okay, for those who might still be in doubt, this is what I got for the clip I provided:
After I set an appropriate vthresh,
NONE of the clean frames has vmetric above 30,and
ALL of the combed frames are way above 100, usually around 150.

I don't know how DG did it, but guys, as Morpheus would say:"He is the one.":D

Guest
6th June 2003, 00:59
Originally posted by cipher
I knew it! I knew it would work miracles!!
And what I didn't know was that it is much more effective than I imagined!! The vmetric distinguishes the really combed fading frames and clean frames so easily that it's just like...WOW!

Tha~~~~nk you~~~!:D Of course, regulars here know that I aim to please. It is gratifying to me to know when I have succeeded. :D

But let's not count our chickens yet. The other users need to weigh in.

cipher
6th June 2003, 01:02
Okay, there are a few music videos that are standing by.
I will post my results later tonight.

Guest
6th June 2003, 02:00
Originally posted by gizmotech
Alright. Looks like guide=0 fixed it. Try a lower gthresh rather than turning off pattern guidance altogether. As I say in the docs, 15-20 is already dangerous.

Also, are you sure there is significant 3:2 content?

gizmotech
6th June 2003, 02:05
Heyo,

I'm back with a silly question. How does the pattern mismastch percentage relate to the gthresh value? for instance I have a number of frames which were overriden incorrectly which have percentage mismatches greater then 10 but less then 15, yet my gthresh has been set to gthresh=15.

Is there a directly correlation between gthresh =15 and a patern mismatch =15%? can I safely assume that setting gthresh=20% means that any frame which is 20% mismatched will be overriden?

telecide(order=1,post=3,guide=1,gthresh=15,vthresh=18,show=true)

As well, does the hints=true affect the patern matching in any way or is it just passing information along?

Gizmotech.

dsmith
6th June 2003, 02:14
Having trouble with the override file.

Script:

LoadPlugin("E:\DVDTools\AviSynth25\plugins\MPEG2Dec3.dll")
LoadPlugin("E:\DVDTools\AviSynth25\plugins\Decomb5\decomb.dll")
SetMemoryMax(16)
MPEG2Source("E:\Clips\Video\Dual\Raw\OP.d2v")
ConvertToYUY2(interlaced=true)
Telecide(ovr="op.tel.txt",order=1,post=1,show=true)
#Decimate(cycle=5,mode=2)

Override file (E:\Clips\Video\Dual\op.tel.txt):

174 p
175 p


However, Show indicates that those frames are still using the C match, not being forced with the override. Giving an absolute path didn't make any difference. The AVS and override files are in the same directory.

--
David

Guest
6th June 2003, 02:29
Originally posted by gizmotech
I'm back with a silly question. How does the pattern mismastch percentage relate to the gthresh value? for instance I have a number of frames which were overriden incorrectly which have percentage mismatches greater then 10 but less then 15, yet my gthresh has been set to gthresh=15.

Is there a directly correlation between gthresh =15 and a patern mismatch =15%? can I safely assume that setting gthresh=20% means that any frame which is 20% mismatched will be overriden?

telecide(order=1,post=3,guide=1,gthresh=15,vthresh=18,show=true)

As well, does the hints=true affect the patern matching in any way or is it just passing information along?

Gizmotech. Yes, the numbers are commensurate. If your mismatch is 10 and the gthresh is 15, then the override will be allowed, even if *you* know it is incorrect. That is why I said 15% is
dangerous. :) Try setting gthresh to 10 and see what happens.

Hints do nothing except inform Decimate modes 1 and 3.

EDIT: It occurred to me that maybe you are misinterpeting "override" in this context. If the pattern guidance thinks a blind field match is not what it predicts based on pattern analysis, it tries to override the blind field match. The override is allowed if the mismatch is less than the gthresh.

Guest
6th June 2003, 02:49
Originally posted by dsmith
Having trouble with the override file. David keeps me honest on the overrides for pattern matching. :)

Get this:

http://shelob.mordor.net/dgraft/decomb/decomb500b8.zip

dsmith
6th June 2003, 03:11
Quick fix :)

Next:
There's no indication in the Show text when a frame has had the postprocessing aspect overridden. You can tell by the absence or presence of a motion map on post=3, but there's nothing for post=1.


--
David

Guest
6th June 2003, 03:11
Originally posted by Bach
is it possible for you optionally to get the order parameter from the d2v file instead of simply from "order=1(or 0)"? Sorry for the delayed response; I've been thinking about it. :rolleyes:

First, not all source clips come from DVD2AVI, for example, my off-air Sopranos captures.

Second, strangely enough, a clip that is fully 3:2 does not have enough information in the D2V file! The numbers repeat 0 1 2 3 and if you think about it, it just isn't enough. If you see some interpolated all 0 or all 2 sequences, fine, but if not...

Third, I'd prefer users to understand the issues and affirmatively set a field order. That's why it throws an exception if the order parameter is omitted. :devil:

Guest
6th June 2003, 03:20
Originally posted by dsmith
There's no indication in the Show text when a frame has had the postprocessing aspect overridden. You can tell by the absence or presence of a motion map on post=3, but there's nothing for post=1.
That's true. My reasoning was that the user asked for it, do we need to tell him?

Actually, the show function was getting complicated... :D

How badly do you want it? You've earned some good brownie points so far.

gizmotech
6th June 2003, 03:39
Originally posted by neuron2
EDIT: It occurred to me that maybe you are misinterpeting "override" in this context. If the pattern guidance thinks a blind field match is not what it predicts based on pattern analysis, it tries to override the blind field match. The override is allowed if the mismatch is less than the gthresh.

Ahh, you're right, I wasn't understanding correctly. This is a much better explination. (though I'm still wrapping my mind around a few things).

Perhaps it would be better to describe gthresh as a limiter, as it limits how large the mismatch can be when overiding the blind match(assuming I understand).

At any rate, I'm quite happy with this version, now I just need some yv12 to test with and you've got yourself best filter of the year. (no more silly 2k override files for me! w00t!)

Gizmotech

Guest
6th June 2003, 04:01
@gizmo

I'll clarify the reference manual and add a FAQ entry. If you misunderstood, it must have been badly expounded. :)

Thank you for the feedback.

If nothing serious comes up in the next few days, I'll start the YV12 support. Then I want to integrate the new Decimate(mode=4) hybrid-handling functionality and the new edge-directed interpolation (to fight jaggies on interpolated areas).

Guest
6th June 2003, 04:16
Here's the new FAQ I made in response to gizmo's point:

How does gthresh affect the field matching when pattern guidance is enabled?

If the pattern guidance thinks that the calculated (blind) field match is not what it predicts based on pattern analysis, it tries to override the blind field match. The override is allowed if the pattern mismatch is less than gthresh. Think of gthresh as a limiter: it limits how large the mismatch can be before a predicted match is overruled by the actual calculated match. If your gthresh is too high, it may cause a new pattern in the clip to be erroneously overridden by the previous pattern. There is a happy medium that allows new patterns to be locked onto quickly while still allowing the pattern guidance to correct mismatches due to noise, etc. The happy medium is usually in the range 5-15%, but it will be clip-specific.

cipher
6th June 2003, 04:44
Okay, I've just done 4 music videos, and the results are awesome as expected!

Three of them contained a lot of fades, and one of these three was a little noisy, but I used "nt" to beat it; the last one was much more like normal films, clean and well-made.
The result was absolutely exciting. And Decombe 5 beta7 had just done what its previous versions never did.:D

JuanC
6th June 2003, 04:52
Great! Betas 7/8 are giving me better results than previous betas! :) I have some questions though:

1. GThresh: What does (technically) a “pattern mismatch=100.00%” mean? I see this frequently in some parts of my video clips.

2. VThresh: Many times in my clips, the vmetric is higher than VThresh, but the frame is shown as being “[progressive]” (and not post processed) ??? In fact these frames are not interlaced, but :confused:

3. VThresh: Also, I have seen that lowering VThresh, Telecide, instead of deinterlacing the best match (P or C), would make a match “using N”, resulting some times in additional duplicate frames (Exact duplicate of the next frame). Could it be possible in a new release of Telecide to tweak this behavior? (Perhaps using a new threshold?) So that some times it could deinterlace (blend) it?

4. VThresh: Finally, when I used VThresh=255 to see what the vmetric was originally for a set of frames, then I saw that vmetric is always zero???

Thanks for your invaluable help,

Juan

EDIT: Numbered the questions to be referred in my next post.

cipher
6th June 2003, 05:11
JuanC, the manual has been updated.:)
Vmetric higher than the Vthresh is not necessarily considered being combed, but ONLY vmetric higher than 48 is defined as combed.
If you lower Vthresh, vmetric will be calculated to a higher value, if it goes up beyong 48, then it is shown as "interlaced".

Edit: So 48 is the unique real threshold, but vthresh acts more like a calibration for every specific movie.

JuanC
6th June 2003, 05:48
Thanks cipher, I missed it :rolleyes:. It's in the tutorial!!.

There are the answers for my questions 2 & 4. So the only valid, remaining, questions after reading "DecombTutorial.html" are 1 & 3.

Thanks again, :J

EDIT: I noticed that using nt>0 will also lower the vmetric values.

Guest
6th June 2003, 12:25
@JuanC

Pattern mismatch of 100% means either that the pattern analysis did not result in any prediction at all, or that the frame was combed after pattern guidance.

Regarding the forward match: I will consider your request. Of course, Decomb classic would always output the forward match, wouldn't it?

The nt parameter should be used with caution. It is appropriate only for really noisy clips and will do harm otherwise.

cipher
6th June 2003, 13:24
The nt parameter should be used with caution. It is appropriate only for really noisy clips and will do harm otherwise.

I know "nt" affects the decision made by telecide(), when you said "do harm", did you mean nt may not only give a wrong judgement, but it may also decrease the image quality?

Guest
6th June 2003, 13:54
"Do harm" just means that the field match decision may be made wrong.

JuanC
6th June 2003, 14:25
Originally posted by neuron2
Regarding the forward match: I will consider your request. Of course, Decomb classic would always output the forward match, wouldn't it?
@neuron2, Thanks for your answers.
Honestly, I don’t know how to answer that, since I get better results for my TV captures using Telecide v4.10b4 (mm=2): matching fields from only Current and Next frames. Here the options I use:

Telecide(guide=0,Threshold=25,blend=true,chroma=true, mm=2, y0=350, y1=430, show=true)

And the ones I use for v5.0b8:
Telecide(order=1,guide=1,Gthresh=10,Vthresh=12,post=3,blend=true,y0=350,y1=430,nt=50,show=true)

Guest
6th June 2003, 15:30
@JuanC

What do you mean by "better results". Can you provide a source clip that demonstrates it?

You have guidance enabled in one and not the other. Please make proper comparisons.

Are you SURE you have the field order correct?

JuanC
6th June 2003, 16:08
Originally posted by neuron2
What do you mean by "better results". Can you provide a source clip that demonstrates it? I mean the best you can get with that version (4.10b4). It is important to note that I have only tried video clips I capture from analog, noisy TV.

These clips are hybrid mostly film. I have tested this morning the same clips I sent you before. I could send them to you again, you just have to say so. Honestly, they look better to me with those options in v4.10b4

Originally posted by neuron2
You have guidance enabled in one and not the other. Please make proper comparisons. You suggested me to disable guidance with Telecide 4.10 to disable pattern hinting to Decimate; It works wonders. In v5.0b disablig guidance would "Do harm" to the field matching. (in my clips)
Originally posted by neuron2
Are you SURE you have the field order correct? Yes I am, I used your very illustrative tutorial to make sure.

Guest
6th June 2003, 16:13
@JuanC

I ask what you mean by better and you respond by saying they look better! Can you please say what is better? Are the scene changes better? Is the field matching generally better? Are there more combs? WHAT???

When I get home tonight I will retry your clips.

HomiE FR
6th June 2003, 18:24
@neuron2 : Hi, thanks for the new betas. :) I think there is a bug when using ovr parameter in Telecide in beta 8. I think it's not my fault because the only line there is in "telecide.txt" is :
3044,3214 nppcc
and I'm sure that Decomb reads the line because I've got an Avisynth access violation at frame 3044.

Moreover this is only happening when using "n" frame in ovr. But I need these frames in some "travellings" (pannings in goog english??), I can send you the scene where ovr is needed in order to get correct field matching.

Please correct this small bug, Decomb is close to reaching the top ! :) Thanks in advance.

HomiE

Guest
6th June 2003, 19:50
@HomieFR

I can't duplicate this. Please provide a clip, script, and override file that causes it to happen. Also, please provide a clip showing the need for the overrides (if it is not the same as the one just requested). Thank you.

JuanC
6th June 2003, 20:47
Originally posted by neuron2
Can you please say what is better? Are the scene changes better? Is the field matching generally better? Are there more combs? WHAT??? OK, you're right. When I say v4.10b4 look better, I mean: The field matching is better in general using (mm=2) for my noisy, hybrid mostly film, Analog TV captured clips. I don't really know if this is very common for capture cards. I use an ATI AIW 8500 with catalyst3.4 & MMC8.5, interlaced MPEG2 @8mbps. And, as a result of this:

There are less, almost zero "combed" frames escaping from field matching/ post processing (however there are more frames being Post-Processed/ blended than with v5.0); and
There are no additional duplicate frames resulting from pattern changes making only occasional C/N matches.

The scene changes are fine with both versions (4.10b4 & 5.0.0b8) of Telecide (There are some sporadic new duplicate frames with 5.0). Any way, latest beta 8 of v5.0 is an enormous improvement over previous 5.0 betas.

I have seen an issue (Telecide v5.0) with horizontal patterns in some frames being detected as combing and thus getting blended.

I wish there could be a not very far future release of the new Telecide with the ability to tweak any override or option to get a behavior similar to mm=2 in the old Telecide.

Thanks yet again, :J

HomiE FR
6th June 2003, 20:50
OK no problem, here it comes :

1. The clip comes from the same anime that I already sent you before to test previous matters. But it's another scene, which I already cut in order to send it to you. The vob file is 23.8 MB.

2. The script is just what is written below (just the directory of the vob file is different) :
MPEG2Source("[...]\override.d2v")
ConvertToYUY2(interlaced=true)
Telecide(order=1,post=0,ovr="telecide.txt")
Decimate(cycle=5)
ConvertToYV12()
The problem happens no matter if Decimate is used or not, and no matter if ConvertToYV12 is used or not.

3. The override file is called "telecide.txt" and is put in the same directory as the script which is written above. There is only one line is the file :
52,773 nppcc
The problem appears with "nppcc" as the manual field matching. If I put "pppcc" there is no avisynth access violation, but there is combed frames every 5 frames, as you'll probably see when looking at the clip.

The problem is, to be precise : "Avisynth read error: Avisynth: caught an access violation at 0x..., attempting to read from 0x..." (the two numbers ... are different).

This clip is, as you thought, the one where I believe that Decomb is unable isn't able to do the correct field matching without some help. But I hope you'll prove me wrong ! :)

I'm not sure about how I should send you the clip : do I use the ftp account that you provided last time ? I'm waiting for an answer to send the file.

HomiE

Guest
6th June 2003, 21:07
Yes, use the ftp account.

Guest
6th June 2003, 21:10
@JuanC

I keep telling you, Decomb 5 already emulates mm=2 when order=1!

Please, let's get specific. I have your clips and your scripts. Point me to the clip and frame numbers you think are handled better by Decomb 4. Leave off Decimate so we can use the direct frame numbers from Telecide.

I'm sorry to be so exacting but generalities just don't help us.

Thank you!

JuanC
6th June 2003, 21:17
Originally posted by neuron2
Please, let's get specific. I have your clips and your scripts. Point me to the clip and frame numbers you think are handled better by Decomb 4. Leave off Decimate so we can use the direct frame numbers from Telecide. OK, I'll do so when I get home. Thanks.

HomiE FR
6th June 2003, 22:08
@neuron2 : I've got an answer. If post=0, it's impossible to play with "n" field matching. It leads to the bug described above. Moreover during some scene changes I can see some combed frames just after the change caused by the use of another field matching instead of "n". If post=2 or post=4, it's possible to play with "n" in an override file, and the scene changes are perfect, with the "n" field matching detection where it needs to.

However I'll still send you my clip when I get the pass to the FTP, cause I still need overrides to make it perfect.

HomiE FR

PS : I don't know if what I said above is totally obvious, but at least in the reference manual it isn't obvious that "n" field matching should only be used when post!=0.

Edit : I have another problem with beta 8, but I don't think this is a bug... I have problems with some scene changes. First of all this scene change needs a forward match "n" on the frame after the change in order to be uncombed.
- if post=0, "c" is used instead of "n" and the result is combed,
- if post!=0 AND vthresh=10 (default), "n" is used ! :) which is great. But with such a low vthresh I have many progressive frames which are deinterlaced. So I have to increase vthresh.

1st question : why isn't field matching acting the same if post=0 or post!=0 ? I thought that field matching and deinterlacing were two different operations, done one before the other. In my case I would love to have the scene changes at "n" even without postprocessing (cause my clip is really clean).

Then is I increase vthresh so that no (or very few) progressive frames are processed, the scene change becomes falsely detected (field matching at "c" instead of "n")... Could you explain (please) why Decomb works this way ? It seems that in my case I can't have a perfect setting : on the one hand you can have good field matching on scene changes BUT too many frames processed, and on the other hand you can have false field matchings on scene changes BUT few progressive frames processed.

Thanks in advance neuron2. I will also send you the part with this scene change so that you can test it (if you want and have time to).

Guest
6th June 2003, 23:30
Originally posted by HomiE FR
@neuron2 : I've got an answer. If post=0, it's impossible to play with "n" field matching. It leads to the bug described above. Confirmed. I will fix it for the next beta.

Moreover during some scene changes I can see some combed frames just after the change caused by the use of another field matching instead of "n". If post=2 or post=4, it's possible to play with "n" in an override file, and the scene changes are perfect, with the "n" field matching detection where it needs to. I need the clip that demonstrates this.

PS : I don't know if what I said above is totally obvious, but at least in the reference manual it isn't obvious that "n" field matching should only be used when post!=0. I'll make sure it is prominent in the documentation.

Edit : I have another problem with beta 8, but I don't think this is a bug... I have problems with some scene changes. First of all this scene change needs a forward match "n" on the frame after the change in order to be uncombed.
- if post=0, "c" is used instead of "n" and the result is combed,
- if post!=0 AND vthresh=10 (default), "n" is used ! :) which is great. But with such a low vthresh I have many progressive frames which are deinterlaced. So I have to increase vthresh. I need a clip that demonstrates it.

1st question : why isn't field matching acting the same if post=0 or post!=0 ? I thought that field matching and deinterlacing were two different operations, done one before the other. In my case I would love to have the scene changes at "n" even without postprocessing (cause my clip is really clean). For speed reasons and to avoid spurious n matches, which shouldn't be necessary except at scene changes, Decomb does not look at the n match *unless* the matched frame is determined to be combed. You can get what you want by setting post=1. My concern is that you are claiming more than just scene change frames are affected. I really need to see the clip that demonstrates that. Thanks.

Then if I increase vthresh so that no (or very few) progressive frames are processed, the scene change becomes falsely detected (field matching at "c" instead of "n")... Could you explain (please) why Decomb works this way ? It seems that in my case I can't have a perfect setting : on the one hand you can have good field matching on scene changes BUT too many frames processed, and on the other hand you can have false field matchings on scene changes BUT few progressive frames processed. The combing detector should be able to achieve what you want. I need the clip to comment further.

I need the clip(s) that demonstrate all these points plus scripts and instructions for creating them. Thank you.

Guest
6th June 2003, 23:48
By the way, I just published a description of MetricX in my journal.

InfoCynic
7th June 2003, 00:19
Edit: This took so long to post, dgraft posted TWICE while I was
working. Sheesh. :) Well, keep in mind your reply wasn't available when I posted this.

So I've spent about 8 hours in the past 2 days playing with Decomb 5 and everybody's favorite whipping-boy, TNG. Yes, I have no life, thank you all for caring. :) This has led to some interesting revelations...

1. Some of the exterior/space scenes in later seasons are FILM, with an identifiable 3:2 pulldown pattern. Not all, and the pattern can be hard to get decomb to match... but important to know.
2. Post-processing plus pattern-guidance is a very bad mix. Since TNG contains large portions of 3:2, guide = 1 made sense, and with some tweaks to the gtresh, I was very happy with the matching I was getting. Until I moved from post=0 to post=1 to find vthresh. I'll put up a series of screenshots for this in a bit.

With postprocessing on, if a frame is detected as interlaced, it gets a 100% mismatch and is automatically out-of-pattern. This makes some sense in theory, but when reality is that our vthresh is going to mark some progressive frames as interlaced, and that these frames are going to be in-pattern, it's a little annoying. I think Homie FR was getting at something like this in his post above.

I want to be able to keep guide=1 on, because with the new pattern guidance algorithms (which are working quite well with post=0, I must say), I can use hints=true and pass it off to mode=1 or mode=3 decimate (side note: I'd like to see that new mode 3 algorithm as an option soon, so I can test it on TNG while I'm working on it anyway).

3. Deinterlacing of frames detected as combed, and noticably combed, is not nearly strong enough, even with dthresh=0. I'll post a screenshot of that too.

Overall, I think Decomb 5 may finally be able to get us where we need to be in order to be able to handle hybrid material like TNG or Babylon5. Given that the problem has always been knowing FILM from VIDEO and that the new pattern guidance can work with it, at least in some cases, is very encouraging.

Telecide(order=1,guide=1,gthresh=17,post=4,vthresh=4,dthresh=10,show=true,hints=true)

Screenshots at http://infocynic.no-ip.org/TNG/
Changes from that for specific screenshots:

TNG01.PNG: post=5, shows areas being detected as interlaced
TNG02.PNG: post=4, vthresh=5. frame is no longer detected as interlaced. But I need vthresh=4 if I want to catch most of the interlaced frames...
TNG03.PNG: exactly as stated. shows frame flagged interlaced, out-of-pattern
TNG04.PNG: post=0. shows frame without any postprocessing. Looks good to me, and it's even in-pattern (which it should be, it's clearly part of a 3:2 cycle if you saw its neighbors).

TNG05.PNG: post=0. shows another frame that needs deinterlacing. this is the "before" postprocessing.
TNG06.PNG: post=4, dthresh=0. This is the "after." Not much improvement.
TNG07.PNG: post=5, dthresh=0. And yet... to see this, you'd think it would have done a better job.

Let me know if you need anything more, I can probably cut a vob sample for you, since the old one you have is a whole different set of problems, which I don't want to address in this post.

gizmotech
7th June 2003, 00:40
Though it's largely useless to say this, I can confirm what Homie is saying as I have noticed this behaviour of scene changes being matched to C at vthresh's higher then 10. I had assume it was intentional, however I have identified 1 or 2 such scene changes where the scene needs to be matched to N but has been matched to C.

GizmoTech

Guest
7th June 2003, 00:45
@Info

TNG06 looks very well deinterlaced to me. What are you talking about?

Anyway, the ONLY way I want to address problems is with a VOB, a script, and a text message telling me what frames you object to. I hope you can appreciate the reason for that. Thank you.

dsmith
7th June 2003, 00:46
On the request about showing the Post override state in the Show text - that's just an "it would be nice if" request. Not really needed, just makes things a bit easier sometimes.

Read over your journal entry for today. Very nice setup for the algorithm :) However, it also explains why I'm having trouble with getting it to recognize when it needs to do the deinterlacing. You're requiring an additional comb match to the left or right of a detected pixel. The combs that I have the most trouble with are usually set up somewhat like this:

xx
xxxx
xxx
xxxxx
xxxx
xxxxxx
xxxxx

I have to move the vthresh down to around 3 or so before it will push those frames over 48. Obviously it's because the current algorithm isn't really designed to find that kind of combing. To be fair, with a normal vthresh in the 8 to 10 range the vast majority of the problem frames are caught, and I can still always set up the override files for this. My question is, what sort of artifacts show up if you look for adjacent combed pixels above and below? And what about checking the diagonally adjacent pixels, to find the stairstepping problem? (assuming you're only checking every other line, perhaps require either TL+BR or TR+BL adjacent pixels be combed)

Anyway, taking a look at some files that I had set up for v4... These are counts of the number of combed frames from pattern mis-matches during a particular scene. All of them except for one frame in the v5 set 3 in Ep 19 would fall under the "mouth" problem. The one out of place frame has combing across the entire face (seen from profile). No pattern guidance was used because I need to be sure there is never any frame uncertainty (I use these for editing).

Ep. 1 of BGC2040:

v4 override set 1: 5 corrections
v5 override set 1: 4 corrections

v4 override set 2: 8 corrections
v5 override set 2: 0 corrections

v4 override set 3: 7 corrections
v5 override set 3: 0 corrections


Ep. 19 of BGC2040:

v4 override set 1: 1 corrections
v5 override set 1: 1 corrections (different frame)

v4 override set 2: 6 corrections
v5 override set 2: 1 corrections

v4 override set 3: 38 corrections
v5 override set 3: 7 corrections


Overall an immense improvement. Also tried it on the Dual! creditless opening, and it was completely solid (though admittedly not much of a challenge; I keep it around for testing compression). Going to try a couple more series that I remember as being problematic.


--
David

Guest
7th June 2003, 00:47
Originally posted by gizmotech
Though it's largely useless to say this, I can confirm what Homie is saying as I have noticed this behaviour of scene changes being matched to C at vthresh's higher then 10. I had assume it was intentional, however I have identified 1 or 2 such scene changes where the scene needs to be matched to N but has been matched to C.

GizmoTech How am I supposed to do anything if you don't provide a clip?

C'mon guys, I'm here busting my butt for you, and you can't help me?

troy
7th June 2003, 01:09
Can someone take a big step back and help a newbie. What does this filter do. What is it good for. How do you use it.

Guest
7th June 2003, 01:25
It converts telecined and hybrid material to fully progressive material. The documents in the distribution answer all your other questions.

I was so tempted to answer: It's no good. It only eats CPU cycles. And nobody has figured out how to use it yet, much less its author.

MasterYoshidino
7th June 2003, 02:02
clip, clip, clip :(
would be nice haha but the most recent beta corrected my bad field matching on Chobits hybrid scenes where the "NEXT" button (3D Coreography @ 30fps ) overlayed on a FILM anime.
nonetheless the beta8 version seems to be very promising.

gizmotech
7th June 2003, 02:17
@neuron2

ohh come on.. it does more then just eat cpu cycles :P

All kiding aside it works really well. I'm just running my source through one last test run here, and if the scene change problem still exists for me I will post a vob segment for you to fiddle with. I think I might have been remembering from beta 6 however, as I didn't see the error where I thought I did before.

Gizmotech.
*Who really appreciates all of neuron2's hard work.

DoW
7th June 2003, 03:00
I am having some issues with ZoE and the new beta 8. First off is the fact that even though the vthresh is = 10, scenes with vthresh of 40 or so are passed though with post processing tellim me that they are progressive (the intro zoom in with the comb like effects have vmetric of up to 40 or so). Secondly, field matching issues that beta 6 resolved have cropped back up in this beta (see frames 931 and 932, 932 was okay in b6, but 931 was bad still). I think that is for some reason, b6 uses n for some of these frames, while b8 seems to be slightly stricter about using c and p only. Slightly more scarry are some frames where the new vmetric is lower for the combed frame than the rest of the scene (frames 894, 895). There is also a rather funny thing I noticed when going through the video, frame 828, vmetric = 0, p=0, c=0, pattern mismatch = -1.#J%. If any of this is repeat, Im sorry. Thanks for all the effort, I hope that this can all get ironed out, even if it involves calling me a nub. Note: tried with and without nt value.

AVS:
LoadPlugin("D:\Filters\mpeg2dec.dll")
LoadPlugin("D:\Filters\decomb500b8.dll")
MPEG2Source("D:\zoe idolo\ZoE test.d2v")
Telecide(order=1, guide=1, post=2, nt=20, vthresh=10, blend=true, chroma=true,
show=true)

I think you still have the cut I sent you, if you need it again, Ill send again. I can post a pic of the the last issue on my ftp if you want.

Edit: Stupid code to big, fixed

Guest
7th June 2003, 03:43
@DoW

Thank you, DoW! Now that is something I can work with. A clip, script, and description that demonstrates problems. :)

I've a very good idea what is happening and what to do about it.

@HomiE FR

I am advised that you are using the wrong password to login. The password is the doom9 screen name of the owner of the site. PM me if you can't deduce it from that. I post this here because you are not picking up your PMs, it seems.

EDIT: Everybody stand down. The same thing that is affecting DoW is affecting you all. Fix coming...

HomiE FR
7th June 2003, 06:15
@neuron2 : Ok the FTP account is working like a charm now, but yesterday when using the same login/password, it didn't work at all.

About the clip I'm sending you now (not finished yet, but in less than 30 minutes), it's a scene where I think that a few frames (during a fading) need an override field matching to be detected correctly ("n" field matching needed, and these frames are NOT detected as combed, far from that, you'll see why ! :) ). But I've never seen any filter (old Decomb, Uncomb, IT,...) which can handle it right.

Then about the scene change matter, the clip I provided last time should suffice to illustrate the problem. Just check the frame 153 (just after the scene change), it is typically the kind of frame where "n" field matching is needed. This is with this frame that I did my tests, so I don't think another clip is necessary.

Finally THANK YOU for your hard work. I think I write it in each post, but it seems it isn't enough. :p Of course Decomb is a great plugin, nobody will question that here. It's already from far the best out there. Sorry to have been a little late, but I just had to sleep a bit.

HomiE FR

EDIT : The file is up. Use override_good.vob (you can discard override.vob, since I had a little problem when uploading the file for the first time). Thanks.

InfoCynic
7th June 2003, 07:57
This is accurate as of beta 8.

I'll post the FTP to you by PM. My script and a file complaints.txt which details specific frames. I only have 25k upload and it's a 90mb vob (when I tried cutting it smaller, Telecide just would not synch up at all...), so be patient, but there's a lot of good examples of problems in there. The 1 or 1-2 frames here and there that are marked interlaced and out-of-pattern when they're progressive in-pattern, I'm not overly concerned about... realistically they probably won't matter... and the thing is, they are correctly flagged with post = 0 (every frame and range I found tagged wrong with post = 4 was right with post = 0).

The larger sets, and the interlaced frames not getting caught is annoying. If I use a lower vthresh to catch them, I get more and more problems with progressive frames marked interlaced out-of-pattern.

From a theoretical standpoint, does pattern guidance really have to be tied to the progressive/interlaced decision?

Mentar
7th June 2003, 14:26
I've played around with Decomb5 beta6 alot (didn't check D5b8 yet, but will now) and have made one little discovery which slightly confuses me. Please help me if I'm misunderstanding something here, but after careful stufy of the Reference manual I'm still none the wiser :p

When selecting the best field match for a clip, p and c are assessed and measured with a metric. The smaller result is arguably the better match, so it's being chosen and processed. Then the vmetric value is generated, which assesses how "combed" the result is, to decide whether or not it's interlaced and needs to be postprocessed.

Now my question: Shouldn't the "better" p or c value also result in a better vmetric result?!? Obviously this is not necessarily the case, see here:

http://www.earth-alliance.org/Combed.png
http://www.earth-alliance.org/Clean.png

c gets the better result than p, but the vmetric is much worse (and rightfully so, since the frame is combed)

This is the avs script I used to generate it:

LoadPlugin("C:\Tools\GORDIA~1\mpeg2dec3.dll")
LoadPlugin("C:\Tools\GORDIA~1\decomb.dll")
mpeg2source("Z:\noir vob1\Noir1.d2v")
ConvertToYUY2(interlaced=true)
Telecide(chroma=true,post=1,order=1,debug=true,show=true,
vthresh=26,ovr="override.txt")

After lots of manual tinkering, it seemed obvious that the vmetric was awesome. It correctly identified all combing in the resulting frame, later in the day I'd stop through the avs and only watch the vmetric to find bad field matches. After entries in the override file I was able to clean up the entire clip, and _always_ the manual overrides seemed to result in a better vmetric.

So here's my second question: Wouldn't it be feasible to code a Decimate mode which generates the vmetric value from _all 3 matches (p, c and n) and then selects the frame with the best vmetric? I wouldn't mind if such a mode was slow as a snail, it would ALWAYS be faster than manual interaction necessary for the perfectionists.

If any test clips are needed, I would be gladly willing to oblige.

Once again thanks a TON for the latest decomb, the results have never been THIS good already :D

Mentar
7th June 2003, 15:02
Just a quick addition with decomb5 beta8:

The effect is the same, just the values are a bit different:

1) For the "normal" mode without manual override:

frame 23324:
vmetric=46
p=318618 c=308882
[using c] [progressive]

2) For the manual override forcing p:

frame 23324:
vmetric=0
p=318618 c=308882
[forcing p] [progressive]

Both frames look just the same as in the other pics, so I chose not to post them again.

thanks to gizmotech :)

Guest
7th June 2003, 16:12
Time to come clean... :)

In beta 8, chroma processing was disabled, so chroma=true was ignored. I did that because MetricX was picking up too much chroma interlacing on my test clips and making it impossible to find a good vthresh value. I thought, I'll release the beta and repair that in the next beta and no-one will notice. Well, you did notice, e.g., DoW's combed frames are due to lack of chroma combing detection.

Now here's the astonishing discovery I made. I added proper chroma handling with MetricX. Immediately I started picking up totally unexpected chroma interlacing. I had a clip which was PERFECTLY matched field-wise, forcing the other ways made obvious gross luma combing. But the chroma was combed! So I separated fields and this is what I saw. First, one field of the matched frame:

http://shelob.mordor.net/dgraft/misc/chromashift2.jpg

Now the other field:

http://shelob.mordor.net/dgraft/misc/chromashift1.jpg

Look at the head of the man on the right. It's obvious why the frame is chroma combed! This is a revelation to me. I knew that chroma could be messed up due to bad Y/C separation (the rainbow effect), but I was unaware it could just drift apart like this on fast motion. MetricX brought it to light!

Here's the kicker. If I performed the forward match for the frame I got a good match with no combing. So this is an explanation of why forward matching may still be required, even if it is theoretically not required in the absence of such gross stream errors. But we live in the real world and we have to deal with these things. So it looks very much as if the forward match must be restored! I'm sure many of you will be happy to hear that, but for me it means a major re-write.

So, while I assess my options given this new information, please do not deluge me with reports and questions on beta 8 and before, as things are obviously going to change a lot. However, if you have any data or other experience about such chroma screw-ups, it would help me to know about them.

Thank you all for your excellent testing results. I hope you are learning as much as I am from the experience.

EDIT: After further testing it's pretty clear to me that suppressing the forward match test makes field-matching less reliable, and not more reliable (as I expected for theoretical reasons). Now I am seriously considering going back to a three-way match on the bottom field, and if that produces a combed frame, try the additional two matches on the top field. This would be the best possible matching strategy, since it would always output a progressive frame if one could be found. It would also give the best performance for clips with blended fields. Ah well, live and learn. :D

Still, we've made some gains that will carry over to the full 5-way match solution. MetricX is a great combing dectector. The idea of piggybacking combed frame detection on the field matching remains. And of course, the field matching itself is better now. Finally, the pattern guidance is better.

Guest
7th June 2003, 17:57
@HomiE FR

Thank you for the very interesting clip.

What is happening is that there is a clean 3:2 pattern and it fades into a clean 3:2 pattern with a different phase. So, this override file does OK to match the sections (only bothered about the first fade) but for the frames in the middle of the fade there is still a problem (e.g., frame 77):

0,79 cccpp
80,170 ccppc

If you do this you get frame 77 OK:

0,76 cccpp
77 n
78,79 cccpp
80,170 ccppc

So you have successfully provided another example of a case where real world material requires the forward match. Bravo!

It is not guaranteed that this will always help in this kind of case. It helped here because the phases were only off by 1. But, if there is a good match for a frame WE SHOULD DELIVER IT. That is why I am now going to the full 5-way matching strategy. This version of Decomb has taught us a lot, and much of it will be re-used, but it is now withdrawn.

gizmotech
7th June 2003, 18:55
@neuron2

Ok, so now that decomb is being recoded for a new version this doesn't really apply, but ok.

Homie's forward matching on scene changes is ok, however if you want to watch the true ******* child of forward matching anime, go rent disc 2 of Crest of the Stars. Episode 6 has more forward matching in it then any other source I've seen. I've attempted to observe a patern, however it just seems to randomly change between when it decides a forward match would be a good idea.

If nescessary I can try to post a vob for you. pm w/ details if interested.

Gizmotech

Richard Berg
7th June 2003, 23:52
Look at the head of the man on the right. It's obvious why the frame is chroma combed! This is a revelation to me. I knew that chroma could be messed up due to bad Y/C separation (the rainbow effect), but I was unaware it could just drift apart like this on fast motion. MetricX brought it to light!
It's admirable that you're willing to rewrite Decomb to handle situations like this, but speaking from my own habits, I always run something like Guava Comb before Decomb to remove such broadcast artifacts. (Of course, I can't say in advance how much success this would have on your test clip.)

P.S. Did the thread on new hybrid-clip handling disappear, or is it just me?

^^-+I4004+-^^
8th June 2003, 01:31
i've been doing a comparation of different deinterlacers,and i have reached such conclusion:
unlike every (hmm,didn't tried greedy,but..) other deinterlacer,fielddeinterlace is taking the bottom field and interpolating on that (all other deinterlacers use top field to make interpolation)_IF I SAW CORRECTLY!_

(i'm basing the asumption on 2 things i saw:comparing the frame deinterlaced by fielddeint. to other deinterlacers (especially in static/logo areas,and comparing fielddeinterlaced video to the source_looking for same areas as a test patterns)
even the smartdeinterlacer is building interpolation on the TF basis...

(and i guess i've been bashing fielddeint. before was because of this effect)

so,graft here's a question for you:would it be possible to make this an configurable option (to choose what will be the skeleton for the interpolated parts) so anyone can choose........
(although i see that fielddeinterlace is not real "spatial" deinterlacer as it interlaces the complete image..and not combed parts only...unlike it's counterparts)

i'm asking this because i would like to compare this deinterlacer with others,but this thing is keeping me from doing it properly.....(also it's twice as fast as smoothdeinterlace()...heheh),quality is there too,but bottom field?

also to throw this in too (before i am thrown out again...lol!)i have read something about that hybrid challenge,tickers and all(on web of yours),so i wondered do you need any pal "tickers" or you solved that already?(or is it ntsc stuff only?as you see i didn't read it all etc.)
some nice ones over here......

Guest
8th June 2003, 03:19
@I4004

It *is* a spatially adaptive deinterlacer. If you get that wrong how can anyone lend credence to your comparisons?

Why do you think it is important to interpolate only on the top field? So your misinformed comparisons can proceed?

Guest
8th June 2003, 03:25
Originally posted by Richard Berg
It's admirable that you're willing to rewrite Decomb to handle situations like this, but speaking from my own habits, I always run something like Guava Comb before Decomb to remove such broadcast artifacts. (Of course, I can't say in advance how much success this would have on your test clip.)Interesting. I'll try it but I still want to rewrite NGD (New Generation Decomb). Turns out my design is quite flexible and it is not so major as I thought.


P.S. Did the thread on new hybrid-clip handling disappear, or is it just me? Some idiot (who I have spent much time helping in various threads) inexplicably decided to **** on my thread, so because I can't just selectively delete people's posts, I deleted the whole thing. :)

Is there anything in there that you need?

EDIT: Tell you what. Since I'm in a take-no-prisoners mood, I will restore the thread to the Development forum with the **** removed.

Ulm
8th June 2003, 05:17
EDIT: Er, nevermind. I must have missed the post where neuron2 said he was doing a complete rewrite. I'll wait for that...

--

Maybe I'm not understanding something here.

I have some fairly noisy source (VHS), and I think I'm having some problems with pulldown pattern matching. Note that it's animation (Bugs Bunny to be exact), and maybe it's got it's own problems, like bad combing in the capture after decomb, which is *NOT* decomb's fault. I'm using beta8, BTW.

If I use "guide=1, post=2", I get jerky playback. I check the faq and it says not to use post=2. Fair enough.

If I use "guide=1,post=4,show=true", I get fairly frequent 'out-of-pattern' notifications, like maybe 1 out of 10, sometimes more. I got these with 'post=2' as well. No amount of playing with different options (nt,vthresh, etc) seems to change this.

If I use "guide=1,post=0,show=true" and use 'FieldDeinterlace(full=true)' in my script (to take care of the combing), I seem to NEVER get a 'out-of-pattern' message. So far the video looks clean and smooth too.

Am I misinterpreting this? Or does 'post' have that much of an effect on the pattern matching aspect of Telecide()?

Thanks...

Guest
8th June 2003, 05:28
If post is on, it causes interlaced frames to be detected. When an interlaced frame is detected, the clip is declared out of pattern. It has been suggested to not do that. Anyway, it all happens after field matching and pattern guidance, so it's just a display issue. Don't worry about it. I wouldn't use FieldDeinterlace like that. Use post in Telecide.

gizmotech
8th June 2003, 17:26
@neuron2

I had an interesting idea, which "might" solve some of the forward matching issues present with anime. How much work would it be for you to change your default matching from previous current to current next?

It's a really wild idea, but I've been looking at all my anime which fails in decomb (Crest of the Stars and BGC 2040) and they all fail on forward matches, however alot of the previous matches aren't required (I overrode a few just to see).

If it's too much work to try, just lemme know and I'll be quiet, but I think it might be worth investigating. Rather then having a default patern matching 5 way, maybe a default selection which has either previous--current previous--current--next current--next, and make it a required selection in telecide.

Gizmotech.

Belgabor
8th June 2003, 19:07
Hi guys,

I just wanted to tell you that I committed an update to the VDubMod script editor to cvs that has a special mode for decomb override files. So far this is not much improved over the simple text editor the script editor is when not in avisynth mode, but I'm awaiting improvement proposals :)

So far it can (like it already can in non-avs mode)
- Copy the curret frame from the main window
- Copy the selected range from the main window (I changed the way this works for non-avs mode to x-y, here the decomb mode differs by using x,y)

Tell me what you think, whether its worth it and what could be improved :)
(So far theoretically, it will be in the next bug-fix version of VDubMod out asa diverse matroska issues are fixed)

Cheers
Belgabor

gizmotech
8th June 2003, 19:24
@neuron2

Assuming we forget for a second that editors "in-theory" follow a basic set of rules for creating 3:2 pulldown and NTSC/FILM hybrids, this might make an interesting, however slow, option for guide=0.

Currently we know that MatriX is very good at picking up the combing in frames that needs to be deinterlaced, and can return a number value that it calculates after examining a frame for combing (either for field matching or interlacing). As such I'm wondering if it could be used to assist in the detection of a "properly" field matched frame.

Before any interlacing detection is done:

def: cthresh Combing threshold for comb free progressive frames defined by user.

Frame 1
apply matriX, determine number value (check against cthresh)
if !(matrix < cthresh)
field match to N, apply matrix
compare frame 1 MatriX to C->N Matrix. if lower value in C->N then current Frame field match to C->N

Frame 2
apply matriX, determine value (check against cthresh)
if !(matriX < cthresh)
field match to P, apply matriX
field match to N, apply matrix
compare frame 2 MatriX to C->P and C->N. lower matriX wins, match to lower matriX

Frame 3 ... etc...

Now I'm pretty sure this is MUCH slower then how it is currently being done, however given the way MatriX works it would probably be very good at doing this. Assuming a consistent number could be generate from the output of matriX being applied to the frame, in theory the frame with the lowest value would either be a proper match, or would require deinterlacing, as matching a frame requiring deinterlacing would increase the MatriX value.

This would also would perfectly on a scene change as the MatriX value would be astronomical to the frame before the change, and could even match to the next frame.

But I wonder if perhaps something very similar to this is already being implemented.

Gizmotech

EDIT:
I stopped and thought about how this should look with a little more thought:
2 Stage decomb testing:

Relies on MatriX for comb detection on visible areas.

def:
pthresh -- Threshold for determining progressive clean frame.
ithresh -- Threshold for determining interlaced frame on test 2. Should be higher then pthresh

n=0
While not eof {
# Test Current Frame
M_FrameC = MatriX(CurrentFrame)
# If current frame is less then the progressive
# threshold send to prepost
if !(M_FrameC < pthresh) {
if !n=0 M_FrameP = MatriX(FieldMatch(PreviousFrame))
M_FrameN = MatriX(FieldMatch(NextFrame))
# Test previous and next frames MatriX values to original C and the
# lower value is in-theory the matched frame.
if (M_FrameN < M_FrameC) FieldMatch(NextFrame)
if (M_FrameP < M_FrameC) FieldMatch(PreviousFrame)
# Test to ensure that the frame is below the interlacing
# level just in case
if (MatriX(CurrentMatchedFrame) < ithresh)
DeInterlace(CurrentMatchedFrame)
}
n=n+1
}


I hope that makes a little more sense to what I was thinking.
Gizmo

^^-+I4004+-^^
8th June 2003, 22:02
Originally posted by neuron2
@I4004

It *is* a spatially adaptive deinterlacer. If you get that wrong how can anyone lend credence to your comparisons?

Why do you think it is important to interpolate only on the top field? So your misinformed comparisons can proceed?

it is?hmmm,it surely doesn't look that way:it's messing the static,uncombed parts of the image....(in that BF way..it is doing it always (!) , logos, static graphics they all miss pieces....this tends to look bad,making it poor general use deinterlacer..)
i can send (although it'll probably be published) tens of images and fielddeint. messed every logo and graphic in a same old way.....

another thing:because fielddeint. is taking BF,i can't get the exact same frame to compare to other deinterlacers-> fielddeint. always has it's own version of the frame and it's not in phase with the rest of the bunch,as TF and BF of video carry different time stamps.....(but i can clearly see that static areas are messed)
also...you have no justification for using BF on deinterlacing...it's not like BF would hold more image info or so....

yes,i know it's your baby,and you hate people talking against it,but i believe that making it TF deinterlacer would make it much better...heck,it's very visible stuff.......
in my mind field deint. is clearly inferior to the rest of the bunch (virtually all tested deinterlacers use tf,looking good) because of such trivial issue......is it so big job to let the user decide what should be interpolated?

you can get angry every time someone mentions it or put that switch it so at least it could be tested.....


and will i look stupid if i say that i'm using decomb4.00 (in case some changes were made to fielddeint. in meantime)?
in that case i would be very sorry for making a mess......

Guest
8th June 2003, 23:12
@I4004

FD is an intra-field deinterlacer. The others that you are comparing it to are inter-frame deinterlacers. They both have artifacts on some kinds of clips. You claimed that it deinterlaces the entire frame. That is manifestly incorrect. It may deinterlace more than you want but that is not the same thing.

It is immaterial which field gets interpolated. I regret that this complicates your comparisons, but I'm not going to lose any sleep over it.

I do not represent FD as a general purpose video deinterlacer. It was designed to be a fast postprocessor for progressive frames, which some people have found adequate for general use. It is still the only deinterlacer that can avoid affecting progressive frames. Make sure you mention all that in whatever you publish.

I wrote this on another thread: "The thing about FD is that it is designed as a postprocessor for progressive frames. It must avoid touching progressive frames. As such it must be an intra-field deinterlacer, which brings with it certain artifacts that can be avoided with an inter-field deinterlacer.

Although people have found FD adequate for general video deinterlacing, there are better solutions in that problem domain, especially TomsMoComp. It is unfair to compare the two in that domain, as some misinformed people are wont to do."

You are so grossly misinformed that if you publish anything you will be doing a serious disservice to your readers.

And your suggestion that I can't accept criticism is insulting to me. This entire thread gives the lie to that silliness.

Please take follow-ups to PM, please.

Guest
8th June 2003, 23:56
Originally posted by gizmotech
I had an interesting idea, which "might" solve some of the forward matching issues present with anime. How much work would it be for you to change your default matching from previous current to current next?

It's a really wild idea, but I've been looking at all my anime which fails in decomb (Crest of the Stars and BGC 2040) and they all fail on forward matches, however alot of the previous matches aren't required (I overrode a few just to see).

If it's too much work to try, just lemme know and I'll be quiet, but I think it might be worth investigating. Rather then having a default patern matching 5 way, maybe a default selection which has either previous--current previous--current--next current--next, and make it a required selection in telecide. gizmo, you are showing some acute thinking here! I had the very same idea this morning. It is not at all hard to change. But I was able to find scenarios that required the previous match. I am assessing now whether there are less of those than the forward ones. If so, it would be a good idea. By the way, I've backed off the 5-way match. Things are very complicated but I'm reaching clarity on the issues. The VOBs you sent me have the dreaded blended fields syndrome; that is the reason for the success of some forward matches. I'm going to write up my findings in my website journal and then we can discuss our options. A point about doing p, c, and n matching is that it can produce extra duplicate frames and missing frames. I'll demonstrate that in the journal. I'm tending toward offering the user choice of p/c matching, c/n matching, or p/c/n matching. Let the user decide his best evil!

When you read my journal (when completed), I think you'll see the hole in your algorithm.

gizmotech
9th June 2003, 00:06
Hmm, I figured it would probably result in some bad frames, and I'm looking at my source thinking that at this point I would chose the "lesser" evil and take c/n matching and find the p matchs manually.

However, what about that little snipet of Psedo-Code I wrote? Does that have any merit as a slow p/c/n option? Maybe I'm missing something in how I figure it would work but my idea "in-theory" would match a very large number of frames with out worrying about any patern guidance.

Gizmotech

Guest
9th June 2003, 00:19
Originally posted by dsmith
However, it also explains why I'm having trouble with getting it to recognize when it needs to do the deinterlacing. You're requiring an additional comb match to the left or right of a detected pixel. The combs that I have the most trouble with are usually set up somewhat like this:

xx
xxxx
xxx
xxxxx
xxxx
xxxxxx
xxxxx OK. Well anyway, my most recent implementation removes that denoising. :)

I have to move the vthresh down to around 3 or so before it will push those frames over 48.That could also be because chroma was not being considered.

My question is, what sort of artifacts show up if you look for adjacent combed pixels above and below? It leaves isolated one-line combs.

And what about checking the diagonally adjacent pixels, to find the stairstepping problem? (assuming you're only checking every other line, perhaps require either TL+BR or TR+BL adjacent pixels be combed) Edge-directed interpolation is something I have planned.

Thank you for the results that you appended. Nice to know it's not all bad. :)

Guest
9th June 2003, 06:03
The rewrite is completed and working well on the clips submitted to me. I have to revise the docs (oh, I just love doing documentation!). Beta 9 coming soon.

Summary: It matches current and next by default, but you can optionally enable previous, current, and next (triple=true). The three-way matching carries no computational penalty because the previous match is already calculated as the next match for the previous frame! Three-way matching may emit spurious dups and/or omit frames, but it can do better with blended-field clips. It is no longer necessary to link the matching with vthresh (previously the forward match was tried only when the frame was detected as combed).

I can't think of any way to improve this matching strategy.

When I post the beta, I'll post the scripts for the clips submitted to me.

Guest
9th June 2003, 06:34
Originally posted by InfoCynic
From a theoretical standpoint, does pattern guidance really have to be tied to the progressive/interlaced decision? No. And with beta 9 they will be decoupled.

Guest
9th June 2003, 06:46
Originally posted by Mentar
Now my question: Shouldn't the "better" p or c value also result in a better vmetric result?!? Another acute thinker! :)

Strangely enough, my code has a #define called SEPARATE. When SEPARATE is undefined, exactly the same metric is used for field matching and for combing detection. When it is defined, slightly different metrics are used. Currently it is defined, so you'll get the results you do. I'd like to have them be the same, but when I do it, some important test clips in my suite start matching wrong. I'm still investigating the issues there.

After lots of manual tinkering, it seemed obvious that the vmetric was awesome. I'm happy that you find it to be an improvement.

So here's my second question: Wouldn't it be feasible to code a Decimate mode which generates the vmetric value from _all 3 matches (p, c and n) and then selects the frame with the best vmetric? I wouldn't mind if such a mode was slow as a snail, it would ALWAYS be faster than manual interaction necessary for the perfectionists. Yes, of course. Beta 9 will offer it as an option and my journal will talk about the pros and cons.

Guest
9th June 2003, 06:56
Originally posted by gizmotech
However, what about that little snippet of Pseudo-Code I wrote? Does that have any merit as a slow p/c/n option? Maybe I'm missing something in how I figure it would work but my idea "in-theory" would match a very large number of frames with out worrying about any patern guidance.
It's effectively the same as what I am doing, but I prefer not to require two thresholds. The pthresh one isn't really needed as far as I can see.

HomiE FR
9th June 2003, 10:31
@neuron2 : Standing by... :) Beta 9 seems really promising. I'm happy that my clip is of any help for NGD. Moreover this thread (along with your journal) is very interesting to understand better how such a field matching algorithm / deinterlacer is working. Thanks a lot for sharing it with us ! (maybe I already said that but...)

gizmotech
9th June 2003, 13:55
Hmm... The only reason I was working with 2 threshold was to attempt to filter out clean progressives first (maybe speed up the process a little), but if it's not nescessary then by all means drop it like a stone..

And I agree w/ HomiE FR. This thread and your journal are very useful tools and I understand alot more now with what my video clip is doing then I did before.

Many thanks,
GizmoTech
PS And it's actually making it through my clips!?! W00T!

Defiler
9th June 2003, 16:14
This comment isn't a reply to any particular post in this thread, but I would just like to mention that I plan on using the deinterlacer that yields the best results, regardless of speed. If next-gen Decomb requires some wild 16-way brute force technique, that won't stop me from using it.
I've learned a great deal from this thread. Thank you for making this kind of development discussion public.

Guest
9th June 2003, 16:42
Couple of new developments...

1) Forward matching is not a panacea after all. See the Uncomb thread for details and what I finally plan to do with the matching. I think it's better to use forward matching but it doesn't catch all the cases. We'll still need the comb test and then consider the backward match. There will still be an option to do the triple test all the time, however.

2) I realized that I could use inter-field to test for a combed frame but then use inter-frame for actual deinterlacing of frames declared combed. Doing that would eliminate the much-maligned artifacts of field deinterlacing. Tom (trbarry) has agreed to allow me to use the TomsMoComp code for the postprocessing. I believe this will be a good thing to do, especially as it brings along the edge-directed interpolation that is one of the best things about TomsMoComp.

So beta 9 will be delayed. ;)

gizmotech
9th June 2003, 17:03
Delayed !?! GAH!

/me rolls over and dies.

j/k

So given this information don't expect a journal entry until your magic is complete?

Gizmotech.

Guest
9th June 2003, 17:38
If you know me, you'll know that things don't get delayed for long.

If all goes well, maybe something will come out tomorrow. Could be a journal entry tonight, although what I would say is already sprinkled about here and there in the forum.

Guest
10th June 2003, 13:30
Here is beta 9:

http://shelob.mordor.net/dgraft/decomb/decomb500b9.zip

Please read the tutorial again, as the use of vthresh has changed again.

This version does 2-way matching by default (current and next). If a frame is combed after 2-way matching and post > 0, then the backward match to the previous frame will be tried. If you want 3-way matching all the time, set triple=true.

Here is what I used for HomiE FR's clip:

Telecide(order=1,post=2,guide=1,vthresh=40)

Here is what I used for gizmotech's scene1 clip (giz, you had order set wrong in the scripts you sent!):

Telecide(order=0,post=2,triple=true,guide=1,vthresh=30)

My next step is going to be to attempt to convert the postprocessing to use the TomsMoComp code (with thanks to trbarry).

HomiE FR
10th June 2003, 14:43
Thanks neuron2, you're fast as always. :) I'll try beta 9 as soon as I come back home this evening. If it can handle the latest clip I sent you, I think Decomb is really close to perfection, at least on the material I'm currently working on.

Moreover your last sentence is also promising, I'm looking forward to beta 10 (so much work since beta 1 :eek: ).

Regards,
HomiE FR

Syncroniza
10th June 2003, 15:04
Originally posted by neuron2
2) I realized that I could use inter-field to test for a combed frame but then use inter-frame for actual deinterlacing of frames declared combed. Doing that would eliminate the much-maligned artifacts of field deinterlacing. Tom (trbarry) has agreed to allow me to use the TomsMoComp code for the postprocessing. I believe this will be a good thing to do, especially as it brings along the edge-directed interpolation that is one of the best things about TomsMoComp.

One question @neuron2:
These changes in postprocessing would affect both functions, Telecide() and FieldDeinterlace(), wouldn`t it? Or did I get something wrong here...

Anyway, your idea really sounds great. The adaptive, inter-field deinterlacing is a very clever way for dealing with mostly progressive clips that contain only a few interlaced scenes. But the deinterlacing proccess itself still creates some artifacts, as you mentioned it. There is for example the "marching-ants"-problem with letterboxed videos or the problem that tv-station logos/still areas are too much affected by deinterlacing (I hope I'm writing no nonsense...).
So, IMHO with this inter-field testing/inter-frame deinterlacing your decomb package would become perfect!

gizmotech
10th June 2003, 15:09
@neuron2

Is it posible for a clip to have 2 different orders within it?

*this doesn't apply to the clips I sent you

I'm looking at an episode with a lot of space scenes and they seem to be horribly combed when using order 0, however with order 1 they look perfect. (which was how I determined order 1 was the correct value)

I've found the guide=0 3 way matching to be VERY good. The only instances where it fails is where there is other "noise" in the scene which when field matched creates just a little more noise then the C match. I have a number of n match scenes which have numbers like:
84815,82202,83526 ... and it's the n match which is required. Thankfully with a little nt adjustment everything is fine. But you have to be very careful apparently as applying to much nt can make the triple match do strange things on noisy scenes.

Things look pretty good this time around, I'm able to play with the setting and generate better results overall from field matching then beta 8.

ohh and ps: overrides aren't working again :P

EDIT:
I've also found another interesting scenario which it highly improbable. I've got a combed frame (I've found a few) which generates an identical MetriX to the previous frame, and on every one of these it should have matched forward, however it couldn't as the forward match generated a ridiculous matrix.

Defiler
10th June 2003, 17:25
Time for MetriX to be an SHA1 hash? Heh.

Piper
10th June 2003, 17:28
Originally posted by Syncroniza
One question @neuron2:
These changes in postprocessing would affect both functions, Telecide() and FieldDeinterlace(), wouldn`t it? Or did I get something wrong here...

Anyway, your idea really sounds great. The adaptive, inter-field deinterlacing is a very clever way for dealing with mostly progressive clips that contain only a few interlaced scenes. But the deinterlacing proccess itself still creates some artifacts, as you mentioned it. There is for example the "marching-ants"-problem with letterboxed videos or the problem that tv-station logos/still areas are too much affected by deinterlacing (I hope I'm writing no nonsense...).
So, IMHO with this inter-field testing/inter-frame deinterlacing your decomb package would become perfect!

I'm also interested in how your latest developments affect the "marching-ants" side-effect currently present in FieldDeinterlace. I've read the latest docs, and FieldDeinterlace doesn't appear to be getting much attention (in that area anyway). Could it be that Telecide may become more useful as a general purpose deinterlace tool in current & future versions?

Guest
10th June 2003, 18:11
Originally posted by Syncroniza
One question @neuron2:
These changes in postprocessing would affect both functions, Telecide() and FieldDeinterlace(), wouldn`t it? Of course.

Anyway, your idea really sounds great. The adaptive, inter-field deinterlacing is a very clever way for dealing with mostly progressive clips that contain only a few interlaced scenes. But the deinterlacing proccess itself still creates some artifacts, as you mentioned it. There is for example the "marching-ants"-problem with letterboxed videos or the problem that tv-station logos/still areas are too much affected by deinterlacing (I hope I'm writing no nonsense...). Yes, yes, of course. That is why I am contemplating changing things.

So, IMHO with this inter-field testing/inter-frame deinterlacing your decomb package would become perfect! It will be better but it will never be perfect. :)

Guest
10th June 2003, 18:31
Originally posted by gizmotech
Is it possible for a clip to have 2 different orders within it?Sure. But it would not be playable, because the AVI stream cannot specify the order to be displayed, much less change it on a per-frame basis. You can easily make such a clip, but it doesn't play correctly. No sane application would create such a file. Here's an analogy: "Is it possible to make a car with square wheels?" Sure, but it wouldn't be drivable.

I'm looking at an episode with a lot of space scenes and they seem to be horribly combed when using order 0, however with order 1 they look perfect. (which was how I determined order 1 was the correct value) Another way is to get the *first* frame's flags byte from the D2V. If it is 2 or 3, the clip is order=1. If it is 0 or 1, the clip is order=0.

I've found the guide=0 3 way matching to be VERY good. It's not generally a good idea unless you have some serious stream problem such as gross field blends. Three-way (triple=true) will usually make a clip jerky. For anime, it's harder to notice it, but for non-anime, it's often quite visible.

I have a number of n match scenes which have numbers like:
84815,82202,83526 ... and it's the n match which is required.I am still tweaking the field difference metric. It may get better.

ohh and ps: overrides aren't working again :PI cannot duplicate this; please elaborate.

I've also found another interesting scenario which it highly improbable. I've got a combed frame (I've found a few) which generates an identical MetriX to the previous frame, and on every one of these it should have matched forward, however it couldn't as the forward match generated a ridiculous matrix. It would be possible to make the "desperation" backward match optional. Would that help? It would cause some scene changes to be deinterlaced instead of matched clean, however. Anyway, if the forward match gets rejected for too much combing, do you really want it, since it will get creamed by the postprocessing?

Guest
10th June 2003, 18:51
Originally posted by Piper
I'm also interested in how your latest developments affect the "marching-ants" side-effect currently present in FieldDeinterlace. I've read the latest docs, and FieldDeinterlace doesn't appear to be getting much attention (in that area anyway). Could it be that Telecide may become more useful as a general purpose deinterlace tool in current & future versions? There are four main areas I am trying to improve in Decomb 5: 1) Blind field matching, including the field differencing metric and the actual matching strategy (which matches to consider). 2) Combed frame detection, which affects field matching ("desperation") and choice of frames to postprocess. 3) Pattern guidance, which affects field matching. 4) Postprocessing. The current beta includes code for areas 1-3, and we are currently refining areas 1 and 2. Soon, I will start addressing areas 3 and 4 in detail. My guess is that the postprocessing will be moved to an external filter that can read hints from Telecide (informing about which frames are combed). Then a suite of different postprocessing filters will be made available that can read the hints and deinterlace selectively. These might include: FieldDeinterlace, TomsMoComp, SmartDeinterlacer, MetricX, etc. But Telecide itself probably will also retain one good all-purpose postprocessor. What that will be, we (myself and anyone else who participates here) haven't decided yet.

gizmotech
10th June 2003, 21:09
(as applies to override)I cannot duplicate this; please elaborate.


Would it be possible for you to have telecide generate an error if you happen to specify an override file which isn't there? (silly me named the file incorrectly in the avs)


It would be possible to make the "desperation" backward match optional. Would that help? It would cause some scene changes to be deinterlaced instead of matched clean, however. Anyway, if the forward match gets rejected for too much combing, do you really want it, since it will get creamed by the postprocessing?


It might actually, as tracking down scene changes would be a lot easier then tracking down incorrect previous matching. Though we would have to test and see if that is the case.

Will continue w/ more testing now.

Gizmotech.

dsmith
11th June 2003, 03:43
Checked those segments I'd looked at earlier again using beta 9. The results are somewhat improved. I should probably note that these scene sets covered roughly 300 to 500 frames each.

Ep. 1 of BGC2040:

v4 override set 1: 5 corrections
v5 override set 1: 0 corrections [was 4]

v4 override set 2: 8 corrections
v5 override set 2: 0 corrections [same]

v4 override set 3: 7 corrections
v5 override set 3: 0 corrections [same]


Ep. 19 of BGC2040:

(expanded the selection I looked at to make sure I was covering the same amount in each test)
v4 override set 1: 5 corrections
v5 override set 1: 3 corrections (4 if chroma=true) [selection changed]

v4 override set 2: 6 corrections
v5 override set 2: 0 corrections (1 if chroma=true) [was 1]

v4 override set 3: 38 corrections
v5 override set 3: 14 corrections (4 if chroma=true) [was 7]


The interesting bit is how things change with chroma=true. For the most part things actually got a little worse using that flag, but the last set showed significant improvement. An override setting for segments where you want chroma checking on may be useful, though I'm not sure how much so in the grand scheme of things.


I'm noticing several points where combed frames are getting picked where, while they have the lowest overall score (is there a name for it?), they have significantly higher vmetrics. EG: P and N have vmetrics of 10 or 11, whereas C, which is picked, has a vmetric of 16 or 22, but has a lower score by about 10% (eg: 52000 vs 56000 or 57000). Possibility: if the winning frame's score is within ~10% (say 1/8) of the other frames, but the other frames have lower vmetrics by some threshold Q, pick one of the other frames instead.

Sample size for this suggestion is very small, so feel free to shoot it down :)


--
David

gizmotech
11th June 2003, 03:50
David, What frames on the episodes was it?

I'm interested in testing with some guide 0 matching and see how they turn out.

Gizmotech. Feel free to pm me.

gizmotech
11th June 2003, 04:49
@neuron2

Heyo, This is gonna sound like a lame request but is there any way for you to occupy a few less lines with the show=true output?

I realize that we all enjoy having our tag on our own things (myself included) however if the top 3 lines of the show=true output were to disappea it would free up alot of screen space for viewing the image.

But this is just a silly little request so feel free to ignore it.

Testing wise, it would appear that the meticx only fails truely miserably on ridiculously noisy scenes (I can provide vob if nescessary), but otherwise appears to be working much better now.

Oddly enough, for anime at least I'm finding that guide=0 to be very effective at determining the combed frames. It might be worth mentioning that in the faq that though guide=0 can cause jerkiness on FMV on Animation it can very accurately decomb small combes.

Just my 2 cents.

GizmoTech.

Guest
11th June 2003, 05:39
Too late to reply to posts tonight. :)

But I wanted to mention I made a new journal entry about matching strategies. Feedback or other ideas about it will be gratefully received.

gizmotech
11th June 2003, 13:21
EDITED July13th.
Ok, I'm stupid as all Fudge. Ignore what was written here. This did not work (shoulda removed this long time ago).

@neuron2

You're a god. nuff said.

Gizmotech.

HomiE FR
11th June 2003, 17:04
@neuron2 : First of all, thanks for this new beta ! :) I'm still playing with it, particularly the field matching algorithm. I'm using post=0 or post=1 (post=1 is better since it computes vmetric which can be useful to improve bad scene changes when post=0 and triple=false).

Indeed, triple=true makes pannings jerky on my anime source. I can't probably use hints=true since I don't use guide=1 for the time being. I have some problems with pattern matching (guide=1), since I often have mouthes of characters which are combed on my source. Decomb has amazing results, but when only the mouthes are moving sometimes I get "combed mouthes". This happens quite often when guide=1 but also when guide=0.

And that leads me to dsmith's suggestion :
I'm noticing several points where combed frames are getting picked where, while they have the lowest overall score (is there a name for it?), they have significantly higher vmetrics. EG: P and N have vmetrics of 10 or 11, whereas C, which is picked, has a vmetric of 16 or 22, but has a lower score by about 10% (eg: 52000 vs 56000 or 57000). Possibility: if the winning frame's score is within ~10% (say 1/8) of the other frames, but the other frames have lower vmetrics by some threshold Q, pick one of the other frames instead.

I have noticed the same problem, and I think that this idea sounds right. I don't know what it's like speed-wise, but it would make Decomb job PERFECT. I have already only a few frames over hundreds (or even thousands) which are still combed after field matching (guide=0 post=1 vthresh=25) but I believe that these frames where the score is lower but the vmetric is higher are the last ones which are wrongly matched by Decomb beta 9.

Thanks again for your work.

HomiE FR

HomiE FR
11th June 2003, 17:43
I'm back (who said too early? :D )

I made a little example so you can see what I mean by "combed mouthes". I used the same anime source that I gave you in order to do some tests.

First of all, here is the Telecide line that I used to do the screenshots :
Telecide(order=1,guide=0,post=1,vthresh=25,show=true)

Then, here is the table where you can see the score, the vmetric and the visual aspect (ok means progressive, and combed means... combed!) for each possible field matching (previous "p", current "c" and next "n").
|--------|--------|--------|
| p | c | n |
|---------|--------|--------|--------|
| score | 116532 | 116212 | 114913 |
|---------|--------|--------|--------|
| vmetric | 13 | 13 | 22 |
|---------|--------|--------|--------|
| visual | ok | ok | combed |
|---------|--------|--------|--------|

And to add some nice pictures to it, here are the images for each possible decision :
Default (using n field matching) (http://perso.wanadoo.fr/homie.fr/using_n.jpg)
Overriding Decomb decision (using c field matching) (http://perso.wanadoo.fr/homie.fr/forcing_c.jpg)
Overriding Decomb decision (using p field matching) (http://perso.wanadoo.fr/homie.fr/forcing_p.jpg)

As you can see, the default Decomb field matching decision is wrong, even though it chooses the lowest score between c and n (n in this case). This leads to think that the score algorithm isn't perfect yet (although it's very powerful, I repeat that such examples are rare, but I believe you want Decomb to handle it right, am I wrong ? :) ).
However, the vmetric seems to be more clever, since it seems to know better whether the result will be combed or not : so why not use the vmetric field matching algorithm in such cases (when the different scores are to close to be sure that there isn't any mistake) or even on each frame? I love vmetric ! ;) I really believe that this could end my problems with such frames where there is very little motion (for instance here only the mouth is moving).

I hope this little example can be useful to you, if you want the source I will be happy to send it to you.

HomiE FR

Guest
11th June 2003, 22:02
Gentlepeople,

Here's what I need to iron out the last wrinkles in the matching. I need a 3-frame *SOURCE* hufyuv with the subject frame in the middle. It should be a frame that with guide=0, post=1 shows a mismatch between the field match scores and the vmetric scores, as in HomiE's example above. You can mail them to me at neuron2@attbi.com. Please specify the field order because I won't be able to get it reliably with only 3 frames.

Thank you!

Guest
11th June 2003, 22:16
Originally posted by HomiE FR
why not use the vmetric field matching algorithm in such cases (when the different scores are too close to be sure that there isn't any mistake) or even on each frame? I have experimented with using vmetric exclusively. But there is an important torture clip in my suite that matches badly with only vmetric:

vmetric: 11 bad matches
uncomb (trbarry): 5 bad matches
decomb 5: 3 bad matches
decomb 5 + nt=10: 0 bad matches!

What I need are the source clips as asked for above, and as many as possible.

Some kind of hybrid fuzzy-logic choice may be best, but I need a large sample of cases to optimize it.

Guest
12th June 2003, 02:02
Here is a little something for you guys for being so helpful.

It is a TomsMoComp-based postprocessor for Decomb 5.

Read the included text file for details. It allows you to run TomsMoComp on only the frames that Telecide declares as combed.

http://shelob.mordor.net/dgraft/decomb/tmcpost500b1.zip

Thanks to Tom (trbarry) for giving his permission for me to do this!

Defiler
12th June 2003, 02:45
That is.. What's the word.. "Freaking Cool"
I have just the thing to try it with, as well...

Guest
12th June 2003, 04:24
Originally posted by Defiler
That is.. What's the word.. "Freaking Cool"
I have just the thing to try it with, as well... I made one small correction to the help file for those who have already downloaded TMCPost. You have to have post=1 in Telecide to get the hints. I erroneously said post=0 or post=1.

Telecide(order=1,post=1,hints=true)
TMCPost(tff=true,search=5,vf=false)

Note, it won't work with Decomb 4 because the progressive/interlaced flag is not hinted.

HomiE FR
12th June 2003, 06:19
@neuron2 : I dropped you a mail. :)

EDIT : I've forgotten to write the field order : it's top field first (order=1 using Decomb).

Guest
12th June 2003, 12:57
Thanks, folks, those little mismatch clips are very helpful.

I have found that half of them get matched with nt=10. Note that beta 10 will use this as a default. Investigation continues on the others.

bouis
12th June 2003, 22:34
I've been using nt=10 for a while now and I've had excellent results with it.

gizmotech
13th June 2003, 00:29
Another Quick Question,

Does guide=0 currently provide any information through the "hints" argument or is that still strictly a guide1-3 thing?

Gizmotech.
PS: Sending a 5 frame huffy tonight to add to your test suite. Current Decomb does some very interesting things.

EDIT:
Nevermind. me being stupid.

Guest
13th June 2003, 04:08
Originally posted by gizmotech
Does guide=0 currently provide any information through the "hints" argument or is that still strictly a guide1-3 thing? EDIT:
Nevermind. me being stupid. Ha ha. I'm stupider than you. Yes, hints are now controlled by the hints option; you don't have to have guide enabled. But of course you won't get the in-pattern hint, only the progressive/interlaced hint.

gizmotech
13th June 2003, 04:15
I wonder if after you've finished doing a full decomb with guide=0 if there could be some way to check guide=1 and send that information through to decimate? Because I know it should be relatively close to that guide, but the pattern matching is better w/ guide=0.

But I'm just being silly now.

**Shouldn't try to encode after a few cold ones.

Gizmotech.
PS: huffy's are comming in a minute.
Huffy's are all order=1

HomiE FR
13th June 2003, 07:19
Hi all,

I just found an example where nt=10 is not enough to make Decomb detect the right field matching. It is, as always, a "combed mouth" artifact. vmetric succeeds, but there isn't any big margin (23 for the right matching instead of 24 for the wrong matching).
But as dsmith pointed it out, these problems happen when the margin between p, c and n scores is very thin.

I'm not at home now but I'll send you the 3-frames huffyuv clip as soon as I get back home (it's the same source as before, so top field first ie order=1).

HomiE FR

Guest
13th June 2003, 08:21
Originally posted by gizmotech
PS: huffy's are comming in a minute.
Did they by any chance have a subject line like "RECLAMAZIONE"? If so, I deleted them as suspected viruses. If those were from you, please use a subject line that I can identify. If they weren't from you, then forgive me mentioning it.

gizmotech
13th June 2003, 12:52
No, it had the subject line "huffy's" iirc.

Actually there should have been 2 emails, as the first one I got to typing, sent it, then realized I forgot to attach things to it :)

Gizmotech

Guest
14th June 2003, 00:30
Originally posted by gizmotech
@neuron2
This is gonna sound like a lame request but is there any way for you to occupy a few less lines with the show=true output? Pretty lame, I agree.

Use debug=true instead of show=true and you'll be able to see all the video.

gizmotech
14th June 2003, 16:55
Hmm... I've encounterd a very strange problem.

I'm currently attempting to use decimate mode=1 however I can't get it to deciamte at this point. I've tried 0,2,3 and they all decimate fine down to around 36000 frames, however when activating mode=1 it doesn't perform any decimation (final frame count is the original 45000). Now I've tried commenting out every line from my AVS so that is's a minimal avs w/o a telecide line, just a decimate line and it still will not decimate in mode=1.


LoadPlugin("C:\newfilters\mpeg2dec3.dll") (version 1.08)
LoadPlugin("C:\newfilters\decomb5b9.dll") (I rename for clarity)
mpeg2source(d2v="C:\bloodylongpath\episode5.d2v")
YV12toYUY2(interlaced=true)
#Telecide(line w/ lots of options)
Decimate(cycle=5,quality=3,mode=1)


Now as is, it should just perform a mode 1 decimation, however I cannot get it to do this. I've tried it on 2 d2v files, w/ 2 version of mpeg2dec3, however I cannot get it to activate.

Many thanks,
gizmotech.

InfoCynic
14th June 2003, 17:29
Gizmo? Have you read the manual? :)

Mode 1 should be used for hybrid material that's mostly video, not film. The FILM portions are ramped up to 29.970 by inserting an extra frame after deleting the dupe (manual explains better), the VIDEO portions are passed through untouched. The final frame count WILL equal the original, because that's how it works!

Next time, someone's going to be a lot ruder and just tell you to RTFM... :)

P.S. Isn't it better just to use mpeg2dec.dll and not do the extra YV12toYUV2?

gizmotech
14th June 2003, 18:31
/me slaps forhead.

Ignore my foolishness.

Wait, Ok now it all makes sense.

Probably, but it doesn't seem to be any faster then dec3 w/ the convert statement.

Guest
14th June 2003, 18:57
It may not seem faster, because mpeg2dec has to convert the color space anyway. But there is some small overhead from having another filter in the chain, as well as an extra unnecessary load on the Avisynth frame cache.

gizmotech
16th June 2003, 20:36
@neuron2

Overriding gthresh. As we discussed earlier, gthresh is a limiter, mean when I receive a mismatch of 8.25% and set the gthresh to 8 it "should" use the appropriate guide value instead of the mismatched frame? Am I understanding this part correctly? (if not ignore next part)

I'm wondering then 2 things:
1) can it be made to accomodate decimal values? currently I receive an error when I enter in 8.2.
2) If I set it to 8 it should stay in pattern, however currently it doesn't, however if I set it to 7 is stays in patern. (the same applies to 0.25% and gthresh=0)

I'm wondering if I understand this correctly, and if so is my second question reproducable in your tests?

Thanks,
GizmoTech.

Myrsloik
19th June 2003, 00:10
Would it be possible to have an option added to decomb that displays the vmetric for all possible matches and not only the current one? This would really help if you attempt to do something like the decomb log parser by cuisinart since it then would be possible to calculate how the matches would have been with a different vthresh after the log is made and lots of time could be saved that way.

Guest
19th June 2003, 02:06
I'll be coming back to Decomb 5 after I finish off DGBob(). I will add the display of all vmetrics and consider the other requests as well. When I resume the development, we will shake down pattern guidance. I'm really happy with the blind field matching right now. I don't see any good way to improve it, and it does very well on many of my torture clips that previously required pattern guidance to be rendered correctly, and which now match correctly with just the blind matching.

Milkman Dan
20th June 2003, 05:51
That's the error I get when I try to use TMCpost instead of the built in postprocessor. I know I'm doing something stupid, but I can't figure out what.

Here's my script:

MPEG2Source("D:\vobSource\testFragments\KareKano.d2v").ConverttoYUY2(interlaced=true)
Telecide(order=1,guide=0,post=1,nt=10,hints=true).TMCPost(tff=true,search=5,vf=0)

So what stupid thing am I doing?

EDIT: I'm using Beta 9, if that makes a difference.

Guest
20th June 2003, 06:34
Use vf=false or vf=true.

My bad, the help file is ambiguous. Sorry for the inconvenience.

gizmotech
20th June 2003, 15:57
@neuron2

Just a quick idea for when you come back to decomb, would it be possible to add adjustable triple=true variable in the override?
As you've noted, triple=true will cause all types of evul on pans and similar slow motion movements, however on "flapping Mouth's" it works wonders. As such, if I could turn on and off triple=true via override it would save me alot of time. (identify a pan is far quicker then identifying mouth combes for previous matches)
Though this doesn't actually fix the problem of the jerkiness in those types of motion scenes it would make the overrides easier.

Thanks GizmoTech

Guest
20th June 2003, 18:46
Originally posted by gizmotech
Just a quick idea for when you come back to decomb, would it be possible to add adjustable triple=true variable in the override? Yes. Thank you for the suggestion.

Milkman Dan
21st June 2003, 01:36
Originally posted by neuron2
Use vf=false or vf=true.

My bad, the help file is ambiguous. Sorry for the inconvenience.

No problem. Thanks for the response, and all the great work. I can't wait until you wrap this baby up with some nice YV12 action.

Guest
23rd June 2003, 05:09
OK, after my little sabbatical, I am back to work on Decomb 5, attacking pattern guidance, which, I confess, currently is poor in Decomb 5.

But don't worry! I have stumbled onto a really effective strategy and tested it successfully for 3:2 pulldown guidance. It hardly ever falls out of pattern except at some scene changes, where it is expected.

I just have to add support for 3:2:2:3:2 and 2:2 and then I can release a new beta. I also want to write it up in my journal. Assuming everyone is happy with it, then we move on to postprocessing and additional color spaces.

Obi Wan Celeri
23rd June 2003, 07:25
Wow, thanks for Decomb and now for DGBOB :)

I don't know about other places in the world but up here in Quebec a lot of local titles are interlaced instead of progressive and the classic solution has always been to blend the whole thing together (giving some rather horrible conversions). The same thing happens to anything being brought in from europe (conversion from PAL to NTSC). Anyways DVD2AVI is conviced those movies are interlaced. But now with DGBOB the results are just FANTASTIC :)

Excellent work Neuron2 :)

Now here's a little suggestion.

There are quite a few decomb plugins lying around on my computer ... and there's no real (easy) way to identify what version they are ... Do you think it would be possible to add a version number that could be read by checking on the DLL's properties?

Oh and does NTSC really stand for Never The Same Color? ;)

cipher
23rd June 2003, 11:26
There are quite a few decomb plugins lying around on my computer ... and there's no real (easy) way to identify what version they are ... Do you think it would be possible to add a version number that could be read by checking on the DLL's properties?

Obi, enabling "show=true" and previewing in vd/vdmod, you will see the version numbers.:)

gizmotech
23rd June 2003, 15:11
@Obi, Alternatively you could just rename the files themselves.

I have 11 different versions of Decomb sitting in my filters folder, all the 5 betas, 4.1b2 for 2.5, and the old 4 for 2.0x

@neuron2

I look forward to reading the journal entry. This current method for patern guidance in 3:2 pulldown, will it be able to "intelligently" switch to between ccppc and ccnnc guidance? Currently the only solution to source swich essentially perfrom this switch is to enable triple=true, and compensate for pans/motion sequences manually. Not that this is hard to do, as I have to make an override for those sources anyways ... **Kicks the EVUL COTS Source** nich :)

At any rate, I look forward to seeing this in action.

GizmoTech

**Also going to start some experimentation w/ decomb 5 on *Almost* FILM source. You know those evul film sources that are 98% and come out after a forced film with a few interlaced scenes. Assuming there isn't noise, the guide=0 w/ triple=true could work wonders on these sources for cleaning up the few remaining 100 matchable frames.

Obi Wan Celeri
24th June 2003, 23:19
Hey thanks @Cipher and @Gizmotech!

Renaming DECOMB.DLL is a great idea, I should do that :)
And using "show=true" is equally good ...

But since @NEURON2 is such a compulsive programmer (eheheheh) I think DECOMB is a good candidate for proper identification (if it's not too much of a hassle and it can be done easily).

Oh by the way, "show=true" does not always show the proper version ... 5b6 had that problem (if my memory serves me right).

@Neuron2:
Sorry I could not come up with a better suggestion :)
Some of you guys out there are seriously smarter than I :)
... and just reading your journal overloads my CPU ehehehe

Guest
25th June 2003, 04:31
Decomb 5.0.0 beta 10 is now available:

http://shelob.mordor.net/dgraft/decomb/decomb500b10.zip

This version improves pattern guidance. Please read the following notes carefully:

1. If you have a non-hybrid, you'll have post=2/3. When a frame is declared combed with post=2/3, pattern is NOT declared lost, unless no prediction can be made (mismatch = 100%) or mismatch exceeds gthresh.

2. If you have a hybrid, you'll have post=4/5. When a frame is declared combed with post=4/5, pattern IS declared lost.

3. In any post mode, if a backward match is chosen, pattern IS declared lost.

4. There is no guidance for patterns with backward matches. They should occur only at edit cuts or other pathological cases, where clearly pattern is lost.

If this new handling holds up, we'll move on to fix up postprocessing and then do the YV12 support.

HomiE FR
25th June 2003, 15:09
Thanks again for this new build! :) It was a "long" time (for me I mean) since the previous one.

Sorry to bother you, but didn't you say that you would give the possibility to see the vmetric for each possible field matching instead of only the chosen one? It's no real problem if we only have the chosen field match vmetric, but it could be useful to choose the right field matching when a bad one is done (very rare, but I like perfection :p )

Thanks again for your work.

Guest
25th June 2003, 16:31
Let me concentrate on the major functionality right now. I'll clean up the other stuff at the end.

How is the new pattern guidance working for you?

BTW, I have the new postprocessing done and a new beta will be along shortly.

gizmotech
25th June 2003, 16:50
Hi neuron2.

Before you release beta 11 can you please add the ability for patern locking? I'm currently applying both beta 9 and 10 to a source with (essentially) perfect ccnnc source, and 98% of the time decomb is correctly patern matching, however it will also go for long spells of incorrect patern matching based on 0.05-0.25% patern mismatch causing all types of combe errors. Setting gthresh=0 is currently not stopping this.

So far it looks good, but because I can't lock the patern or put gthresh=0 low enough to stop the overrides I'm still having to override large chunks of the source.

Another quick question, directly concerning override files. Would it be possible to evaluate the dicision in the override file based on the patern instead of just automatically declaring the overriden match "out of patern"? A number of overrides I perform are to get it back into patern, which is related to my previous point, and the frames are declared out of patern.

otherwise looks good. looking forward to yv12 :)

GizmoTech

Cyberia
25th June 2003, 17:45
@Neuron2:

Could you explain what this means? I am confused by the "...instead of using the best field match for the frame, the original frame is deinterlaced" part. poof. HOW is the original frame deinterlaced?

post=4: This is the same as post=2 except that instead of using the best field match for the frame, the original frame is deinterlaced. You would use this to pass video sequences through when you have a hybrid clip.

I'm sure I am missing the obvious, but I *figured* it would be deinterlaced. (thats why I'm using Telecide) It's the 'HOW' more than the 'WHAT' that is important.

Fantastic work on this latest Decomb!

bilu
25th June 2003, 18:06
I think it goes like this:

Imagine a telecined movie field sequence.

a b b c d
a b c d d

Telecide does this in forward matching ( I think):

a b c d d
a b c d d

post=4 should do this:

a b b* c* d
a b c* d* d

frames b*c* and c*d* were deinterlaced, not matched.

Maybe I'm completely wrong as I don't know how does it remove combing without match though :rolleyes:


Bilu

Guest
25th June 2003, 18:09
Originally posted by gizmotech
Before you release beta 11 can you please add the ability for pattern locking?It's already there. Use this kind of override:

200,500 ccnnc

If you are asking for something else, spell it out. If you are reporting that pattern matching is failing, then you know the drill: provide a source clip and script!

I can fix the <= test to < so that gthresh=0 stops all overrides, but then that would be the same as setting guide=0. That won't be of any use.

Another quick question, directly concerning override files. Would it be possible to evaluate the dicision in the override file based on the patern instead of just automatically declaring the overriden match "out of patern"? A number of overrides I perform are to get it back into patern, which is related to my previous point, and the frames are declared out of patern.I'll think about it. It's only a display issue, isn't it?

Guest
25th June 2003, 18:18
Originally posted by Cyberia
Could you explain what this means? I am confused by the "...instead of using the best field match for the frame, the original frame is deinterlaced" part. poof. HOW is the original frame deinterlaced?

I'm sure I am missing the obvious, but I *figured* it would be deinterlaced. (thats why I'm using Telecide) It's the 'HOW' more than the 'WHAT' that is important. Well, bilu is a little confused so I'll describe the what and the how. :)

Suppose we make a field match and the resulting frame is detected to be still combed. As long as post is greater than 0, we are going to deinterlace that frame, no matter what. If post=2, we take the frame as matched and deinterlace that. If post=4, we ignore the match and just use the incoming frame as is, without matching, and deinterlace that.

How do we do deinterlacing? Well, we just apply FieldDeinterlace() to it. So, decombing can be achieved either through field matching, or, when that fails, through normal video deinterlacing methods, such as FieldDeinterlace().

Guest
25th June 2003, 18:21
@all

The pattern guidance algorithm has just been published in my website journal.

Cyberia
25th June 2003, 22:38
OK, if the composite frame conjured up by Telecide is detected as (still) combed then look at the POST value. If POST=2, deinterlace the Telecide frame. If POST=4, deinterlace the original frame.

If the Telecide frame is not detected as combed, keep it.

In either POST case, 'deinterlacing' is either Interpolating or Blending the fields depending on the value of Telecide's BLEND parameter.

Gotcha. Thanks.

Guest
25th June 2003, 22:57
@Cyberia

You are spot on with one refinement: the deinterlacing is spatially adaptive, so that only combed areas of the picture are interpolated/blended.

Boulder
25th June 2003, 23:26
Donald,

If I've understood correctly, the basic functions of Telecide will still be the same (with your latest improvements and inventions) as in Decomb v4 and us PAL people can still use the plugin as we used to after finding out the correct field order? I use simply Telecide() for sources that I know to be originally film (Star Trek TOS, for example).

Eagerly waiting for the YV12 version here:)

Guest
25th June 2003, 23:37
Originally posted by Boulder
If I've understood correctly, the basic functions of Telecide will still be the same (with your latest improvements and inventions) as in Decomb v4 and us PAL people can still use the plugin as we used to after finding out the correct field order? I use simply Telecide() for sources that I know to be originally film (Star Trek TOS, for example). Yes, of course. I wouldn't leave you PAL guys out in the cold!

Milkman Dan
26th June 2003, 08:45
I had a question about the eventual "1.0" release of Decomb.

You've already mentioned that you are going to work a bit on post, which you've already done, I believe. And then adapt for YV12.

However, are you planning to do any low-level ASM optimizations with the code, or have you been doing that all along?

I ask, because I'm learning ASM (MASM) and looking to cut my teeth a bit on some code before moving along to something really complex. So if you've optimized it already, I can study that, and if you haven't, I can see if I can figure out what would be improved.

Just so that this isn't totally off-topic, I've seen good improvements with the pattern matching so far. I feel safe turning it on now, instead of leaving it on guide=0 just to be safe.

Unfortunately, it doesn't help much on Kare Kano (at least so far as I've tinkered), but it's a particularly subborn source anyway. Too much pure interlaced material, I think. DGBob does a good job though!

Guest
26th June 2003, 12:34
Originally posted by Milkman Dan
However, are you planning to do any low-level ASM optimizations with the code, or have you been doing that all along?

I ask, because I'm learning ASM (MASM) and looking to cut my teeth a bit on some code before moving along to something really complex. So if you've optimized it already, I can study that, and if you haven't, I can see if I can figure out what would be improved.It's planned but not yet implemented. You can find some low-level code in Decomb 4 for study. Also, it would pay to study the work of others, such as trbarry and sh0dan, just to mention a few. And, of course, Avisynth itself is chock full of low-level code.

Just so that this isn't totally off-topic, I've seen good improvements with the pattern matching so far. I feel safe turning it on now, instead of leaving it on guide=0 just to be safe.That is good to know. Thank you for reporting on your results.

Unfortunately, it doesn't help much on Kare Kano (at least so far as I've tinkered), but it's a particularly subborn source anyway. Too much pure interlaced material, I think. DGBob does a good job though! Make sure you get version 1.5.1 of DGBob(). Double rate output is broken in 1.5.0.

bilu
26th June 2003, 18:57
@neuron2

From DecombReferenceManual.html v.5.0b10:

On triple explanation:"By default, only two-way match testing is used, which tests for matching with the current and next frames."

On Appendix A. Telecide() Theory of Operation: "When it receives a request for a frame it gets access to the previous frame and the requested one (called the current frame)"

What's the default behaviour, matching previous/current or current/next?


Bilu

Guest
26th June 2003, 19:12
current/next

Thank you for pointing out the documentation error.

Guest
27th June 2003, 00:31
See the first post for the link to Decomb 5.0.0 beta 11. This is the last release (barring bugs) before the YV12 support is added.

Here are the changes (refer to docs for details):

1. Fast deinterlacing based on metricX is now used for deinterlacing frames still combed after field matching. Use FieldDeinterlace() externally with post=0/1 to Telecide() if you want the old way. Note: there is no blend mode in Telecide() now, so I'll never hear another complaint about ghosting. :)

2. DGBob() is now included in the Decomb dll.

3. A pattern override does not automatically declare out of pattern. It is now properly tested.

4. vmetrics are shown for all matches.

5. The shipped DLL is named by version.

6. The triple parameter can now be overridden.

7. gthresh, vthresh, and dthresh are now all floating point.

8. Docs updated.

I'll especially appreciate an audit of the docs against the shipped functionality. All feedback will be appreciated. YV12 is getting close!

HomiE FR
27th June 2003, 06:14
Thanks thanks thanks thanks! :D

I have some exams right now, but be sure that I'll do some proper tests with b11 before sunday. :) But with b10 I already noticed some good improvements with pattern guidance (with some mouth combing for instance, but I guess it'a a "side effect" of better pattern guidance).

By the way, thanks for the full vmetric information!

I'll be back. ;)

Cyberia
27th June 2003, 15:40
So Interpolation is now done *always* to remove leftover combing artifacts? Why not just default Blend to false, and leave the option?

bilu
27th June 2003, 17:53
@neuron2

Using Telecide(order=1,guide=1,post=4,debug=true):

A Monty Python's Telecined tree panning scene
=============================================
!Telecide: frame 7: matches: 98828 198989 97486
!Telecide: frame 7: vmetrics: 18 34 19 19 [chosen=9333040]
!Telecide: frame 7: [using n] [progressive] [in-pattern]
!Telecide: frame 8: matches: 97486 183712 106774
!Telecide: frame 8: vmetrics: 19 24 20 20 [chosen=9333040]
!Telecide: frame 8: [using n] [progressive] [in-pattern]
!Telecide: frame 9: matches: 106774 106774 240076
!Telecide: frame 9: vmetrics: 20 20 36 20 [chosen=9333040]
!Telecide: frame 9: [using c] [progressive] [in-pattern]

Your Star Trek hybrid challenge stream
=======================================
!Telecide: frame 7: matches: 210930 109769 210892
!Telecide: frame 7: vmetrics: 75 24 68 24 [chosen=9333040]
!Telecide: frame 7: [using c] [progressive] [out-of-pattern]
!Telecide: frame 8: matches: 210892 105463 210081
!Telecide: frame 8: vmetrics: 68 22 71 22 [chosen=9333040]
!Telecide: frame 8: [using c] [progressive] [out-of-pattern]
!Telecide: frame 9: matches: 210081 105268 215254
!Telecide: frame 9: vmetrics: 71 19 74 19 [chosen=9333040]
!Telecide: frame 9: [using c] [progressive] [out-of-pattern]


I've noticed that [chosen=9333040] appears everywhere during the whole movies. Tried on another movie with the same result.What is it? :confused:


Bilu

Mentar
27th June 2003, 17:55
I would also politely request to keep the blend option in Telecide, because interpolation is extremely rude to the eye. It catches the attention of the viewer much more than a ghost ever would. Please reconsider and enable blend at least as a toggle, because ALL my encodes are blend. For anime I consider interpolation as barely usable.

Otherwise, thanks very much for your efforts :)

HomiE FR
27th June 2003, 18:06
Mentar : I totally agree with Mentar on that point. I would like not to lose the blend switch which I used all the time with my anime source (I gave you some parts of it for tests). But I'm doing some more tests...

Guest
27th June 2003, 18:44
The metricX-based fast deinterlacing doesn't easily allow for blend deinterlacing. I will see if I can add it without too much hassle, otherwise I'll make FieldDeinterlace() observe hints and you can use that to get your blending:

Telecide(post=1,hints=true)
FieldDeinterlace(full=false)

My intent is to have a suite of possible postprocessing filters, so I'm not too bothered about just having a simple fast one built-in to Telecide. Thoughts?

BTW, YV12 is done, but now you've delayed the release. :)

Guest
27th June 2003, 18:52
@bilu

It's a bug in debug=true display. The 4th vmetric value shown is the chosen match's vmetric, and the one shown in brackets is garbage. It will be fixed in beta 12. Thank you for pointing it out.

Guest
28th June 2003, 07:06
The long-awaited YV12 support has arrived, coincidentally in beta 12! I also managed to put back the blend mode for deinterlacing. I hate to make my users unhappy. :)

Also, FieldDeinterlace() will now honor hints from Telecide() about interlaced/progressive frames. Hints are now on by default for Telecide().

Please report any bugs in the DLL or in the documentation here. Get the new beta from the link in the first post of this thread.

HomiE FR
28th June 2003, 08:17
Just one word can sum up what I think right now : THANKS! :)

I'm going to test it right now, I'll check the documentation too because I know it (too?) well.

Just a little mistake in the documentation according to your latest post :
hints (true/false, default false) enables Telecide() to pass hints to Decimate().
default should be true I think.

bouis
28th June 2003, 12:32
Decomb 5.0 Beta 11 and Beta 12 consistently crash on a certain scene from the movie "The Comancheros." The error message is "Avisynth: caught access violation at 0x00c5b2bc, attempting to read from 0x0284e44". Beta 9 does not crash and I haven't tried beta 10.

However, when I create a huffyuv2 of the scene, no crash occurs. I'd like to help, but what should I do?

I'm using this script:
loadplugin("E:\Decomb500b12.dll")

mpeg2source("coman.d2v")

#AssumeTFF().SeparateFields()

Telecide(guide=1,order=1,nt=10,post=0)
Decimate(cycle=5)

FieldDeinterlace(full=false,debug=true,dthreshold=255)
## FieldDeinterlace(full=false,threshold=255,dthreshold=8,debug=true,ovr="over.txt")

AddAudio()

Guest
28th June 2003, 14:11
@bouis

Please use a VOB splitter from the doom9 download page to make a small VOB containing the frame that cause the crash. Then put the VOB somewhere I can download it. Thank you.

Also, add Telecide, Decimate, and FieldDeinterlace one-by-one and see when it crashes. That will tell me which filter is having a problem.

Also, are you running YUY2 or YV12?

Is there anything funny about the frame? All dark, all bright, etc.?

BTW, thresholds of 255 to FieldDeinterlace defeat its purpose. I assume you are doing that for debugging.

Guest
28th June 2003, 15:03
Beta 12 is temporarily withdrawn. It has some serious problems.

Guest
28th June 2003, 15:26
Beta 13 fixes hard pattern guidance and makes backward matching more intelligent.

Is beta 13 the lucky charm? :p