new deblocker script: funkydeblock

[Mug Funky]

a recent thread got me thinking of deblocking, so i made one based on blindPP and high/lowpass separating (what's a generic word for that?).

it gives VERY similar results to blindPP(quant=x,cpu=4) but can eliminate some bitrate pumping effects as well, an delivers a not-insignificant compressibility gain (not as much as removedirt, but hey, we can't all be geniuses)

this is of most use on HEAVILY compressed source material, otherwise regular blindPP or mpeg2dec3's "cpu=4" will be enough.


function gauss (clip c,int "radius") {

radius=default(radius,1)

radius=radius*4
c.bilinearresize(4*(c.width/radius),4*(c.height/radius)).bicubicresize(c.width,c.height,1,0)

}

function funkydeblock (clip c,int "quant",int "th",int "radius", bool "deblock",bool "depump"){

quant=default(quant,4)
th=default(th,3)
radius=default(radius,4)
deblock=default(deblock,true)
depump=default(depump,true)

blurd = c.gauss(4)

highpass=subtract(blurd,c)
deblocked=(deblock==true) ? highpass.blindpp(quant=floor(quant),cpu=4) : highpass

nopump=subtract(blurd,deblocked)
pump=subtract(blurd.temporalsoften(radius,th,th,2*th,2),deblocked)

(depump==true) ? pump : nopump

}


the first little function is useful as well - it'll use blurry-bicubic resizing to give a gaussian-like blur at whatever radius you tell it.


okay... usage:

funkydeblock(clip c,int "quant",int "th",int "radius", bool "deblock",bool "depump")

quant: the quant param usually fed into blindPP. default 4. tis actually is very conservative due to the fact it's only used on the highpassed clip, so even quant=31 gives a good picture.

th: temporalsoften threshold. only active when depumping is on. default 3. this param controls how sensitive to pumping the filter is. keep it low, unless you're seeing large jumps at I frames. increase only as much as you have to, or dim moving objects will start vanishing.

radius: the number of frames before and after currentframe used in temporalsoften. default 4. this is intended to smear GOP changes, so pumping doesn't show as much.

deblock: turn deblocking on/off (only depumping is used). default true

depump: turn depumping on/off (only deblocking is used). default true

[mf]

Originally posted by Mug Funky
high/lowpass separating (what's a generic word for that?).
Frequency discrimination? :)

[Chainmax]

Cool, maybe this will help me with "The Simpsons". I was just using MipSmooth but the blocks on the source don't seem to be macroblocking (they are too small and appear mostly on flat, evenly-colored areas). How fast is this filter?


P.S: now I only need something to reduce the sudden brightness changes...

[Chainmax]

I'll try to find a frame that shows clearly what I'm talking about.

[DarkNite]

After a few tests all I can really say is:

Wow, this works pretty damn good. Thank you. :D

[Mug Funky]

Frequency discrimination?

i hesitate to call it that because it's not true lowpassing... for all intents and purposes it is, but mathematically it's a huge botch :D

besides, you can do this with anything, not just blurring. i guess "differential filtering" but that's nondescript and probably wrong.

oh, and mf: would you have any idea how to get de-ringing going without touching the true edges too much? (and running at over 5fps :P) i did test clips for this where i encoded footage at q8 in xvid, I-frame distance 15 (so like a bad DVD), and this killed the blocks and the large scale pumping, but the ringing and pumpy-ringing remained.

i'll try "HQdering", but my computer's quite slow, hence my trying to keep scripts fast and simple (hehe. that and i don't have the short-term memory to write a "toad licking" script)

[mf]

Look at HQDering ;). It removes the true edges from the thickened "around-the-edges" mask. I will have to set this functionality togglable in the next version though, cause it's crippling my HQUnfilter functionality that I now use it for the most.

[Chainmax]

Here's a clip which perfectly illustrates the blocking issue I was talking about:

Sample (http://www.31012.com/~stuff/Clip1.vob).

Do you guys think funkydeblock can help clear out those blocks?

If you look closely, you'll also notice that the brightness changes slightly at a couple of spots. This is much more evident in other scenes but I couldn't locate them yet. What can I use to reduce/eliminate that?

[mf]

That's not just blockiness. That's film grain, a bad transfer, denoising, bad authoring, all of which lead to a certain kind of blockiness, and also the brightness changes. I think you're the best person to try it out - the script is posted and you have the source video. Why would we have to try it out to tell you if it works or not :rolleyes:.

[Prettz]

Originally posted by Chainmax

If you look closely, you'll also notice that the brightness changes slightly at a couple of spots. This is much more evident in other scenes but I couldn't locate them yet. What can I use to reduce/eliminate that?
Well if you don't particularly value your time you could always apply ColorYUV or LumaFilter manually to every affected scene.

[Mug Funky]

@chainmax:

hell yeah this deblocker can get rid of it.

just tried it then. luma variance can be treated as pumping, so you can use the script at it's default and they'll all go away :)

of course, it can't help with the other problems with this sample that mf mentioned, but that should be allright.

make sure you bob first (losslessly, ie with no blurring)

so you'll have:


mpeg2Source("C:\Ack\Clip1.d2v")

telecide(order=0,guide=1)

coloryuv(levels="pc->tv")
funkydeblock(th=5)
coloryuv(levels="tv->pc")



the 0,.5 in bob makes the bicubic filter work without blurring, which is important for putting the stream back together without loss.

[edit]

oh, what am i doing! you can telecide it first and save all the bobbing and un-bobbing...

also there seems to be some overbright things which invoke the subtract inverted dot bug, so the script above has been modified accordingly.

[mf]

Originally posted by Mug Funky
also there seems to be some overbright things which invoke the subtract inverted dot bug, so the script above has been modified accordingly.
Why don't you workaround that in your script, maybe a togglable switch? Could save people who don't know about the bug some headaches :). I've already described to you how to do it.

[Mug Funky]

hmm... i'll maybe do that, but the bug isn't always there, and i'm wanting to nut it out properly before i use a slower workaround.

for example, the bug doesn't show up with the following:


blurred = clip.magicalblurfilter(8)

subtract(blurred,clip)
subtract(blurred,last)


but it will for:


blurred = clip.magicalblurfilter(8)

subtract(clip,blurred)
subtract(last,blurred)


which otherwise will give the same output.

but then again, i've made the deblocker by those rules (unless i got confused) but the bug shows up either way i arrange things. until i solve this i won't bother putting any extra stuff in... but if it defeats me completely then i'll do it :)

[mf]

That gave me an idea. How about trying this:
ColorYUV(levels="pc->tv").Invert().ColorYUV(levels="pc->tv")
So that the padding is always 20 values off, instead of 16 off on the left and 20 off of the right. Alternative could be:
Levels(20, 1, 235, 20, 235, false)

[Manao]

Just a warning with subtract : on the luma, when both clip are identical, it returns 126, not 128, so it is slightly biased. It explains the dots.

[Mug Funky]

ah, is that it? does this mean it's a simple matter to fix?

[Manao]

May be, I can't be sure of it ( I can't yet compile AviSynth on my computer ). I sent a workaround to sh0dan, but the probleme is that subtract will then have a different behavior in RGB and in YUY2. So there is also a decision to take.

