really strong settings for Deblock_QED_MT2

[hydra3333]

Not understanding how the settings work for Deblock_QED_MT2, is someone able to give a few examples of parameters in order of increasing deblocking strength ?
Assuming quite blocky 1440x1080i25 source. edit: it's after the source has been deinterlaced and resized to 576p50

I'd thought
Deblock_QED_MT2(quant1=20)
Deblock_QED_MT2(quant1=30)
Deblock_QED_MT2(quant1=40)
might be it, however it doesn't seem to be right.

[Gser]

http://www.google.com/search?q=Deblock_QED

[hydra3333]

Thanks.
Deblock_QED_MT2 internally uses two different instances of deblock() -
one for block borders, and one for block interiors.
That's why the function has those "xxx1" and "xxx2" parameters.
Very roughly,
"quant1" can be seen as "strength" for borders
"quant2" can be seen as "strength" for block interiors
"bOff1" is "sensitivity to detect blocking" for borders
"bOff2" is "sensitivity to detect blocking" for block interiors
"aOff1" is halfway "sensitivity", halfway a strength modifier for borders
"aOff2" is halfway "sensitivity", halfway a strength modifier for block interiors
defaults are
quant1 int = 24 Strength of block edge deblocking.
quant2 int = 28 Strength of block internal deblocking.
aOff1 int = 2
bOff1 int = 4
aOff2 int = 4
bOff2 int = 8

Ah, I'd entirely forgotten about this: http://forum.doom9.org/showthread.php?t=121303
In part someone suggested
1) Higher strength, but smaller sensitivity/threshold - should kill the ugliest blocks, leaving smaller (&less visible) almost intact: should preserve more details as well. Hence my settings for Deblock().
2) Lower strength, but higher sensitivity/threshold - should deal with almost every block, smoothing both smaller & larger ones, doing not too much harm to details, however leaving the larger blocks less processed. I could call it Didee's approach, since his filter isn't recommended for severe blocking.

So maybe Deblock_QED_MT2(quant1=48,aOff1=1,bOff1=2,quant2=24,aOff2=2,bOff2=4)
might be what I'm looking for with a source with sharp block edges; 1440x1080i25 after deinterlacing and resizing to 576p50 using neuron2's great NV tools. I'll have to give it a try.

There seem to be a couple of MT2 versions of around after Search, so I hope I'm using the right one
# Changes 2008-08-18: (Didée)
# - Replaced the ugly stackXXX cascade with mt_LutSpa() (requires MaskTools v2.0a35)
# - Changed Quant and Offset defaults to 24,28,2,4,4,8
function Deblock_QED_MT2 ( clip clp, int "quant1", int "quant2", int "aOff1", int "bOff1", int "aOff2", int "bOff2", int "uv" ) {
quant1 = default( quant1, 24 )
quant2 = default( quant2, 28 )
aOff1 = default( aOff1, 2 )
bOff1 = default( bOff1, 4 )
aOff2 = default( aOff2, 4 )
bOff2 = default( bOff2, 8 )
uv = default( uv, 3 ) # u=3 -> use proposed method for chroma deblocking
# u=2 -> no chroma deblocking at all (fastest method)
ox = clp.width() # u=1|-1 -> directly use chroma debl. from the normal|strong deblock()
oy = clp.height()
block = clp.mt_LutSpa(false,"x 1 + 8 % 1 < x 8 % 1 < y 1 + 8 % 1 < y 8 % 1 < | | | 255 0 ?",U=3,V=3)

# create normal deblocking (for block borders) and strong deblocking (for block interiour)
normal = clp.deblock(quant=quant1,aOffset=aOff1,bOffset=bOff1)
strong = clp.deblock(quant=quant2,aOffset=aOff2,bOffset=bOff2)

# build difference maps of both
normalD = mt_makediff(clp,normal,chroma=uv>2?"process":"ignore")
strongD = mt_makediff(clp,strong,chroma=uv>2?"process":"ignore")

# separate border values of the difference maps, and set the interiours to '128'
strongD2 = mt_lutxy(StrongD,block,expr="y 255 == x 128 ?",U=uv,V=uv)
normalD2 = mt_lutxy(normalD,block,expr="y 255 == x 128 ?",U=uv,V=uv)

# interpolate the border values over the whole block: DCTFilter can do it. (Kiss to Tom Barry!)
# (Note: this is not fully accurate, but a reasonable approximation.)
strongD3 = strongD2.mt_lut(expr="x 128 - 1.01 * 128 +",U=uv,V=uv).dctfilter(1.0,1.0,0.0,0.0,0.0,0.0,0.0,0.0)# .yv12lut("x 128 - 2 / 128 +")

# apply compensation from "normal" deblocking to the borders of the full-block-compensations calculated
# from "strong" deblocking ...
strongD4 = mt_lutxy(strongD3,normalD2,expr="y 128 == x y ?",U=uv,V=uv)

# ... and apply it.
deblocked= mt_makediff(clp,strongD4,chroma=uv>2?"process":"ignore")

# simple decisions how to treat chroma
deblocked = (uv<0) ? deblocked.mergechroma(strong) : uv<2 ? deblocked.mergechroma(normal) : deblocked

deblocked
return( last )
}

