Deinterlace Problems

[Kyaneos]

Hi guys:

I'm capturing a cartoon movie interlaced from an old VHS tape with Lagarith codec, interlacing is "Field blended norm-conversion", I used many filters (TDeint, TMC, AnimeIVTC, TempGaussMC_Beta1, QTGMC etc.) but I can not delete the following artifacts:

http://oi60.tinypic.com/qnvj3d.jpg

http://oi57.tinypic.com/xnyw6x.jpg

http://oi57.tinypic.com/x1x6wk.jpg

http://oi59.tinypic.com/2f07nrn.jpg

http://oi61.tinypic.com/11iz3x2.jpg

http://oi57.tinypic.com/vfulg8.jpg

http://oi61.tinypic.com/2e50hs1.jpg

Here uncompressed two samples:

https://mega.co.nz/#!SdIiXK6b!fjPWF_c-O4f16_ABan-ntADV9gTjLs3Gf2-TaURHMZw

https://mega.co.nz/#!3MYHyCRb!W-Yf4QghzifUZ8Sq55E-ArFkIKukiP9vcgLcJh2mUkc

Is there a deinterlace filter, settings, or postprocessing filter to fix it?

Thanks a lot.

[Overdrive80]

Ohhh, TVE2... old memories. Maybe you can try http://forum.doom9.org/showthread.php?t=166834

This artefact is chroma blend, if I am not wrong. Saludos.

EDIT: Change for avoiding confusion.

[feisty2]

it's chroma blend

[Stereodude]

Are you using ConverttoYV12() somewhere in your script?

[Overdrive80]

it's chroma blend

Thanks for clarification. ^^

[feisty2]

luma = tfm(pp=0, slow=2)
chroma = vinverse().Srestore(omode="PP3", cache=10)

# manual sync: figure out which frame (previous,current aka p,c) of 'chroma' clip is most similar to current frame of 'luma' clip

# 46*log(|x-y|+1) uses the full [0,255]-range and scales little differences better than |x-y|*2
diffp = mt_lutxy(luma,chroma.selectevery(1,-1),"x y - abs 1 + log 46 *")
diffc = mt_lutxy(luma,chroma, "x y - abs 1 + log 46 *")

# average difference between compared frames
mp = mt_lutf(diffp,diffp,"avg",expr="x")
mc = mt_lutf(diffc,diffc,"avg",expr="x")

# build conditional masks based on the caculated comparisons
maskp = mt_lutxy(mp,mc,"x y < 255 0 ?")

# finally merge the luma of the tfm with the chroma of the srestore clip accordingly to the binary mask
MergeChroma(luma,chroma).mt_merge(chroma.selectevery(1,-1),maskp,luma=true,Y=2,U=3,V=3)

try this script, should fix the problem

[Kyaneos]

Ohhh, TVE2... old memories. Maybe you can try http://forum.doom9.org/showthread.php?t=166834

This artefact is chroma blend, if I am not wrong. Saludos.

EDIT: Change for avoiding confusion.

AutoChromaFix don't work for me :(

Are you using ConverttoYV12() somewhere in your script?

Yes, this is the first point of my script, I capture with Lagarith in yuy2 and I use the command "ConverttoYV12".

luma = tfm(pp=0, slow=2)
chroma = vinverse().Srestore(omode="PP3", cache=10)

# manual sync: figure out which frame (previous,current aka p,c) of 'chroma' clip is most similar to current frame of 'luma' clip

# 46*log(|x-y|+1) uses the full [0,255]-range and scales little differences better than |x-y|*2
diffp = mt_lutxy(luma,chroma.selectevery(1,-1),"x y - abs 1 + log 46 *")
diffc = mt_lutxy(luma,chroma, "x y - abs 1 + log 46 *")

# average difference between compared frames
mp = mt_lutf(diffp,diffp,"avg",expr="x")
mc = mt_lutf(diffc,diffc,"avg",expr="x")

# build conditional masks based on the caculated comparisons
maskp = mt_lutxy(mp,mc,"x y < 255 0 ?")

# finally merge the luma of the tfm with the chroma of the srestore clip accordingly to the binary mask
MergeChroma(luma,chroma).mt_merge(chroma.selectevery(1,-1),maskp,luma=true,Y=2,U=3,V=3)

try this script, should fix the problem

The script doesn't work, the result is the same I use it without using it:

http://oi60.tinypic.com/xo1cef.jpg

http://oi62.tinypic.com/2m3io08.jpg

This is the script:

AVISource ("C:\Home.avi")

ConverttoYV12()
AssumeTFF()
AnimeIVTC(mode=2)
luma = tfm(pp=0, slow=2)
chroma = vinverse().Srestore(omode="PP3", cache=10)

# manual sync: figure out which frame (previous,current aka p,c) of 'chroma' clip is most similar to current frame of 'luma' clip

# 46*log(|x-y|+1) uses the full [0,255]-range and scales little differences better than |x-y|*2
diffp = mt_lutxy(luma,chroma.selectevery(1,-1),"x y - abs 1 + log 46 *")
diffc = mt_lutxy(luma,chroma, "x y - abs 1 + log 46 *")

