Double-blend IVTC Removal

[mg262]

MaskTools 2.0a mt_merge with u=v=3 might do it...

[Didée]

MOmonster, please elaborate on your problem. I can't see any problem.

As Clouded pointed out, you have to specify "U=3,V=3" in MaskedMerge to also process chroma. This is nothing new new in MaskTools' alpha, but is the very same in MaskTools v1.5.x.

A frame:
http://img356.imageshack.us/img356/998/frame7bu.th.jpg (http://img356.imageshack.us/my.php?image=frame7bu.jpg)


edge = o .prewitt() .greyscale() :
http://img356.imageshack.us/img356/2908/yedge6zx.th.png (http://img356.imageshack.us/my.php?image=yedge6zx.png)


edge2 = o .prewitt() .fity2uv() :
http://img356.imageshack.us/img356/5595/yedge2uv3sw.th.png (http://img356.imageshack.us/my.php?image=yedge2uv3sw.png)


show = stackvertical( stackhorizontal(edge2.UtoY(),edge2.VtoY()), edge2.greyscale() ) :
http://img85.imageshack.us/img85/5581/showyuvedge2sz.th.png (http://img85.imageshack.us/my.php?image=showyuvedge2sz.png)


Everything is fine.


edit: there's a minor problem with fitY2UV producing an offsett of 0.5 pixel horizontal and vertical. Probably FitY2UV is using the same code as Avisynth's ReduceBy2, which has the very same offset problem.
But supposely that's not the problem you were facing.

