deblock_qed quant1,quant2 ?

[halsboss]

Hi, searched with not much luck for a brief explanation on meanings of quant1 and quant2 and their intended relationship (eg quant1 usually < quant2+2 or something)... some people seem to be using various values but I'm hoping for some basic info on what they are so as to at least test with some informed guesswork.

So far have supposed that quant1 may be a form of strength however unsure what to do with quant2 if, say, we up quant1 to 40...

http://forum.doom9.org/showthread.php?p=879259&highlight=quant1+quant2#post879259 suggests how to test
http://forum.doom9.org/showthread.php?p=872597#post872597 mentions usage

Any comments on the other parameters would be valued, too. Anyone know ?

[Didée]

Deblock_qed is fully based on Deblock() (implementation of H.264 deblocking, contained in DGDecode / older MVTools / Fizick's stand-alone plugin.)
Deblock() has the parameters "quant", "aOff" and "bOff". How these work has been discussed in several threads, do a search.
(Very roughly, "quant" can be seen as "strength", "bOff" is "sensitivity to detect blocking", and "aOff" is halfway "sensitivity", halfway a strength modifier.)

In deblock_qed(), the meaning of these parameters is exactly the same. The difference is that deblock_qed internally uses two different instances of deblock(): one for block borders, and one for block interiours. That's why the function has those "xxx1" and "xxx2" parameters.

To get a better idea (eventually;)) of the methodology used by deblock_qed, start with this post (http://forum.doom9.org/showthread.php?p=913394#post913394), and follow the link that's given there.

[halsboss]

Thanks Didee, the post http://forum.doom9.org/showthread.php?p=913394#post913394 in turn pointed to a rather interesting technical discussion at http://videoprocessing.11.forumer.com/viewtopic.php?p=406#406

Then, 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

I hope I've sourced the proper latest DEBLOCK_QED MT2 version (wiki currently down ?) and added the comments Didee made plus that from foxyshadis in http://forum.doom9.org/showthread.php?p=933643#post933643

function Deblock_QED_MT2 ( clip clp, int "quant1", int "quant2",
\ int "aOff1", int "bOff1", int "aOff2", int "bOff2", int "uv" )
{
# MT2 version ( hopefully the right one from http://avisynth.org/mediawiki/Wiki/Deblock_QED )
# 26/01/2007 comments added per http://forum.doom9.org/showthread.php?p=944459#post944459
# 26/01/2007 extra checks added per http://forum.doom9.org/showthread.php?p=933643#post933643

quant1 = default( quant1, 20 )
quant2 = default( quant2, 40 )
aOff1 = default( aOff1, quant1/2 ) # I've no clue if these are clever values or not!
bOff1 = default( bOff1, quant1/4 ) # So:
aOff2 = default( aOff2, quant1/4 ) # Also try all these 4 values @ 0 (zero),
bOff2 = default( bOff2, quant1/8 ) # and quant1=30, quant2=40~45 instead.
uv = default( uv, 3 ) # u=3 -> use proposed method for chroma deblocking
# u=2 -> no chroma deblocking at all (fastest method)
# u=1|-1 -> directly use chroma debl. from the normal|strong deblock()
#--- 26/01/2007 start per http://forum.doom9.org/showthread.php?p=944459#post944459
# Deblock_QED is fully based on Deblock() (implementation of H.264 deblocking,
# contained in DGDecode / older MVTools / Fizick's stand-alone plugin)
# Deblock() has the parameters "quant", "aOff" and "bOff".
# How these work has been discussed in several threads, do a search.
# In Deblock_QED(), the meaning of these parameters is exactly the same.
# The difference is that Deblock_QED 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
#--- 26/01/2007 end

#--- 26/01/2007 start per http://forum.doom9.org/showthread.php?p=933643#post933643
Assert(clp.isplanar(),"Deblock_QED_MT2: Requires planar YUV (YV12, YV16, YV24, Y8).")
Assert(clp.width() % 8 == 0 && clp.height() % 8 == 0,"Deblock_QED_MT2: Requires mod8 video.")
#--- 26/01/2007 end

ox = clp.width()
oy = clp.height()

# With avisynth scripting, there is no information available about the position of the currently
# processed pixel ... there simply is no such thing like an "actual" processed pixel.
# So first I've to build up a grid covering the transitions between all 8x8 blocks,
# and make some LUTmania with it later. Yes, this is cumbersome.

block = blankclip(clp,width=6*4,height=6*4,color=$000000).addborders(4,4,4,4,color=$FFFFFF)
block = stackhorizontal( block,block,block,block)
block = stackvertical( block,block,block,block) .pointresize(32,32) .mt_binarize(upper=false)
block = stackhorizontal( block,block,block,block,block,block,block,block)
block = stackvertical( block,block,block,block,block,block)
block = stackhorizontal( block,block,block)
block = stackvertical( block,block,block)
block = stackhorizontal( block,block,block)
block = stackvertical( block,block)
#return clp.subtitle(string(block.width)+"x"+string(block.height))
block = block .crop(0,0,ox,oy)
block = (uv!=3) ? block
\ : YtoUV(block.crop(0,0,ox/2,oy/2),block.crop(0,0,ox/2,oy/2),block)
block = block.trim(1,1) .loop(framecount(clp))

# 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 )
}

Comment or correction or redirection welcomed.

[HeadBangeR77]

I'm testing the above atm on some very blocky avisource, that has not much detail left. My previous results with both Deblock() (Fizick's plugin) or BlindPP-deblocking weren't satisfactory. Deblock worked much better than BlindPP, but also washed out the last details I would like to retain. Playing with different settings didn't give me the desired result. I'll report back, when I'm finished.