# average difference between compared frames
mp = mt_lutf(diffp,diffp,"avg",expr="x")
mc = mt_lutf(diffc,diffc,"avg",expr="x")

# build conditional masks based on the caculated comparisons
maskp = mt_lutxy(mp,mc,"x y < 255 0 ?")

# finally merge the luma of the tfm with the chroma of the srestore clip accordingly to the binary mask
MergeChroma(luma,chroma).mt_merge(chroma.selectevery(1,-1),maskp,luma=true,Y=2,U=3,V=3)
Crop(24,10,-24,-20)
Lanczos4Resize(720,576)


I'm starting to lose hope :(

[wonkey_monkey]

I've just had a quick look - is it me, or is the chroma interlaced out of sync with the luma?

a=avisource("sample1.avi").assumetff
b=a.separatefields.doubleweave.selectodd
mergechroma(b,a)

seems to give a clearer view of the problem, at least.

[johnmeyer]

The following code shifts the chroma and fixes the problem, but it also introduces the problem on the other side of each object. Here's a before/after:

http://i177.photobucket.com/albums/w208/johnmeyer/Chromafix_zpsb696ea95.jpg

What's needed is a way to combine this code with a mask so that it only applies to chroma differences below and to the right of chroma transitions.LoadPlugin("c:\Program Files\AviSynth 2.5\plugins\CNR\Cnr2.dll")

source=AVISource("E:\Documents\Dnload\UNPACK\Sample1.avi").killaudio().AssumeBFF()
chroma=source.Cnr2("oxx",8,16,191,100,255,32,255,false)
output=ChromaFix(chroma)

stackhorizontal(source,output)
#return output

#-------------------------------

function ChromaFix(clip source)
{
Vshift=2 # 2 lines per bobbed-field per tape generation (PAL); original=2; copy=4 etc
Hshift=2 # determine experimentally
fields=source.SeparateFields() # separate by fields
fields=MergeChroma(fields,crop(fields,Hshift,Vshift,0,0).addborders(0,0,Hshift,Vshift))
Weave(fields)
}

[Stereodude]

Yes, this is the first point of my script, I capture with Lagarith in yuy2 and I use the command "ConverttoYV12"You're not using the command correctly. You need to set interlaced=true in the call.

like this:
ConvertToYV12(interlaced=true)

[feisty2]

xxxsource ()
tfm ().tdecimate ()
converttoyv12 ()

[Kyaneos]

You're not using the command correctly. You need to set interlaced=true in the call.

like this:
ConvertToYV12(interlaced=true)

This doesn't solve the problem.

xxxsource ()
tfm ().tdecimate ()
converttoyv12 ()

The problem persists :(

[Stereodude]

This doesn't solve the problem.Well, the problem is in the capture. It's not being caused by incorrect settings in AVIsynth as I initially guessed.

I'm not sure your captures can be fixed. It seems to have been damaged beyond what can be repaired. The Chroma from the two interlaced fields is merged. As such it will never line up with the luma correctly.

Open this script in VirtualDub to see what I mean:

AVISource("sample1.avi", pixel_type="YUY2").assumetff()
clip1=separatefields().selecteven()
clip2=separatefields().selectodd()
clip1u=(clip1.UToY())
clip1v=(clip1.VToY())
clip2u=(clip2.UToY())
clip2v=(clip2.VToY())
clip1chroma=YToUV(clip1u,clip1v)
clip2chroma=YToUV(clip2u,clip2v)
clip1luma=clip1.Greyscale()
clip2luma=clip2.Greyscale()
chromastack=stackvertical(clip1chroma,clip2chroma)
lumastack=stackvertical(clip1luma,clip2luma)
stackvertical(chromastack,lumastack)

Step through a few frames and the problem should be quite apparent. The even fields are on top and the odd ones are on the bottom. You'll see the Chroma is identical for them, but the luma is not.

[wonkey_monkey]

Kyaneos, are these samples completely un-reencoded cuts of captures? You didn't run them through VirtualDub (except by Direct Stream Copy) or anything to cut them?

I'm not sure your captures can be fixed. It seems to have been damaged beyond what can be repaired.

I disagree; the situation can certainly be improved, to a degree.

First problem: either the broadcast or the capture was weird, and the fields are out of sync, so there's an AA AB BB BC CC pattern going on (most of the animation is "shot on twos", but some of the backgrounds and camera moves are 25fps).

separatefields.doubleweave.selectodd

fixes that, but somehow re-interlaces the chroma! So:

a=avisource("sample1.avi").assumetff
b=a.separatefields.doubleweave.selectodd
mergechroma(b,a)

The above gives us the problem in its simplest form - progressive 25fps frames with blended chroma. Because the animation is (mostly) shot on twos, one can simply replace the chroma on the "bad" frames with chroma from a good neighbour.

a=avisource("sample2.avi").assumetff
b=a.separatefields.doubleweave.selectodd
mergechroma(b,a.selectevery(2,0,2))

This fixes it right up until the last frame (which could be a capture artefact).

The first sample seems to have a dropped frame, so the pattern needs to change slightly halfway through, and around there one frame will always be stuck with blended chroma:

a=avisource("sample1.avi").assumetff
b=a.separatefields.doubleweave.selectodd
pattern1=mergechroma(b,a.selectevery(2,0,2))
pattern2=mergechroma(b,a.selectevery(2,1,1))
return pattern1.trim(0,454)+pattern2.trim(455,0)

This is a reasonable stab at correcting it.

However, some of the animation in the first clip (backgrounds, zooms, and some foreground animation, frames 243 to 266) is "shot on ones" - one cel per frame - instead of "shot on twos" - one cel per two frames - as the second sample is in its entirety. This means there is still some residual chroma blending on certain parts (the beach near the end being the most obvious example).

This remaining chroma does seem to be fully blended, and while you could theoretically work backwards and forwards from good "shot on twos" frames, subtracting as you go through the "shot on ones" sequences, in reality you'd rapidly build up too much noise for this to be even worth attempting. If you're a glutton for punishment, though, that blended frame caused by the dropped frame in sample1 can be fixed that way.

So, there you go. I think the majority of the blending can be removed simply by dropping the bad frames of chroma and replacing them with good ones. Due to dropped frames you may need to change that selectevery every now again - it'll probably need to switch between (2,0,2) and (2,1,1) as above, or possibly also (2,0,0) and (2,-1,1).

And now, back to what I was supposed to be working on today until this distracted me! ;)