If you don't need YV12LUT, I advise you to use YV12Subtract, bundled with the masktools ( it's faster than subtract ). If you use YV12LUT, you'll have to wait for me to find the bing between YV12LUT and YV12Subtract.

[Mug Funky]

ah. i was just about to ask if YV12subtract exhibited the same behaviour...

i'll switch to that then. :)

[Chainmax]

Originally posted by mf:
That's not just blockiness. That's film grain, a bad transfer, denoising, bad authoring, all of which lead to a certain kind of blockiness, and also the brightness changes. I think you're the best person to try it out - the script is posted and you have the source video. Why would we have to try it out to tell you if it works or not :rolleyes:
I phrased myself wrong. I don't know much about blocking other than it's bad, so I wanted to know if what I call "blocks" were actually blocks and could therefore be removed with this. Sorry about that.

mugfunky: the script I'd have to use would be

IVTC
coloryuv(levels="pc->tv")
funkydeblock(th=5)
coloryuv(levels="tv->pc")
whatever else

then?

[Manao]

I should have checked the code before answering. YV12Subtract will behave in the same way Subtract does considering the dot issue. But the value will be centered on 128.

I'll add a parameter to change that behavior. I'll also correct a slight bug that sneak its way in when resolution are mod 4 only. So wait for another release.

[Chainmax]

Well?

[Manao]

Ooops, I forgot to add that to the changelog for the latest version of the Masktools. I added a parameter to the filter, which documentation is now :

6) YV12Subtract(clip clip1, clip clip2, int tolerance,
int offX, int offX, int w, int h, bool widerange)
(works in-place, mode=2 will copy the plane of clip2 to clip1)
Performs almost exactly the same as Subtract, but uses MMX.
- If widerange is set to false ( default ), the behavior will be the following :
if mode<0:
if clip1 < clip2, output = 128 + clip1 - clip2
else output = clip1 - clip2
else
output' = |clip2 - clip1| - tol
if output'<0, output = output'
else output = output'
- You can remark that overflow is possible, which leads to the dot issue.
To correct that, use the parameter widerange = true. The tolerance is then
used in a different way : the filter will return

128 + ((clip1 - clip2) / 256)^(1/tolerance) * 128.

Thus, no overflow. The tolerance act as a gamma parameter, which can come in handy.

[JC_Nagash]

What is the requeriments filters to funkydeblock?

[rkalwaitis]

Thanks Mug Funky

[tormento]

Sorry for necroposting.

Asd-G released a new BlindPP build (https://github.com/Asd-g/avisynth-blindpp/releases/tag/1.0.0), it would be nice to have and updated script.

[real.finder]

it would be nice to have and updated script.

I think it dont need update since it so simple and should work even with HBD