[Gser]

You forgot

uv int = 3
Deblock chroma:

* 2 : Copy chroma from source.
* 3 : Process chroma.
* 1/-1 : Process chroma with normal/strong Deblock().

And yes that is the newest one.

[hydra3333]

Saw this http://forum.doom9.org/showthread.php?p=1568355#post1568355 mentioned as updated version of Deblock_QED (2011-11-29)
edit:

They're close enough to be the same but updated. File compare shows:
Comparing files Deblock_QED_MT2.avs and DEBLOCK_QED.AVS
***** Deblock_QED_MT2.avs
# http://avisynth.org/mediawiki/Upload/f/f7/Deblock_QED_MT2.avs
#
# Changes 2008-08-18: (Didée)
# - Replaced the ugly stackXXX cascade with mt_LutSpa() (requires MaskTools v2.0a35)
***** DEBLOCK_QED.AVS
# Changes 2008-08-18: (Didée)
# - Replaced the ugly stackXXX cascade with mt_LutSpa() (requires MaskTools v2.0a35)
*****

***** Deblock_QED_MT2.avs

function Deblock_QED_MT2 ( clip clp, int "quant1", int "quant2",
\ int "aOff1", int "bOff1", int "aOff2", int "bOff2", int "uv" )
***** DEBLOCK_QED.AVS

# Changes 2011-11-29: (06_taro)
# - Replaced (chroma=uv>2?"process":"ignore") by (chroma=uv>2?"process":"copy") to avoid garbage clip when uv=2.
# The formal parameter is not used by MaskTools2 any more, if ever used.
# Foxyshadis once mentioned chroma="ignore" but I had never found a document containing it.

function Deblock_QED ( clip clp, int "quant1", int "quant2",
\ int "aOff1", int "bOff1", int "aOff2", int "bOff2", int "uv" )
*****

***** Deblock_QED_MT2.avs
# build difference maps of both
normalD = mt_makediff(clp,normal,chroma=uv>2?"process":"ignore")
strongD = mt_makediff(clp,strong,chroma=uv>2?"process":"ignore")

***** DEBLOCK_QED.AVS
# build difference maps of both
normalD = mt_makediff(clp,normal,chroma=uv>2?"process":"copy")
strongD = mt_makediff(clp,strong,chroma=uv>2?"process":"copy")

*****

***** Deblock_QED_MT2.avs
# ... and apply it.
deblocked= mt_makediff(clp,strongD4,chroma=uv>2?"process":"ignore")

***** DEBLOCK_QED.AVS
# ... and apply it.
deblocked= mt_makediff(clp,strongD4,chroma=uv>2?"process":"copy")

*****

[hydra3333]

I woud like to try a new approach but am a bit stuck on "how".

I have PAL 576i sources (and sometimes a 1440i) from TV captures. Mostly they are badly blocked with some ringing too. There's a lot of fast movement.

I am using this to deblock and dering and etc. It works however the result seems a tad soft.