Btw. the readme for Deblock states:
aOffset : quant modifier to the blocking detector threshold. Setting it higher means than more edges will deblocked.

bOffset : another quant modifier, for block detecting and for deblocking's strength. There again, the higher, the stronger.

Here those two values are swaped. Which version is the correct one, then? Or are those two parameters implemented differently (in Deblock_QED)?

:confused:

EDIT: As for now, Deblock(30,-2,-3) or Deblock(28,-1,-2) seems to do a better job for my source than any configuration of the above script I've already tried. Guess I have to "tame" this script a bit more ;) ;) ;)

[Didée]

The description in the readme is correct, but it's sort of a
"Hey, this is too complex&difficult to explain to JoeAvg ... so let's put it this way. It's oversimplified, sure, but at least it's not wrong. ;-)"

My description was similar, except for that my understanding of the inner details is not half as good as of those who did code that stuff. ;)

I remember there has been a thread where x264's deblocking parameters were explained & discussed quite in-depth ... (iirc) Manao & akupenguin & bob0r (/iirc) discussed & gave lots of insights about what/how/why the parameters are doing exactly ... but I can't find the darn thread anymore!

Anyone remembering that thread, too, and have a link to it?

(I found this one (http://forum.doom9.org/showthread.php?t=109747), but that's not the one I've in mind.)

[Didée]

As for now, Deblock(30,-2,-3) or Deblock(28,-1,-2) seems to do a better job for my source than any configuration of the above script I've already tried.
Oh that's quite possible, sure. You are
testing the above atm on some very blocky avisource,
and my experiment turned out to rather aim at removing blocking from "not so bad" sources, while keeping maximum detail for those.

With increasing "severe-ness" of blocking artefacts, deblock_qed becomes more and more counter-indicated: Such stuff *needs* block-interior smoothing, and deblock_qed is mostly about *avoiding* block-interior smoothing. ;)

[halsboss]

Hi, thanks for the pointers.
Thought I'd have a go on a blocky noisy source per http://forum.doom9.org/showthread.php?p=943895#post943895 (xvid PAL 4x3 768x576 25fps)
Source avi 50 frames 240kb - http://rapidshare.com/files/13598192/source07-50frames.avi.html
Result avi q2 xvid including comparisons 7.4Mb - http://rapidshare.com/files/13598193/DeblockResults-xvid.avi.html

Original frame 17
http://www.users.on.net/~walshdcw/deblock/deblock_0017-frame17-jpgQ90.jpg
Original frame 35
http://www.users.on.net/~walshdcw/deblock/deblock_0035-frame35-jpgQ90.jpg
Selected area frame 17 with various combinations of settings -
http://www.users.on.net/~walshdcw/deblock/deblock_0067-frame17-jpgQ90.jpg
Selected area frame 17 with various combinations of settings -
http://www.users.on.net/~walshdcw/deblock/deblock_0085-frame35-jpgQ90.jpg

Not sure if I'm altogether comfortable with the results... as Didee said QED's for OK sources... so per HeadBangeR77's suggestion
previous results with both Deblock() (Fizick's plugin) ... EDIT: As for now, Deblock(30,-2,-3) or Deblock(28,-1,-2) seems to do a better job for my source than any configuration of the above script I've already tried. should I have a go with Fizick's Deblock plugin, or do you have any settings suggestions for Deblock_QED_MT2 ? Or are my eyes too old and one of these deblocks is OK. (Just a thought, have I mucked up the Deblock_QED_MT2 version above ?)

Thanks

Rapidshare links in case the images go away :-
Your Download-Link #1: http://rapidshare.com/files/13598192/source07-50frames.avi.html
Your Download-Link #2: http://rapidshare.com/files/13598193/DeblockResults-xvid.avi.html
Your Download-Link #3: http://rapidshare.com/files/13598194/deblock_0017-frame17-jpgQ90.jpg.html
Your Download-Link #4: http://rapidshare.com/files/13598195/deblock_0035-frame35-jpgQ90.jpg.html
Your Download-Link #5: http://rapidshare.com/files/13598196/deblock_0067-frame17-jpgQ90.jpg.html
Your Download-Link #6: http://rapidshare.com/files/13598197/deblock_0085-frame35-jpgQ90.jpg.html
Your Download-Link #7: http://rapidshare.com/files/13598198/source07-50frames-CQ2.avs.html
Your Download-Link #8: http://rapidshare.com/files/13599820/source07-50frames-CQ2.avs.html
brute-force avs acknowledged, just wanted a result

Your Delete-Link #1: http://rapidshare.com/files/13598192/source07-50frames.avi?killcode=908153089
Your Delete-Link #2: http://rapidshare.com/files/13598193/DeblockResults-xvid.avi?killcode=3488374581
Your Delete-Link #3: http://rapidshare.com/files/13598194/deblock_0017-frame17-jpgQ90.jpg?killcode=2525053817
Your Delete-Link #4: http://rapidshare.com/files/13598195/deblock_0035-frame35-jpgQ90.jpg?killcode=12760647
Your Delete-Link #5: http://rapidshare.com/files/13598196/deblock_0067-frame17-jpgQ90.jpg?killcode=3592071387
Your Delete-Link #6: http://rapidshare.com/files/13598197/deblock_0085-frame35-jpgQ90.jpg?killcode=1443429062
Your Delete-Link #7: http://rapidshare.com/files/13598198/source07-50frames-CQ2.avs?killcode=955946316
Your Delete-Link #8: http://rapidshare.com/files/13599820/source07-50frames-CQ2.avs?killcode=3245121920

[halsboss]

OK, something good was happening ... results with COMPARE and SUBTRACT.Levels(127,1,129,0,255) :-

http://www.users.on.net/~walshdcw/deblock/deblock_0117-compare-frame17-jpgQ60.jpg
http://www.users.on.net/~walshdcw/deblock/deblock_0117-subtract-frame17-jpgQ60.jpg

with just these shown in this 18mb! xvid-Q3 of the same 50 frame clip :- http://rapidshare.com/files/13632070/DeblockResults-Compare-Subtract-xvidQ3.avi.html

Rapidshare links in case the images go away :-
Your Download-Link #1: http://rapidshare.com/files/13632066/deblock_0117-compare-frame17-jpgQ60.jpg.html
Your Download-Link #2: http://rapidshare.com/files/13632067/deblock_0117-compare-frame35-jpgQ60.jpg.html
Your Download-Link #3: http://rapidshare.com/files/13632068/deblock_0117-subtract-frame17-jpgQ60.jpg.html
Your Download-Link #4: http://rapidshare.com/files/13632069/deblock_0117-subtract-frame35-jpgQ60.jpg.html
Your Download-Link #5: http://rapidshare.com/files/13632070/DeblockResults-Compare-Subtract-xvidQ3.avi.html
Your Download-Link #6: http://rapidshare.com/files/13632071/source07-50frames-CQ2.avs.html

Your Delete-Link #1: http://rapidshare.com/files/13632066/deblock_0117-compare-frame17-jpgQ60.jpg?killcode=2174292909
Your Delete-Link #2: http://rapidshare.com/files/13632067/deblock_0117-compare-frame35-jpgQ60.jpg?killcode=2127580006
Your Delete-Link #3: http://rapidshare.com/files/13632068/deblock_0117-subtract-frame17-jpgQ60.jpg?killcode=362622077
Your Delete-Link #4: http://rapidshare.com/files/13632069/deblock_0117-subtract-frame35-jpgQ60.jpg?killcode=2649980916
Your Delete-Link #5: http://rapidshare.com/files/13632070/DeblockResults-Compare-Subtract-xvidQ3.avi?killcode=2549615504
Your Delete-Link #6: http://rapidshare.com/files/13632071/source07-50frames-CQ2.avs?killcode=3013382420

[halsboss]

EDIT: As for now, Deblock(30,-2,-3) or Deblock(28,-1,-2) seems to do a better job for my source than any configuration of the above script I've already tried. Guess I have to "tame" this script a bit more ;) ;) ;)
Sorry, I'm a bit :confused: confused on the -ve settings as Fizick's Deblock doco says stuff like

# Fizick's Deblock (clip, int "quant", int "aOffset", int "bOffset")
# quant : def=25 the higher the quant, the stronger the deblocking. It can range from 0 to 60.
# aOffset : def=0 quant modifier to the blocking detector threshold.
# Setting it higher means than more edges will deblocked.
# bOffset : def=0 another quant modifier, for block detecting and for deblocking's strength.
# There again, the higher, the stronger.
# If quant + aOffset is inferior to 16, the filter does nothing at all.
# The same goes for quant + bOffset.

[HeadBangeR77]

(...)
and my experiment turned out to rather aim at removing blocking from "not so bad" sources, while keeping maximum detail for those.
I think your script might turn out to be very useful for some MPEG-2 sources I've got, that suffer from small blocks here and there, from time to time :)

However, I've been experimenting with it for the 2nd day, and I've got an impression it changes colors, or I would rather say, brightness very slightly. Nothing to panic about, invisible while watching, yet visible while analyzing and comparing frame by frame. I dare to say it could connected with the alpha version of MaskTools, it's alpha after all. ;)

Do you think this small script (http://forum.doom9.org/showpost.php?p=913497&postcount=9), designed for MSU filter, might be useful? Just in case...

With increasing "severe-ness" of blocking artefacts, deblock_qed becomes more and more counter-indicated: Such stuff *needs* block-interior smoothing, and deblock_qed is mostly about *avoiding* block-interior smoothing. ;)
Nethertheless, playing with various settings, including uv, I've managed to achieve similar effect to Deblock. I don't know yet what to choose, still comparing ... The source is not only blocky (middle-fast motion), but also tends to change throughout its duration, however applying zones would be too much work. It also contains halos and mosquito noise, so many of your scripts are at work. ;) Thanks for your comments.

cheers,
HDBR77

[HeadBangeR77]

should I have a go with Fizick's Deblock plugin, or do you have any settings suggestions for Deblock_QED_MT2 ? Or are my eyes too old and one of these deblocks is OK. (Just a thought, have I mucked up the Deblock_QED_MT2 version above ?)

Thanks
You're welcome :) To tell you the truth, I'm a noob to deblocking, but I've been experimenting much over the last few days. The difference is: your source is simply old (like that old SF stuff ;)) with some blocks, mine is heavily blocked in some scenes, and that's the main problem. If I set any filter too strongly, then it destroys details in low-motion scenes, and when I set it moderately, then it doesn't destroy nasty blocks in the worst parts, so I'm kinda helpless atm :D

A good invention would be some kind of adaptive filter, that would analyze every frame, applying different deblocking strenght and threshold on different frames, like MSU Smart Deblocking (here (http://forum.doom9.org/showthread.php?t=103873)) claims to be. Unfortunatelly the results aren't impressive, though I'm still trying (beeing a bit fed up with this already :p).

As to my settings - I would like to preserve as much details as I can (kind of fight against windmills ;)), so I choose two different approches to the matter:

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.

Hope we could swap more experience. I need a break atm, tired of all this ;)

cheers,
HDBR77

[foxyshadis]

That was the goal behind SmoothD and SmoothDeblock, actually. They attempted to reconstruct the original quant structure in order to decide how strong a deblocking was necessary. Both of them work - SmoothDeblock especially - they're just enormously slow and complex.

[HeadBangeR77]

That was the goal behind SmoothD and SmoothDeblock, actually. They attempted to reconstruct the original quant structure in order to decide how strong a deblocking was necessary. Both of them work - SmoothDeblock especially - they're just enormously slow and complex.
I thought I had seen that thread (on SmoothDeblock) somewhere, and it turned out I'm even subscribed. Good you've reminded us, that sth like that exists. :)

