after IVTC'ing anime material still some combed frames left

[Sp00kyFox]

hello there

have some trouble here to ivtc batman the animated series. tried the following usual combo:

tfm(chroma=true, pp=0, slow=2)
tdecimate(mode=1)

result is ok except for some residual interlaced frames. with pp=5 it gets rid of the combing but there is some chroma overlapping (left pp0, right pp5):

http://img6.imagebanana.com/img/y5tnbdu2/0945pp0.PNGhttp://img6.imagebanana.com/img/gjm22osq/0945pp5.PNG

thought about srestore (doubleblend removal) with blur or vinverse as a preprocessing step:

vinverse() #or blur(0,1)
Srestore(omode="PP3")

but since tfm mostly finds good matches the quality is siginificantly worse than the tfm.tdecimate clip in the non-combed frames.
so the last thing I tried was to combine both clips with conditionalfilter. only to use frames of the srestore clip on still combed frames of the tfmclip.
but since the frames doesn't match exactly it introduces jerky movement on cam panning:

ConditionalFilter(tfm, sres, tfm, "IsCombedTIVTC(chroma=true)", "=", "true")
tdecimate(mode=1)

well I ran out of ideas.
hope you can help me with the problem.

I uploaded the intro of an episode as a sample (35MB):
http://mir.cr/14HLXHXE

[librarian]

I think this script may be effectve:



blur(0,1)#.sharpen(0,0.7)# perhaps
fixblendivtc()
decimate()

[Sp00kyFox]

@librarian
that's nearly the same solution like my vinverse/blur.srestore-try with the same described problems.
besides that fixblend seems to produce worse results than srestore. look at frame 333 with your script (the eyes):

http://img6.imagebanana.com/img/q2zib18a/0333fixblend.PNG

[librarian]

I cannot get your result. This is my output:

http://www.imagebanana.com/view/83a5uytn/frame333.png

[Sp00kyFox]

yeah you're right. the error was probably caused by non-linear order of frame serving.
I used vdub to preview the avs. put in a requestlinearorder after fixblendivtc and its ok now.

poblem still remains: because of the preprocessing step for the blend removal there is a loss in
sharpness and detail in fine textured areas compared to the tfm.tdecimate clip.

edit: my script for now with the best results:

DGDecode_mpeg2source("VTS_01_1.d2v")
ColorMatrix(d2v="VTS_01_1.d2v", threads=0, interlaced=true)

vinverse().Srestore(omode="PP3", cache=10)
tdecimate(mode=1)

any suggestions?

[Sp00kyFox]

came up with a solution while searching through the interwebs. maybe it can help someone else.
here is the commented code (based on Didée (http://forum.doom9.org/showthread.php?t=160575)), you still have to add extra filters for any other artifacts or picture enhancements:

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)

tdecimate(mode=1)



# debug output. check calculations and decisions

#stackhorizontal(stackvertical(maskp,luma)\
#,stackvertical(chroma.selectevery(1,-1),chroma))

#stackhorizontal(stackvertical(diffp,diffc)\
#,stackvertical(mp,mc))


you can verify that you have the same problem with the following two lines. look for field blendings in the chroma plane:


separatefields.bilinearresize(width,height)
stackvertical(last.greyscale(),stackhorizontal(last.utoy(),last.vtoy()))


edit:
simplified the code (only current or previous frame is necessary) and change to a better frame distance norm. since after every calculation the result is rounded to the next integer in [0,255] it's better to scale it logarithmically, otherwise small differences are indistinguishable. the constant factor 46 is there to stretch the value to our luma range.

[DragonM]

came up with a solution while searching through the interwebs. maybe it can help someone else.
here is the commented code (based on Didée (http://forum.doom9.org/showthread.php?t=160575)), you still have to add extra filters for any other artifacts or picture enhancements:

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)

tdecimate(mode=1)



# debug output. check calculations and decisions

#stackhorizontal(stackvertical(maskp,luma)\
#,stackvertical(chroma.selectevery(1,-1),chroma))

#stackhorizontal(stackvertical(diffp,diffc)\
#,stackvertical(mp,mc))


you can verify that you have the same problem with the following two lines. look for field blendings in the chroma plane:


separatefields.bilinearresize(width,height)
stackvertical(last.greyscale(),stackhorizontal(last.utoy(),last.vtoy()))


edit:
simplified the code (only current or previous frame is necessary) and change to a better frame distance norm. since after every calculation the result is rounded to the next integer in [0,255] it's better to scale it logarithmically, otherwise small differences are indistinguishable. the constant factor 46 is there to stretch the value to our luma range.

This really seems to help with a video I have. The video I have has chroma blends quite often, especially at scenechanges it happens a lot. There's also one particular scene where it doesn't fix all of them, but I'm not sure what to change in this script to possibly improve it. I could post a sample clip of that particular scene later.

[Sp00kyFox]

This really seems to help with a video I have. The video I have has chroma blends quite often, especially at scenechanges it happens a lot. There's also one particular scene where it doesn't fix all of them, but I'm not sure what to change in this script to possibly improve it. I could post a sample clip of that particular scene later.
a sample clip would be helpful. besides that the main core of the script is the srestore call. and this function only fixes double blends. if you have scenes with triple (or more) blendings you're pretty much screwed. well at least I don't know how to fix those. I guess that's the problem in your case. (or you have to tweak the difference norm)

[x265]

I have these DVD's, i will try this script. :D

[lordsmurf]

My source is a 29.97 cartoon with bad interlace resizing.
A TFM().TDecimate() removed most of the interlace, but there are chroma ghosting and linear chroma leftovers in some frames.

I attempted to run the above script, but I get this:
Average: all clips must be have same or greater number of frames as the first one.
(Srestore.avsi, line 53)
(New File (1), line 12)

What's causing this? :confused:

[SaurusX]

What's causing this? :confused:

I’ve found that srestore v27h is the best to use with animated material. Far more effective. And other versions will cause the error you’re encountering. I’ve ALSO had problem getting 27h to run with “pp3” in 64bit. 32bit only for this case