Decomb 5.0.0 beta 15: Fix for crashing problem [Archive] - Page 4

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.