Any way to remove this dot crawl?

[Logan9778]

Hi guys.

Got some help from some people with the Batman TAS ghosting problem, and it turned out that it was a blended chroma. So with their help, I got some code that de-telcined the luma and unblended the chroma, then put it all back together again.

Now I'm left with a dot crawl? problem. Pretty sure it's dot crawl. Rainbow looking bleed on the black lines making up the figure of the character, etc.



Any suggestions?

I've tried a couple, including tcomb(), but nothing seems to touch it. Probably because of the blended chroma.

[Sharc]

If your source is NTSC mpeg2 720x480 try
http://home.earthlink.net/~tacosalad.../dotcrawl.html
It proved to be effective for some cases here. See also the Usage Notes.

It's a Vdub plugin but you can import it in avisynth.

[foxyshadis]

Stubborn rainbowing that doesn't respond to the normal restricted tests of dedicated filters are best smacked with fft3dfilter.

fft3dfilter(sigma=2,bt=3,plane=1)
fft3dfilter(sigma=2,bt=3,plane=2)

Play with sigma, sigma2, sigma3, and sigma4 as necessary. As a side effect, flat areas will get flatter; good for anime, bad for live-action.

BTW, Dot Crawl is the mirror image of Rainbowing; it's a checkerboard pattern in the luma arising from the same crosstalk that causes rainbowing in analog transmission. (Your capture looks more like digital-induced rainbowing, which is probably why it doesn't respond to rainbow-specific plugins.)

[Logan9778]

Thanks guys!

The fft3dfilter helps a little when I up the sigma to 10, but I'm still getting some minor rainbowing on the pic of the security guard and some other scenes. One fat black line on a blimp was also REALLY rainbowing, but sigma=10 tones it down a lot. sigma=2 has little effect.

Here's the code I'm using so far

LoadPlugin("C:\DGDecNV2053\DGDecodeNV.dll")
loadplugin("c:\program files (x86)\avisynth\plugins\fft3dfilter.dll")
SetWorkingDir("C:\Program Files (x86)\AviSynth\plugins")
SetMTMode(5,6)
DGSource("F:\Test Space\batman\title01.dgi") #source
SetMTMode(2)
y=tfm(mchroma=false).tdecimate(cycle=5) #ivtc and decimate original luma
blank=utoy().spline36resize(720,480) #fake luma (overwrite the y with u) So, uuv, u is now luma.  v is untouched.  No weight option.
mergeluma(last,blank) #fake blended yuv (last is the original clip) default weight is 1 (100% lumu from clip2, i.e. blank) now we have blank's luma, and source chroma.  So luma is still just u. v is untouched.
srestore(omode="pp3").tdecimate(cycle=5) #fix chroma blend and decimate
mergeluma(last,y) #merge back original luma
fft3dfilter(sigma=10, bt=3,plane=1)
fft3dfilter(sigma=10, bt=3,plane=2)

Some guy told me all the shows like this were mastered in S. Korea back in the 80's and 90's on really crummy equipment, so that's probably the bulk of the problems. Looks like they had crazy ideas on how to do things as well.

Here's a clip of the security guard .m2v if anyone wants to look at it.

https://mega.nz/#!SfpxxC5A!QrPZufKo7...DjwCoC5gyxRudY

So, I've seen a definition of dot crawl, but can't find one for rainbowing. Is it the chroma leaking into the luma channel (not that I understand how that works)

[foxyshadis]

I guess I shouldn't make that much of a distinction; if you UToY or VToY a rainbowed'd clip it would look just like dot crawl. The main difference is that you can use much harsher blurring to make it look good than for dot crawl, since a little chroma bleed is more tolerable than edges disappearing.

The whole problem comes from luma and chroma being mixed together in composite video and then unmixed. Not only is the process lossy at certain high frequencies, there's an enormous amount of RF interference that tends to get picked up by the unshielded cables that act as an antenna; channel 3 or 4 is normally used, but usually someone is transmitting on them in the vicinity, making noise even worse.

[Logan9778]

Thanks. Sorry for the late reply. My computer finally crashed on me.

I'll try and mull all this over.