BTW, I never liked Horizontal/Vertical/ReduceBy2 for just this reason. And if creation of halfsized/quartersized/... clips is done in scripts, where these reduced clips are blown up to fullsize again later on, then the shrinking should never be done with ReduceBy2. (It's a rather common mistake.)

[foxyshadis]

momonster, I have another clip sitting unprocessed, I could strip off the audio and give you two or three minutes of it, so that you have a longer testbed if you want it?

Here it is: Niea (http://foxyshadis.slightlydark.com/random/Niea's_Life.m1v)

[MOmonster]

@Didee & Clouded
Thanks for the fast help. I think I have an older documentation, that´s why I don´t know of these parameters.

@foxyshadis
Thanks for the clip, I´ll test it soon.

[MOmonster]

So, I updated FixBlendIVTC_HQ to version 0.5. It gives a really nice output, has a much better single-blend-detection and a better postprocessing. The negative point is that it´s so heavy specialized for your first samples. I also didn´t make internal values changeable by parameters. Also with these parameters the functions fails a lot on your new clip. The motions is in many cases just to low.
I have allready a idea to avoid this problem. A mix of this singe-blend-detection with the Cdeblend algo and maybe using unblend for preprocessing should handle also these sources much better. I think I´ll create such a function the next days, but it will take some time (many things to do in reallife :) ).

Edit: Attachment moved to a later post.

[foxyshadis]

Thanks for taking the time to work on this. =D I'll grab it and see if I can offer any useful tweaks to help it along. I tested using unblend and reverseblend as a preprocessor to older versions, they proved rather too dumb to make effective use of, because they screw up all the double-blends and sometimes pick the wrong frame to replace a single-blend with, but if you think you can marshall them into form it'd be nice to see.

I have another source with motion much much lower than that too. It might be better to try a manual on it, but I won't be working on it for a few weeks so I'll deal with that when I get there.

[MOmonster]

@foxyshadis
I had a closer look at your new source and recognized something strange. I don´t know how it came to this, but the blendweights are very different. A good blenddetection and this blendreversing we do now isn´t possible that way. Unblend gives here better results than my function. Sorry, but I don´t how to restore this source. :(
But still my function will get some little improvments next time.

[foxyshadis]

Really? Eeek! I'm so sorry! I should have checked to make sure, it was from the same guy so I assumed it was the same thing without closely examining it.

I'll find you another one, if you'd still like, and this time make sure it is what I say it is (although frankly, just compressing a hand-made clip into mpeg-1 or 4 should be enough to give 'real-world' conditions).

[MOmonster]

I'll find you another one, if you'd still like, and this time make sure it is what I say it is (although frankly, just compressing a hand-made clip into mpeg-1 or 4 should be enough to give 'real-world' conditions).
Of course I like. I don´t have so much time, but I´m really interested in further improvements. ;)

[LogicDeLuxe]

What plugins do I need for this to work? You only mention MaskTools in your first post, and I'm a bit confused about all the many posts. I'd really like to give this a try.

[foxyshadis]

Masktools and Average. Did I not mention Average when I edited? I'll fix that now.

Same for mine or Momonster's. (Although like he says, his is somewhat better and faster than mine, though I haven't had a chance to full test it, since I'm on vacation.)

[LogicDeLuxe]

I loaded those plugins. Now I get a Script error: there is no function named "min"
([ScriptClip], line 3)What did I do wrong?

[MOmonster]

@LogicDeLuxe

Foxyshadis function needs also this (http://forum.doom9.org/showthread.php?t=72999&highlight=deleteevery) (the Min/Max filter) I think, but I´m not sure, because for tests I write the function into the script. My function doesn´t need this. But Average and Masktools is so or so needed. :)

[LogicDeLuxe]

Thanks. Works great now. It doesn't even seem to harm hybrids, ie. scenes with those blend crap together with clean 30p scenes. That's even better.

Now dealing with such a hybrid, I can't just decimate the result to 24 fps.
What I'd like to do is a PAL speedup, ie. converting it to a hybrid with 25p scenes and fieldblended 50i scenes from the 31.25p parts.
Any idea, how to achive this?

[MOmonster]

@LogicDeLuxe

Maybe I can create a function that reads the range of this blended parts, if this would help you.
It would be good if you can upload two short samples (one 30p and the other blended). I like to have a look at it.

[LogicDeLuxe]

I thought about something like this:video=fx_unblendTC()

video
decimate
AssumeFPS(25.00)
vid_progressive=Lanczos4Resize(720,576)

video
AssumeFPS(31.25)
Lanczos4Resize(720,576)
ConvertFPS(50)
SeparateFields
SelectEvery(4,1,2)
vid_interlaced=Weave

ConditionalFilter(vid_progressive, vid_interlaced, "is_30p", "=", "true")
If I had an expression for "is_30p" that should do it.

[MOmonster]

I think something like this is possible. Give me some days. I don´t have the time for this now. :)

[MOmonster]

I thought about something like this:video=fx_unblendTC()

video
decimate
AssumeFPS(25.00)
vid_progressive=Lanczos4Resize(720,576)

video
AssumeFPS(31.25)
Lanczos4Resize(720,576)
ConvertFPS(50)
SeparateFields
SelectEvery(4,1,2)
vid_interlaced=Weave

ConditionalFilter(vid_progressive, vid_interlaced, "is_30p", "=", "true")
If I had an expression for "is_30p" that should do it.

Sorry, but it isn´t that easy like I thought.
I created a function that preanalyse the next five frames and can decide to restore or use a given clip. The problem with the conditional enviroment is the different speedup.
A solution can be to output the frames where the source change to 30p and then back (similar to my interlacing_reader), but maybe this function is just ok.

Use higher thresholds to recognice more 30p parts. The pp parameter can be 0 (non), 1(medium), 2(max). The nblength says the function after how many frames (with no detected blends) it should use the nbclip. Nice tryout. ;)

p = last.ConvertFPS(23.976*2) # or changefps()
p = p.separatefields().selectevery(4,1,2).weave().changefps(29.970)

FixBlendIVTC_Hybrid(nbclip=p, pp=2, nblength=11, hthresh=5.2, lthresh=2.3)
decimate(cycle=5,quality=0)
assumefps(25.000)
It is absolutly not proof that this works. I tested only a mask clip, but theoretical :confused: .
Just give a report back, I can try to make it better.

Edit: Sorry, of course it should be "changefps(29.970)" after weave. Is changed. ;)

[LogicDeLuxe]

The detection seems to work fine with the default parameters. I don't really understand how I should tweak the parameters exactly.

