Anime problem.

[Ramromulus]

I'm doing this anime and it seems to have this slight colored after image. If I turn chrome=true to false in TIVTC it turns into more of a line image. Here is my avs script:

LoadPlugin("C:\Documents and Settings\Desktop\Encoding Tools\Filters\DGDecode.dll")
LoadPlugin("C:\Documents and Settings\Desktop\Encoding Tools\Filters\TIVTC\TIVTC.dll")
mpeg2source("D:\source\source.d2v", cpu=4,iPP=true,idct=5)
tfm(d2v="D:\source\source.d2v", order=0,mode=1,pp=7,field=0,slow=true,mChroma=true,cthresh=8,chroma=true,blockx=16,blocky=16,MI=100)
tdecimate(mode=1, cycleR=1, cycle=5, chroma=true, dupThresh=1.1, nt=0, blockx=32, blocky=32)

And here are some images(copy and paste links to browser):

http://tu.adultbouncer.com/problem.png
http://tu.adultbouncer.com/problem2.png

Is there any way to get rid of both?

[Mug Funky]

hmm. could you maybe post a sample from the vob (in a place that would cause this problem).

the source is very clean, so i imagine it will telecine quite easily. it's possible you don't need anything fancy in TFM - in my experience it doesn't need much help finding matches on clean sources.

that first image is being interpolated in parts, but from the look of the second image, it's not at all needed. so maybe defaults for TFM are the way to go?

[Scarfac3]

mug is right...you don't need something fancy...just use decomb with yatta and fix the problem manually
but you'll have to use dvd2avi if you used DGIndex cause yatta doesn't work with DGIndex

[tritical]

I've seen that effect in other anime (fmp and ikki come to mind), where one of the chroma planes will move independently of the luma from time to time. If tfm is still giving you that match, but just deinterlaced, with chroma=true and in mode 1, then that's the best out of p, c, or n. You could try mode=2 which would also test b and u, or just use a manual override to check if b or u fix it. If none of the five matches are better then that then your options are: 1.) live with the deinterlaced image... 2.) leave it as is if it's not too visible at full speed (i.e. chroma=false)... 3.) more manual means like yatta, copying over a good frame if there's a good duplicate frame nearby, or trying to edit it in an image editing program. Matching from the opposite field in tfm *might* help as well.

[MasterYoshidino]

That source (Akibakei Kanojyo) is a classic example of chroma combing -_-. IMHO there is no chance to get rid of it through deinterlacing, but some decimation schemes do delete frames like that *but cause choppy panning scenes*. All you can do is a simple blur(-1.0) .blur(1.0) , which will reduce the combs to a "ghost" image. (apply blur after ivtc).

[ArabianSwan]

well I had that with Angelic Layer.. FreezeFrame fix it.. nothing fancy :p

[Mug Funky]

hmm. i wonder what the source of this combing is?