Total overkill, far beyond not only my skills but even undestanding :D And I appreciate that guy's work very much. Hair structure by close-ups is one of the worst things I could imagine. Gonna try that library this nite :devil:

[halsboss]

OK - links to results with Fizick's Deblock ... not a huge change to deblock_qed_mt2, in my eyes anyway.
The 9Mb xvid AVI result http://rapidshare.com/files/13727793/fizick-deblock-20frames.avi.html
Frame 17 SUBTRACT 180kb http://rapidshare.com/files/13727795/fizick_deblock_SUBTRACT-frame17.jpg.html
Per your suggestions, will have a look for and test with SmoothD and SmoothDeblock and MSU Smart Deblocking :thanks: ...
MSU Deblocking Filter v2.2 http://compression.ru/video/deblocking/index_en.html
MSU Smart Deblocking Filter 0.5 http://compression.ru/video/deblocking/smartdeblocking_en.html with colour correction at http://forum.doom9.org/showthread.php?p=913497#post913497
SmoothD 0.0.9pre2 November 8th, 2004 http://www.funknmary.de/bergdichter/projekte/video/SmoothD/
SmoothDeblock thread at http://forum.doom9.org/showthread.php?t=111526

Cheerio
Rapidshare links :-
Your Download-Link #1: http://rapidshare.com/files/13727792/source07-20frames.avi.html
Your Download-Link #2: http://rapidshare.com/files/13727793/fizick-deblock-20frames.avi.html
Your Download-Link #3: http://rapidshare.com/files/13727794/source07-20frames-FizickDeblock.avs.html
Your Download-Link #4: http://rapidshare.com/files/13727795/fizick_deblock_SUBTRACT-frame17.jpg.html