But I get glitches at some scene changes. Looks like it subtracs the last frame of one scene from the first frame of the next scene, which looks much more distracting then blended frames since it tends to flash. I think, it has to do with poor edits, which you find in so many TV series, ie. there are scene changes where there is only one field of a frame left.
In such a case, the frames around a detected scene change should be passed untouched. An option allowing this would be great.

Also, I wonder, is there a ConvertFPS replacement which works in YV12? I'm not that happy with the ChangeFPS result, and I certainly don't want to convert the colorspace more than neccesary.

[foxyshadis]

I think clouded's Motion filter includes one. Or maybe I'm thinking of another filter but I know I saw it in this forum recently.

Try lowering hthresh, I think that might help. But I haven't had a chance to play with the thresholds to see which do what just yet.

Oh, and I'm going to try it on the Blended Clip From Hell(tm) just to see if it works at all. It's double-blended like the rest... and heavily edited, so all the patterns are thrown way off but vaguely recognizable. This will be fun!

[mg262]

Yes, it's called BlendFPS and its in Motion.

[MOmonster]

I´ll create a function that have some more parameters and use the code of the Hq and the standard version this weekend, maybe it´s worth to wait until Monday before testing the function.

@LogicDeLuxe
It would be really nice if you could upload a small clip. I don´t have internet this weekend, but a small example would help me a lot to improve the function for your problem.
Such a scenechange detection parameter should be easy to implement, but with the source maybe I find a better solution for you. ;)

Edit:
The hthresh is used for the comparison with the next and the previous frame. If the blendvalue difference is that high, it´s detected as a blend. The lthresh is for the overall difference (the smallest of five values against the others). For the standard version this thresh is zero.
some artefacts can also be a result of the postprocessing. Try also 1 and 0.

[LogicDeLuxe]