MPEG2Source("par.d2v",info=0,ipp=true,cpu=6) # DEBLOCK and DERING
#MPEG2Source("par.d2v",info=0,ipp=true,cpu=4) # DEBLOCK
#MPEG2Source("par.d2v",info=0,ipp=true,cpu=0)
SetMTmode(mode=2)
AssumeFPS(25)
AssumeTFF()
# For RE-INTERLACING http://forum.doom9.org/showthread.php?p=1110741#post1110741
# AssumeTFF().SeparateFields().SelectEvery(4, 0, 3).Weave() -> TFF
# * AssumeBFF().SeparateFields().SelectEvery(4, 0, 3).Weave() -> BFF
# AssumeTFF().SeparateFields().SelectEvery(4, 1, 2).Weave() -> BFF
# AssumeBFF().SeparateFields().SelectEvery(4, 1, 2).Weave() -> TFF
QTGMC(Preset="Very Slow",EdiThreads=2,Sharpness=1.3,SLMode=2,EZKeepGrain=1.2,NoiseProcess=2) # result is double framerate progressive, so re-interlate it later
# Re-Interlace and halve framerate
AssumeTFF()
Blur(0,0.5).SeparateFields().SelectEvery(4,0,3).Weave() #reinterlace - ASSUMED TFF HERE # BLUR(0,.5) per http://forum.doom9.org/showthread.php?p=1488308#post1488308
My objective is to clean up the blocking and ringing and leave it sharp with as much detail as possible. I run it through x264, using a batch file with
"C:\software\avs2yuv\avs2yuv.exe" "%avs1%" -o - | "%X264EXE%" - --stdin y4m --thread-input --frames %FRAMES% --profile high --level 4.1 --preset slower --interlaced --tff --no-cabac --bitrate 8000 --sar 16:11 --colormatrix bt470bg -o "%outputfile.mp4%"
to give it plenty of bitrate headroom and use the result on an old WDTVlive media player. There are probably better x264 parameter settings, suggestions welcomed about that.

I recall seeing posts saying that Deblock_QED_MT2 is newer (more "effective"?) than DEBLOCK in MPEG2SOURCE, and wondered if Deblock_QED_MT2(quant1=48,quant2=26) may provide a more visually appealing "better" result for me.

My query is how to work Deblock_QED_MT2 into the script above and also manage deringing, and also calming produced by QTGMC ... it doesn't have to be QTGMC, alternative suggestions welcomed.

Thanks.

[Bloax]

I might be wrong here, since I know nothing about deinterlacing. (And thus it might be a byproduct of it.)

But resizing something that you want to deblock is generally a Bad Idea (TM). Because then the otherwise rather uniform sizes of the blocks get mixed and stuff. (Which is not good.)
I may be wrong just here though. For reasons above.

[Gser]

This is how you deblock interlaced material which should be deblocked before deinterlacing.
i=LAST
SeparateFields().PointResize(i.width,i.height)
AssumeFrameBased().deblock_QED()
GetParity(i) ? AssumeTFF() : AssumeBFF()
SeparateFields().SelectEvery(4,0,3).Weave()

[TheSkiller]

Yes, it is pointless to try to deblock after resizing or deinterlacing.
The workaround script posted by Gser is required for deblocking interlaced sources.

There were comparison pictures somewhere that showed that Deblock_QED is much better at eliminating slight to medium blocking while keeping details compared to MPEG2Source's internal deblocking (cpu=x).

Try cpu=0 (no deblocking and no deringing) and use Deblock_QED. Ringing (JPEG noise effect) can be defeated using Edgeclean.

[jconklin]

You might try SmoothD2 see http://forum.doom9.org/showthread.php?t=164800 which works well with material that needs strong deblocking. It allows the deblocking strength to be varied from the block edge to the block center. It also allows the deblocking strength to be decreased in darker areas.

I did the rewrite on SmoothD2 so I think it's great. I am also looking for ways to improve it in the next release.

[Bloax]

SmoothD2
I once wanted to test it, but then something went wrong.

After trying to get it again, I now remember what exactly went wrong.

The links you have on the site go to the source page, and a .dll of interest, say - SmoothD2.dll, can't be downloaded.

[jconklin]

Appologies for not being able to download. The download link is at the very bottom of the page on the right hand side. It is a small down pointing arrow. I will redesign so there is a box at the top of the page that will take you to a separate download page.

If the download does not work please repost so I can get it fixed.

Thanks for letting me know.
Jim

[StainlessS]

Yep, downward arrow link works, had looked there before, and gave up.

EDIT: Click the bottom of the two.

[Bloax]

that's some nasty design right there.

Usually when you have a file name that's clickable on such occasions (I may very well be making a wrong assumption, but FTP sites are like this), it means "download this thingy".
Here they instead serve as the "(File) Source" links. Which lead to absolutely nowhere if you actually want "that" file.