Your Delete-Link #1: http://rapidshare.com/files/13727792/source07-20frames.avi?killcode=583033730
Your Delete-Link #2: http://rapidshare.com/files/13727793/fizick-deblock-20frames.avi?killcode=2872344047
Your Delete-Link #3: http://rapidshare.com/files/13727794/source07-20frames-FizickDeblock.avs?killcode=1886757446
Your Delete-Link #4: http://rapidshare.com/files/13727795/fizick_deblock_SUBTRACT-frame17.jpg?killcode=291447377

[halsboss]

Ah, just noticed " All existing deblocking algorithms implementations" by redfordxxx http://forum.doom9.org/showthread.php?t=119082

[HeadBangeR77]

Ah, just noticed " All existing deblocking algorithms implementations" by redfordxxx http://forum.doom9.org/showthread.php?t=119082
Thanks for the link. ;) Have already came across that thread, but I forgot to subscribe.

Now I've got 2 different configurations for Deblock(), and 3 for DeblockQED, between which I have to choose soon. Atm I'm experimenting with motion-compensated Deblock, like e.g.


# DEBLOCKING
vectors = video.MVAnalyse(isb = false, truemotion=true, lambda = 800, overlap=2, dct=3)
compensation = video.MVCompensate(vectors, mode = 0)
compensation.Deblock(28,-1,-2)