the PAL version of angelic layer has none of this particular chroma combing (though it's a field-blend conversion).

perhaps it's a yuy2/yv12 thing? maybe these iffy titles are encoded as progressive but are really hard-telecines? or maybe there's just some settings going awry in the DGindex/avs stage?

how about a little experiment... right after mpeg2source, put:

assumetff()
converttoyuy2(interlaced=true)

and run telecide, etc as normal. if the ghosts disappear, then the source is okay, and you'll have to hunt down what causes the chroma to come out wrong (perhaps postprocessing without "ipp=true" might cause this?).

[Kintaro]

you can find this "chroma ghosting" on quite a few anime sources like mahoromatic, ikkitousen, ... mostly on highmotion and near scenechanges.
to get rid of 'em I wrote a quick little function called chromafieldkiller. takes one chromafield, doubles its height, and merges with the original luma on single frame basis.

function CFK(clip clip, int frame, int "order"){

order = default(order, 1)

chroma = (order == 1) ? clip.separatefields().selectodd().bilinearresize(width(clip),height(clip)) \
.converttoyuy2().chromashift(L=1)
\ : clip.separatefields().selecteven().bilinearresize(width(clip),height(clip)) \
.converttoyuy2().chromashift(L=-1)

CFKclip = mergechroma(clip.converttoyuy2(),chroma).trim(frame,frame)

new = clip.isYUY2() ? CFKclip :
\ clip.isYV12() ? CFKclip.converttoYV12() :
\ clip.isRGB24() ? CFKclip.converttoRGB24() :
\ CFKclip.converttoRGB32()

final = (frame == 1) ? clip.trim(0,1).deleteframe(1) + new + clip.trim(frame+1,0) :
\ (frame == clip.framecount) ? clip.trim(0,frame-1) + new :
\ clip.trim(0,frame-1) + new + clip.trim(frame+1,0)

return final }


you can take out chromashift if you want since it doesnt help that much anyways, the doubled field wont fit perfectly. you wont notice the little difference on a playing video though, especially if you're using smoother afterwards. "order" parameter was named according to decomb, declares which field will be kept.

Hooray for Single-Frame-Processing!!

[Ramromulus]

Sorry for sorta dissapearing, got caught up in other things. Alright, I can fix the most of it in yatta using freezeframe as long as it's not a panning scene. The panning scenes go "cccpp" first p being post processed.

The chroma ghosting appears on the two "p" frames. Now one "p" frame can be fixed with freeze frame but the other can't cause there's no frames to match it with. I tryed switching the non matching "p" frame to an "n" frame which gave me a matching frame to freezeframe with but in turn caused jerkiness.

Any help appreciated. I'm also new to yatta, so help with that would be appreciated too.

PS: CFK doesn't fix the problem :(.

[Kintaro]

disable postprocessing in tfm() and it'll work. once its blended you cant separate the fields anymore.

[Mug Funky]

requesting a vob chunk for great justice :)

i want to see what the cause of this is, out of sheer morbid curiosity.

[Chainmax]

Kintaro, I assume CFK goes after IVTCing? This is awesome news: with TIVTC, LRemoveDust and now CFK I might finally be able to make a decent rip out of my Spawn 1st Season DVDs :).


P.S: Kintaro, when you say to disable postprocessing in TFM you mean setting PP=0, right? I don't understand why, since only modes 1 and 5 use blending.

[Kintaro]

yes cfk should be placed post telecide.
it doesnt really matter how you're messing with the fields, interpolating is as destructive as blending for that matter.

Ramromulus sent me a vob today. 2-3 out of 5 frames contain chromaghosting on at least one field, the ones with both fields borked are not fixable at all, merely choosing less the evil.
additional it doesnt follow any regular pattern, so its not possible to apply cfk eg. on every 4th+5th frame. massive amount of manual work would be needed and it still wont get perfect.
without doubt the same problem as seen on the sources I mentioned earlier, but on a whole new level of evilness.

[Chainmax]

Originally posted by Kintaro
yes cfk should be placed post telecide.
it doesnt really matter how you're messing with the fields, interpolating is as destructive as blending for that matter.

Would it make sense to use a deinterlacer after CFK?

[Kintaro]

if theres combing left after ivtc then deinterlacing usually makes sense, yes ;)

[Ramromulus]

I could send you a sample mug funky, but I have no where to host it so maybe you could suggest some alternitives.

[Chainmax]

Originally posted by Kintaro
if theres combing left after ivtc then deinterlacing usually makes sense, yes ;)
Well, since it's not a good idea to use IVTC PP before CFK I wasn't sure if it was a good idea to deinterlace after it. So, IVTC(no PP)--->CFK->Deinterlace will work out fine then (just making sure, I'm kinda neurotic :))?

P.S: how do I know which field to keep and what should I set frame to?

[Kintaro]

the idea is to totally drop the field with ghosting. once you deinterlace, the ghosted field mixes into the good one. hence it makes cfk useless. you can deinterlace as much as you want afterwards since the bad field is gone then.

as mentioned in the first post cfk works on single frame basis, so frame is the number of the frame it'll be applied on.

you'll probably have to find out which field should be kept for every single frame. ramromulus' source was the first one I've seen so far where there's almost a pattern.