Weirdly blended X-Men DVDs, need help sorting it out

[Chainmax]

It seems like the poor X-Men just can't get a break, as every release there has been for them has an issue of some sort. Now, while the newest Disney DVD release is almost perfect, it has a strange artifact that fully seems like blending. Take a look at the following screenshot, taken only with SeparateFields() in the script:

http://img411.imageshack.us/img411/8011/separatefieldsframe199.png

The interlaced/progressive pattern is I-I-P-I-P, which I find unusual as well. In any case, here's a sample containing the intro and a high motion scene, please have a look at it and let me know what you think:

http://www.mediafire.com/file/uzu70p7zqnn7n4a/VTS_03_1.demuxed.m2v

[Chainmax]

One more thing to note: DGIndex found field order transitions, and this issue happens whether I load the fixed d2v or its "bad" version.

[Chainmax]

Anyone?

[Emulgator]

Hi chainmax ! I already tried my luck and found some steps to go.

Please be patient, I can not continue right now:

Right now I have to solve an emergency case (Hammond repair for a major studio here in Berlin)
The band (famous act from the netherlands) wants to start their recording tomorrow,
and now this monster (a RT-3, the biggest one) is in my hands...

[Chainmax]

Thanks, Emulgator :)

[Emulgator]

Hm, lovely. Fieldblends in different strength all over the place.
Here DGIndex reports the demuxed source you provided to have Field order TFF globally.

I counted field pattern offsets in a spreadsheet and found something that works
for some parts of the clip's frames.

If one wants to have full frames back, including keeping some movement of background mattes:

ConvertToYV12(interlaced=true).QTGMC(EdiMode="NNEDI", tr2=3, sharpness=2.8)
SelectEvery(5, 1, 2)

This seems to work for fields 71/72 to 241/242. The fields before 70 are black or close to black, so I can not tell.

It breaks at fields 245/246.
245/246: here exist two 50/50 blended fields for the first problematic frame.
248 delivers a slightly blended field for the second problematic frame.
250/251 deliver two 50/50 blended fields for the third problematic frame.
Then 253 is a solitary field that delivers an almost unblended frame.

Then the pattern continues like 256/257, 261/262, 266/267, but breaks again later.

So maybe every z frames there is a another different offset for SelectEvery(5, x, y),

You might try searching this pattern...

AnimeIVTC choked.

[Chainmax]

So, your line would work on fields [0, 242] x n and I'd have to manually fix fields [243,255] x n? Or are fields [243,255] x n unfixable?

This can't have been due to bad ripping: AnyDVD + DVD Decrypter in IFO mode is as straightforward a it comes...damn it, I can't believe even a new release can be so royally screwed up.

[Emulgator]

These 3 have to be unblended, the pattern search may go on, maybe shifted.
Ripping is not the fault. But the treatment of the source definitely was.
I would like to continue searching, but right now too much is coming in for me.
One Organ saved, next is coming in.
Maybe I will find a way later.

Srestore is quite good at auto-deblending, just play around with that one.
A combination of
Assumefps(your guess here, 30000/1001, or 30)
Srestore() or (frate=your guess here)
Vinverse()
can bring out most of the good frames.
Some 12,5fps, 14.385614fps, 15fps should be the real source rate.

[Chainmax]

After reading up on SRestore, I finally got around to try it. Some tinkering showed pretty satisfactory results with this:

d = last.bob(-0.2,0.6).reduceflicker(strength=1)
TDeint(mode=1,type=1,edeint=nnedi3(field=-2),emask=TMM(mode=1))
SRestore(frate=23.976,omode="pp3",speed=-25,dclip=d)
vinverse()
TDecimate(mode=7)

But I did find a few problem spots. As an example, here's a chosen problematic frame:

http://img822.imageshack.us/img822/5316/selectedw.png

And here are the ones that were being considered:

Frame 282:
http://img403.imageshack.us/img403/1428/282d.png
Frame 283:
http://img169.imageshack.us/img169/3563/283p.png
Frame 284:
http://img256.imageshack.us/img256/7751/284d.png
Frame 286:
http://img830.imageshack.us/img830/4516/286c.png
Frame 287:
http://img294.imageshack.us/img294/875/287.png
Frame 288:
http://img684.imageshack.us/img684/4932/288y.png

As you can see, frame 287 should have been chosen, or at least 286 or 288. The documentation regarding debug or display is not too comprehensive, so I do not understand how to tweak the "dupthresh" and "vidthresh" parameters to effect the final frame choice, or if that's possible at all. I will try Decomb's Decimate and SmartDecimate too, but for now I wanted to exhaust all possibilities here.

[Chainmax]

Sticking BlendBob after Srestore and before TDecimate did help a bit, but again, not perfect.

[Nightshiver]

You know, this is probably one of those sources that you won't be able to fix 100%, so you should already be prepared for that. If you dislike it so much, just do a bunch of freezeframe() calls.

[Chainmax]

I am afraid that will turn out to be the case, but first I wanted to exhaust possibilities of there being an automatic way before resigning myself to examine each frame manually.

[kazary]

I was thinking about buying this DVD. got any good results?

[Lyris]

Those images look absolutely hideous - not so much the field blending, but the total lack of detail. Is that something in your own script or have these been blasted with noise reduction?

[Chainmax]

kazary: for now, all I have left to try is find the places the current script fails at and make an insanely high number of freezeframe calls. If I am lucky, I can find a function that links every instance of a bad decimation choice. If not, then I'll have to give up. It is, however, something that will take a long time and I can't feel like doing it just now, so unless a better way is found this will be on hold.

Lyrys: the current script is this:
TComb(fthreshL=6,fthreshC=7,othreshL=7,othreshC=8)

d = last.bob(-0.2,0.6).reduceflicker(strength=1)
TDeint(mode=1,type=1,edeint=nnedi3(field=-2),emask=TMM(mode=1))
SRestore(frate=23.976,omode="pp3",speed=-25,dclip=d)
vinverse()
TDecimate(mode=7)

RemoveGrain(mode=5)

Crop(6,0,704,480,align=true)

source=last
preNR=source.dfttest(sigma=1.25,tbsize=3).FFT3DFilter(sigma=4,plane=3,bw=32,bh=32,bt=3,ow=16,oh=16)
preNR_super=preNR.MSuper(pel=2, sharp=1)
source_super=source.MSuper(pel=2, sharp=1)
backward_vec3 = MAnalyse(preNR_super,isb = true, delta = 3, overlap=4)
backward_vec2 = MAnalyse(preNR_super,isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(preNR_super,isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(preNR_super,isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(preNR_super,isb = false, delta = 2, overlap=4)
forward_vec3 = MAnalyse(preNR_super,isb = false, delta = 3, overlap=4)
source.MDegrain3(source_super,backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=350)

FFT3DFilter(sigma=4,plane=3,bw=32,bh=32,bt=3,ow=16,oh=16)

aWarpSharp2(depth=16,chroma=4)

dull=last
sharp=last.LimitedSharpenFaster(SMode=4,Strength=150)
Soothe(sharp,dull,25)

GradFunkMirror(1.51)

So, as you can see, there isn't really that much in the way of detail killing. The source is just that bland. In all fairness though, this is a very high motion intro scene, and from a early 90s western cartoon, so it's probably par for the course. The show itself looks a little better.