Edit: What exactly do you need for this? Because the .dll doesn't even seem to "work"! (Using LoadPlugin() makes it spit out an error, yikes.) o_O

[jconklin]

Appologies for having put out a filter that causes problems.
This is what I have been doing to figure out what the problem is and how to fix it.

I uninstalled avisynth.
I checked that the environment variable for the plugin directory had been removed.
I made sure there was no directory in C:\Program Files (x86)\ called AviSynth
I downloaded the latest version of avisynth v.2.6.0 ST, 32-bit from SourceForge, file name AviSynth_110525.exe and installed it.
It installed in C:\Program Files (x86)\AviSynth 2.5

In the plugins directory there are 3 files. colors_rgb.avsi, DirectShowSource.dll, and TCPDeliver.dll
On my machine i7-2600K windows 7 64-bit this script, 4 lines of code, runs.


LoadPlugin("C:\SmoothD2-a2\SmoothD2.dll")
AviSource("H:SmoothD2speedTest.avi").ConvertToYV12()
SmoothD2(quant=31, num_shift=4, Matrix=15, Qtype=1, ZW=0, ZWce=1, ZWlmDark=255, ZWlmBright=255, ncpu=1)
return(last)

Its not dependent on some avisynth filter dll that I am loading.

I uninstalled avisynth v.2.6.0 ST, 32-bit
I Download and installed Avisynth_258.exe (4.2 MB)
The script still runs
Its not an avisynth version problem.

Dependency walker says that SmoothD2.dll needs MSVCR80.DLL file version 8.0.50727.6195
Aparently MSVCR80.DLL is required for any? dll built with Microsoft Visual C++ 2005 Version 8.0.50727.867
Note the version numbers match in the first 3 fields.

OK so it works on my machine and does not care which which avisynth is used.
It works for some people but not others...
Maybe MSVCR80.DLL needs to be in a special place.

When I do a search for MSVCR80.DLL on my C drive the search finds over 50 of them!
Oh thats right everyone that puts out an application, photoshop for example, needs to distribute a copy
of any dll's that it uses. So most people probably already have it on their system.
When I tracked one down and did a properties on it the description was Microsoft C Runtime Library.
Good, 1 guess confirmed.
When I sorted the list by size there were 5 different sizes. oops, I know I still don't get it.
When I looked at examples of the different sizes there were 4 different file versions.
The same file version came in 778KB and 612KB.
The other sizes were 803KB, 783KB, and 617KB
Now I am starting to get a bad feeling

I search further and find
For your convenience, we have provided the following folders for use when redistributing VC++ runtime files.
Subject to the license terms for the software, you may redistribute the folder (unmodified) in the application local folder
as a sub-folder with no change to the folder name. You may also redistribute all the files (*.dll and *.manifest)
within a folder, listed below the folder for your convenience, as an entire set.

\VC\redist\x86\Microsoft.VC80.CRT\
msvcm80.dll
msvcp80.dll
msvcr80.dll
Microsoft.VC80.CRT.manifest

Now the bad feeling really kicks in since I realize that the different versions of MSVCR80.DLL
are probably not compatible with each other.
OK I will have to distribute the dlls. No big deal. Ill have to figure out where they should
get put so they will be found.
And that won't work either!!!
It can't work because if there are 2 filters that have been built using 2 different versions of
MSVCR80.DLL one of them will a version that was not the version the filter was built with.
so if the versions are different and a called function is incompatible then the filter dies.

At this point I am assuming I have my build system set up wrong and probably need to get the MSVCR80.DLL
code linked into the SmoothD2.dll. First I need to go back and study the AviSynth build a filter documentation, again.

If you know what I have done wrong please let me know.

Thanks Jim

[jconklin]

There is a new version of SmoothD2 at https://sites.google.com/site/jconklin754smoothd2/home/download that should fix the filter crash bug. You should now be able to click the highlighted link and have the file downloaded. I will be updating the documentation over the next few days. The biggest change is support for multithreading using the ncpu argument which takes values 1-4.

[Bloax]

I can confirm that it works now.

[jconklin]

Bloax

Thank you for confirming as quickly as you did that I didn't mess it up again. By the way I did have my build system set up wrong. After I knew what to look for I could see how I mislead myself when I was converting the aviSynth build a filter documentation to the microsoft linker hints in their Visual dev environment. Thanks again, from me and everyone who will now not have this problem. I will definatly sleep better tonight.

Jim