It's slow (a little tweaked comparing to the default/recommended values, see lambda, overlap, dct), but still faster than MSU "Smart" Deblocking, about which I'm gonna speak further in my post. The only reason I haven't decided yet, though Deblock seems to be better for my source, is that Didee's script, while remaining very conservative, offers some tweaking that I wanted to test. :)

I will post my experiences with MSU's filter in another post (:devil: ) - moderate ranting expected.

cheers,
HDBR77

[HeadBangeR77]

One shouldn't play with sth he doesn't undestand at all - motion compensated deblocking ended (after a sample encode with new, heavy 8x8 blocks) :eek:

As to MSU: it really seems to be sort of adaptive, and it really preserves details, but it doesn't deal with large blocks, as it should do. The overall effect isn't better than that with Deblock() or DeblockQED(), if not even worse, and the filter is two times slower! What's more, it doesn't have any strength/threshold/sensitivity/hell-knows-what-more parameters to play with, so we can only enalbe or disable certain processing functions. I'm rather disappointed, both with the endeffect and speed. I might be wrong, but it doesn't handle edges too well, even destroying some of them (I didn't activate the edges restoring function). Point. I will say no more.

[HeadBangeR77]

I would like to revive this thread a bit. ;)

After dealing with some nasty, blocky source, for which Deblock_QED was not meant, as Didee stated, I was working on another source, which was my back-up copy of "The Curse of the Black Pearl", after the original had been broken in two pieces (oh, my beloved family! :D). DVD-Shrink did an overall good job, but in some high-motion scenes the bitrate turned out to be too low for MPEG-2, hence some nasty blocks poped out here and there.