David

[johnmeyer]

David,

That's really good stuff!

[Kyaneos]

Kyaneos, are these samples completely un-reencoded cuts of captures? You didn't run them through VirtualDub (except by Direct Stream Copy) or anything to cut them?



I disagree; the situation can certainly be improved, to a degree.

First problem: either the broadcast or the capture was weird, and the fields are out of sync, so there's an AA AB BB BC CC pattern going on (most of the animation is "shot on twos", but some of the backgrounds and camera moves are 25fps).

separatefields.doubleweave.selectodd

fixes that, but somehow re-interlaces the chroma! So:

a=avisource("sample1.avi").assumetff
b=a.separatefields.doubleweave.selectodd
mergechroma(b,a)

The above gives us the problem in its simplest form - progressive 25fps frames with blended chroma. Because the animation is (mostly) shot on twos, one can simply replace the chroma on the "bad" frames with chroma from a good neighbour.

a=avisource("sample2.avi").assumetff
b=a.separatefields.doubleweave.selectodd
mergechroma(b,a.selectevery(2,0,2))

This fixes it right up until the last frame (which could be a capture artefact).

The first sample seems to have a dropped frame, so the pattern needs to change slightly halfway through, and around there one frame will always be stuck with blended chroma:

a=avisource("sample1.avi").assumetff
b=a.separatefields.doubleweave.selectodd
pattern1=mergechroma(b,a.selectevery(2,0,2))
pattern2=mergechroma(b,a.selectevery(2,1,1))
return pattern1.trim(0,454)+pattern2.trim(455,0)

This is a reasonable stab at correcting it.

However, some of the animation in the first clip (backgrounds, zooms, and some foreground animation, frames 243 to 266) is "shot on ones" - one cel per frame - instead of "shot on twos" - one cel per two frames - as the second sample is in its entirety. This means there is still some residual chroma blending on certain parts (the beach near the end being the most obvious example).

This remaining chroma does seem to be fully blended, and while you could theoretically work backwards and forwards from good "shot on twos" frames, subtracting as you go through the "shot on ones" sequences, in reality you'd rapidly build up too much noise for this to be even worth attempting. If you're a glutton for punishment, though, that blended frame caused by the dropped frame in sample1 can be fixed that way.

So, there you go. I think the majority of the blending can be removed simply by dropping the bad frames of chroma and replacing them with good ones. Due to dropped frames you may need to change that selectevery every now again - it'll probably need to switch between (2,0,2) and (2,1,1) as above, or possibly also (2,0,0) and (2,-1,1).

And now, back to what I was supposed to be working on today until this distracted me! ;)

David

David, first, many thanks for the explanation, fantastic job! :thanks:

These samples completely un-reencoded, they just have been cut with Vitual Dub (Direct Stream Copy).

A doubt, using these scripts, would it be necessary to deinterlace?

Thanks for everything

[wonkey_monkey]

It shouldn't be necessary to deinterlace - the script unweaves the fields and puts them back in the right order, and leaves you with progressive frames.

That said, there may be a filter you could run to more neatly line up the fields - there's a horizontal flicker between odd and even (most noticeable if you bob and look at the left hand blanking edge).

[Kyaneos]

It shouldn't be necessary to deinterlace - the script unweaves the fields and puts them back in the right order, and leaves you with progressive frames.

That said, there may be a filter you could run to more neatly line up the fields - there's a horizontal flicker between odd and even (most noticeable if you bob and look at the left hand blanking edge).

True, I have seen the horizontal flicker, you know any filter to fix the problem?