I just restored two clips without any wrong detection. Works really well. (I didn't try tweaking the threshs yet, though)

The problematic one I tried before has one difference as I can see it. It seems the clip comes from a source with 240 lines, probably the average of two NTSC fields. But as if that wasn't worse enough, the clip then was upscaled to 432 lines. Is it possible that those scaling artefacts can distract the proper scene detection? I wonder as I didn't have that problem at all on the two other clips, even though I scaled them up to PAL resolution before processing.
I'll try scaling it back to 240 lines in order to see if this helps detection. If not, I will prepare a short clip.

Anyways, it should be possible to pass separate clips for detection and processing to FixBlendIVTC_Hybrid(). The way it is now, you have to scale the clip to 576 lines which might make the detection more difficult, I guess. On the other hand, if I do the scaling afterwards, I wouldn't be able to properly interlace the 30p parts.

[LogicDeLuxe]

Scaling it to 240 lines did in fact fix my detection problem. I guess separate clips for detection and processing is the right way to go.
That is, I would scale the detection clip to 240 lines and the processing clip to 576 lines.
Then things would be perfect, I think.

[foxyshadis]

If you want, I can add a clip2 parameter to it really quick. It's not too hard to separate final output from blend-detection, since they're pretty much entirely separate.

[LogicDeLuxe]

Sorry, my fault. The scaling didn't really fix it.
I disabled decimate(), which I usually do when previewing since it is much faster that way. It turned out that those gliches only appear when decimate() is in the chain. Also Could decimate() produce such a glitch? Strange, isn't it? Even more strange is the fact that I didn't have that problem with the other two clips at all.

I tried saving it without decimate() into a new clip. When I then just loaded that intermediate clip and decimate() it, I don't get those glitches any more. Does this make any sense to you?

[LogicDeLuxe]

Maybe decimate() throws the detection algorithm out of order, thus screwing the counter variables.
At least I found a workaround without the need of an intermediate file (which gets pretty big with a huffman codec):
I just left the decimate() out of it and opend the restored clip in another avs file like this:DirectShowSource("Fixed.avs")
decimate(cycle=5,quality=0,mode=0)
AssumeFPS(25)

[foxyshadis]

Anything that requests frames from a conditional function out of order (which fdecimate and tdecimate do, and apparently decimate with yours) will farge up the function. Normally decimate wouldn't but maybe in this case something causes it to.

But the second avs is very cool, I'll have to try that next time.

On a development front, I'm trying to tweak both mine and momonster's to try to get them to deal with runs of identical frames without killing the pattern. (Oh, this video is hurting. It's been edited to place slices of video on top of each other, or 30p on top of 24p w/ 2 blends, so I have to go crazy on editing or just skip big chunks...)

[LogicDeLuxe]

(Oh, this video is hurting. It's been edited to place slices of video on top of each other, or 30p on top of 24p w/ 2 blends, so I have to go crazy on editing or just skip big chunks...)I just stumbled on such composed scenes as well. I also spotted 24p on top of 30p, sometimes with those blends, sometimes without blends, ie. just every 4th frame (the 24p part of it) doubled. Any chance, that could be smoothly interlaced to 50i? I guess, not. Fortunately such scenes are pretty rare in my clips, were handled like any 30p parts, and I don't have much hope that they'll get any better.

It's amazingly enough, that I didn't saw a crossfading breaking the pattern so far, which certainly would be another pain in this matter.

[MOmonster]

@foxyshadis & logicdeluxe

You speak about heavy sources with edits and pattern problems. The decimating could be easily tweaked with a different singleblenddetection and the clip2 parameter for bad quality sources could also be easy implemented to softing the detection clip. But I would like to have some source to test with. The modified source I work with shows perfect patterns and so on, so it´s not that comparable.
I finished the next version, wrote a readme and opened many more parameters. If useful the hybridversion can be also easily changed.
Edit: The decimating problems are normal with the evaluate enviroment, only tdecimate(mode=7) and smartdecimate works fine with such things at this moment. I use a unnecessary tweak(hue=0.25) for the dupframes. Often a resizing after the function also helps, but logicdeluxe´s idea looks nice.

Edit:
attachment removed to later post.

[foxyshadis]

You don't want my evil parts, I'm just going to chop up the video frames, process, and then remerge them, voila, corrected segments. (Such is the hope.)

The less evil parts I'm going to analyse more to see if I can find out what's pathological and what's worth posting. I do think that it gets confused when 4 identical frames occur, then of course it looks like a blend. It's not common but when it happens things go bad. I'm still trying to figure out why one segment that looks like it should be easy to recognize isn't, I'll probably post it for you too.

Would using a halfsized or denoised clip for blend-detection work better, you think? I know pre-filtering didn't work for me before, but it's changed quite a bit in yours. I haven't tried yet, but I'll probably give it a shot.

By the way, you are awesome.

[MOmonster]

@foxyshadis
Thanks :)
I still would like to see the sources. Mostly I learn more from bad sources.
For many sources the preprocessing has a bad effect, only for some bad quality samples it can help. Also, it has to be stupid preprocessing (resizing or simple bluring, bilinear mostly helps a bit). Deblocking and so on mostly make the detection worse than before. :(

Edit:
To tweak my function for your sources you should play a little bit with this parameter:
YV12LUTxy(unblend1, unblend2, yexpr="x y - 2 ^ 6 /", uexpr="x", vexpr="x") It has a big influence on the blenddetection. For a working singleblenddetection it has to be the same for blenddiffm.
I think I´ll open this parameter in the next version. Maybe also a motionthreshold is useful for you, because of the many still scenes. Maybe I`ll find the time for this the next days. ;)

[MOmonster]

So, the next version is ready. New is the mthresh and sprotect. Maybe it helps in some sources. :)

[foxyshadis]

I'm sorry I haven't been testing as much as I wanted to, I've been dragged into and involving myself in too many projects lately. ^^; It was better when I played with it, but I haven't had time to make real encodes or test cases.

I think I'd definitely better replace mine in front with yours, it's so much better now. Aww, I feel bad that my first really important filter is useless now. :p

Is this integrated into C_Deblend at all, or are they still entirely separate?

[MOmonster]

FixblendIVTC and Cdeblend are totally different functions. I don´t think that this will ever get a part of Cdeblend.
Sorry. that you think your function is useless now. You give me some ideas with it, especially for so postprocessing.
So, thanks you very much. ;)

[Anonymouses]

I have this really nasty clip that I've been trying to use the FixBlendIVTC but I'm not getting any decent results. I'm not sure if it's just too screwed up to fix or if I'm just doing something wrong. The clip is here (http://rapidshare.de/files/7585928/Patlabor.m2v.html). Any help is appreciated.

[MOmonster]

I have this really nasty clip that I've been trying to use the FixBlendIVTC but I'm not getting any decent results. I'm not sure if it's just too screwed up to fix or if I'm just doing something wrong.
I´m not able to have a closer look on it (only vlc here), but this is no source for these doubleblendremovers here. The blendweights are different. So it´s more a source for Cdeblend or Cdeblend_mod. Tomorrow I can have a closer look on it and give you more informations.

[LogicDeLuxe]

I have this really nasty clipThis here is for blended progressive video. Your's is interlaced. You can try restore24 on it.

[foxyshadis]

I had time to pick through the next bebop video (sorry about overusing the show...) and found a few interesting segments, numbered according to how I split it up.

s9 (http://foxyshadis.slightlydark.com/random/be_blendtest_s9.avi) and s14 (http://foxyshadis.slightlydark.com/random/be_blendtest_s14.avi) show pulsing artifacts, I have no idea what might cause that.

s19 (http://foxyshadis.slightlydark.com/random/be_blendtest_s19.avi) shows a few artifacts, notably frames 189, 308, and 576. It only seems to catch about half the blends, as well; they're all on obvious edits, so if you don't want to deal with that I'm cool. (It took some editing but I restored some of the patterns myself and it works a lot better.)

Adding removeblend after helps catch some straggling single-blends though.

[MOmonster]

I have this really nasty clip that I've been trying to use the FixBlendIVTC but I'm not getting any decent results. I'm not sure if it's just too screwed up to fix or if I'm just doing something wrong.
Oh yes, nasty and screwed up are the right words. Another totaly overblended anime. I have modified Cdeblend a little bit for this. It´s still not very good, but these sources aren´t worth much more time working (too bad and too seldom). Have a look here (http://forum.doom9.org/showthread.php?p=751063#post751063).

[MOmonster]

@foxyshadis
Yesterday I took a look at the s14 sample (couldn´t find the others on my pc, sorry). What do you mean, with pulsing. I get a wrong detection and saw cruel artefacts (I´ll fix it in the next version), but get no pulsing (maybe because the wrong detection). Show pp=0 or pp=1 also this pulsing. I´ll try to improve the singleblenddetection in the next version. Maybe a motioninfluence (similar to Cdeblend) can also tweak the blenddetection. I´ll see, but give me some time (I´m ill :( ). ;)

[foxyshadis]

Oh, by pulsing I just meant the artifacts kept showing up in a cycle.

Anyway, I made a couple of mods to your function, let me know what you think:


global lastframe = -1000
global frameskip = false
global diffclipf = interleave(source.trim(1,0),unblend2.trim(1,0))
global revdiffclipf = interleave(unblend1.trim(2,0),unblend2.trim(2,0))


d3=FrameEvaluate(d4, " blenddiff1 = max <= 0 ? 0.01 : (fdetect == false ? AverageLuma(blenddiffm.trim(1,0)) : CFrameDiff(diffclip,prevf=false))
revdiff2 = fdetect == false ? AverageLuma(revdiffm.trim(2,0)) : CFrameDiff(revdiffclip,prevf=false)
revtemp = frameskip ? 1.0 : revdiff0")

d2=FrameEvaluate(d3, " blenddiff0 = frameskip ? 1.0 : blenddiff1
revdiff1 = frameskip ? 1.0 : revdiff2
revdiffb = frameskip ? 1.0 : revtemp
global diffclip = diffclipf.trim(current_frame,0)
global revdiffclip = revdiffclipf.trim(current_frame,0)")

d1=FrameEvaluate(d2, " global blenddiffb = frameskip ? 1.0 : blenddiff0
global revdiff0 = frameskip ? 1.0 : revdiff1
global revdiffbb = frameskip ? 1.0 : revdiffb
lastframe = current_frame")
d0=FrameEvaluate(d1, "frameskip = lastframe != current_frame-1")
return(d0)

The frameskip is there to prevent random access (such as joining normal and unblended sections of clip) from playing total havok with it, it resets everything if it detects it. Not very bright but it works. And proves that adding removeblend after it screws things up.... I'll have to find a good way to work that.

CFrameDiff (from TIVTC) was an attempt to fix the artifacts, it didn't do that, but it does seem to give better detection of not-blends (ie, actual 30p). The numbers it returns are normalized the same as LumaDiff. Probably not worth adding a new dependancy, but I thought you'd be interested.

I also tweaked the counters, but my mods only tended to make things worse, so I'll leave any of that up to you. :p

[MOmonster]

A nice idea, really. :D
I don´t know, if I´ll add it to the next version, just because the next version will have a lot of significant changes (hoply improvments), but I keep it in mind.

[MOmonster]

Yesterday I got the time to finish version 0.6. There are many changes like:
- different, more useful parameters
- blenddetection with motioninfluence
- variable postprocessing mode
- better motionthresholding
- different, faster singleblenddetection

I think about much more improvments especially on the postprocessing, but there are other projects more important at the moment and less time for all the things, so don´t wait for the next release.;)

[foxyshadis]

Thanks for taking the time! It must have been a lot of work improving it that much. It took me a while to puzzle it all out (there also seems to be a lot of dead code... most of the scriptclip as well as frdiff0/frdiffb/frtemp never actually getting assigned to anything but themselves, was that intentional? they're certainly used often enough.), and had to wait for a bug in another filter to be fixed, but I think I kind of got the hang of most of it.

I've made a few modifications, if you'd like to take a look and comment you're welcome to. For one, I converted to masktools 2 (all of my stuff is, faster plus I occasionally find bugs for manao =p), as well as a couple of other optimizations. I also took out some unused code, added my "frameskip" test. Also created a new is12p test, because I found that no sbf caused bad artifacts and sbf>.7 stopped them but caused many missed blends with my sources. mil helps but not always. It tests two frames on either side and if they're the same, triples the SBF. Also included is optional use of CFrameDiff instead of YDiffToNext, with parameter cdiff, which makes single-blend even more reliable, but doesn't affect double-blend detection yet. I modified the readme accordingly. I'm thinking of changing the double-blend too, but I haven't yet had any serious inspiration. ^.~ I do have a few ideas for postprocessing I'll look into though.

Of course that means a few more dependancies: Avisynth 2.56a+, Masktools 1.5x, Masktools 2a22+, Average, Removegrain (plus optional 1.0a optimizations, maybe I should just add them in directly? too bad there's no way to test filter version), and TIVTC RC1 optional.

I also talked to tritical, and he may change TDecimate for in-order access soon, so I can use it directly for my purposes (too many 24/30 hybrid clips), plus it's much faster now.

[MOmonster]

Really nice modification.;)
The last weeks I had really less freetime, so I only concentrated on corechanges.
I miss the FitY2UV() in version 2, but this changed with the last update. Through I don´t have a good feeling using both masktools version in one script, because version 2 has no YV12subtract anymore. Maybe the simple differencing with mt_lutxy won´t cost speed (I have to test it). So or so a really useful modification, many improvments.:D I´m interested in your idea for a better blenddetection. The doubleblenddetection can be tweaked easy with a difflimitation in the lutprocessing. If I find some other ideas I´ll post you.

Edit: frtemp and frdiff1 are just there to get frdiff0 and frdiffb, used for the singleblenddetection.
Edit2: Yes, after some more testing, the variable postprocessing wasn´t the goal, it was a try.
I still don´t worked with the inofficial last removegrain version. Is there somewhere a documentation around?

[MOmonster]

New version (FixBlendIVTC v 0.8a) is ready.:D
And it clearly superior all my previous versions.

Changes are:
- improved speed (faster double- and singleblenddetection, faster postprocessing)
- new more accurate doubleblenddetection
- different singleblenddetection (12fps detection)
- easier use and less global variables
- new postprocessing (sharper and faster -> post 2 and 5)
- use mt_masktools instead of the older masktools version

Needed filters are included in the zip. RemovegrainS.dll works on all my tested systems, but of course for a better speed you can use the faster versions.
I wasn´t satisfied with the results of v0.7, but this version is much better. You should update your last version.

@foxyshadis
There shouldn´t be much scope for useful modifications. This time I also gone a little bit more into detail, but of course another modification would be more than appreciated.
A better 30p treating i´ll maybe add next version.

Edit: I packed a wrong plugin into the zip. Is changed now.

[foxyshadis]

Wow, nice. I see in your detection you were going down a similar road I was, but I like your results better. =D I still have a feeling that AverageLuma is the weakest link. YPlaneMinMaxDifference is only slightly better. That's why I've replaced it with CFrameDiff in different ways each time, and always improved its functionality. (It gives you the highest averageluma out of all 8x8 blocks.) If only it had the ability to compare against a second clip I wouldn't have to hack it in, which is why I've toyed with writing a filter consisting of nothing but Dup's mmx 8x8 difference function.

Does that interest you at all?

[MOmonster]

Oh, I´m really interested in this idea. Theoretical a matrix wise operation should give better results than the simple pixel operations without regard to the other values.
But if this will practical tweak the detection, I don´t know. Bobbing artefacts and so on can have a bad effect on this methode, more than on the simple pixel operation. We´ll see.
So or so, I think such a filter would be of much use also for different projects.
Keep on your good work. ;)

[jmac698]

Hello,
looking forward to trying your script. Read some of the thread, seems very interesting and exactly what I'm looking for.
This is a (probably, as BBC) pal-land source on ntsc. Possibly film -> pal -> ntsc.
Anyhow, it goes like this:
progressive, progressive, top field blending with previous field, top field blended with previous field, bottom field blended with previous field, bottom field blended with previous field, and repeat.
Just to be clear, when the top field is blended, the bottom field is fine. Is the blending with the last other field or other same field? I have to look for edges jumping up and down, I will have to look again.

So the model and arithmetic in your terms, with x1 x2 being top/bot fields of frame x:
A1=u1
A2=u2
B1=v1
B2=v2
C1=(w1+v1)/2
C2=w2
D1=(x1+w1)/2
D2=x2
E1=y1
E2=(y2+x2)/2
F1=z1
F2=(z2+y2)/2

So I need to do u=A1&A2,v=B1&B2,w=(C1-B1)*2&C2,x=(D1-x1')*2&D2,y=E1&(E2-D2)*2,
z=F1&(F2-y2')*2

You can see some of the differences are twice removed, which will probably look terrible.
I would like to suggest generalized parameters as (a,b,c,d,e,f...)
which could take up to cycle6 (12 parameters) or even 25, and each number is the number of fields back this field is blended with. So my case would be:
(0,0,0,0,-2,0,-2,0,0,-2,0,-2). Or maybe the -2 are all -1. You would also need blend ratio, threshold parameters, and anything else. Of course, it's best to autodetect blends, but a hint could form a weighting system.

Even more general is a set number of blend types, in my case there is either none or -2 blending. If there were a deblend function deblend(prevfield,weight,thresh) with the result of currfield'=(currfield-(1-weight)*prevfield)*1/weight if diff>thresh else currfield'=currfield. Diff could be the squared difference as discussed. By calling this function with different weights you could give a hint to the function. But it would also be good to get a value for diff back so you can adapt at a higher level. To be really good you would need to supply also some interpolation fields for better recovery, but then it gets complicated.
Is this making any sense? :)
I think we need tools that a user can determine their cycle type, the blend ratio, and then know what to put in some parameters.

I'll try your script and see what happens. Thanks for all the work!

[edit] one other problem, on non-stable sources like VCR the fields could be relatively shifted a few pixels, this would leave ghosted edges only. And of course mpeg artifacts and noise too :(