My goal this time was to eliminate the smaller ones and to mask the larger ones as good as it's possible, without destroying any important details. And Deblock_QED turned out to be very suitable for this task, since I can't see any details removed, while the blocks has been either eliminated (blurred) or masked pretty well. :)

0 - The source VOB, very blocky on high motion (I've deribately chosen the worst frames I could find)

1 - Fft3dgpu, BlindDeHalo3 (just PPmode=-3), LimitedSharpenFaster and Soothe: image is sharper, yet the blocks has been sharpened too.

2- As above + gentle Deblock_QED applied at the beginning, before corpping: quant1=18,quant2=24,aOff1=2,bOff1=2,aOff2=4,bOff2=4.


0) http://www.hidebehind.com/thumbs3/C2673453.png (http://www.hidebehind.com/C2673453)

1) http://www.hidebehind.com/thumbs3/1F8A33E.png (http://www.hidebehind.com/1F8A33E)

2) http://www.hidebehind.com/thumbs3/A4B51E.png (http://www.hidebehind.com/A4B51E)


0) http://www.hidebehind.com/thumbs3/C6739C30.png (http://www.hidebehind.com/C6739C30)

1) http://www.hidebehind.com/thumbs3/BB4036D0.png (http://www.hidebehind.com/BB4036D0)

2) http://www.hidebehind.com/thumbs3/7D598C4.png (http://www.hidebehind.com/7D598C4)


0) http://www.hidebehind.com/thumbs3/8B8F74AA.png (http://www.hidebehind.com/8B8F74AA)

1) http://www.hidebehind.com/thumbs3/9B037DB8.png (http://www.hidebehind.com/9B037DB8)

2) http://www.hidebehind.com/thumbs3/BE7648EA.png (http://www.hidebehind.com/BE7648EA)

Please view at fullscreen resolution, otherweise it doesn't make sense. ;)

[HeadBangeR77]

...and some more screenshots...

0) http://www.hidebehind.com/thumbs3/38481C82.png (http://www.hidebehind.com/38481C82)

1) http://www.hidebehind.com/thumbs3/D297B91D.png (http://www.hidebehind.com/D297B91D)

2) http://www.hidebehind.com/thumbs3/3F7434CC.png (http://www.hidebehind.com/3F7434CC)


0) http://www.hidebehind.com/thumbs3/73291F2A.png (http://www.hidebehind.com/73291F2A)

1) http://www.hidebehind.com/thumbs3/BC80B1F0.png (http://www.hidebehind.com/BC80B1F0)

2) http://www.hidebehind.com/thumbs3/F6C383CC.png (http://www.hidebehind.com/F6C383CC)

cheers,
HDBR77