Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
26th January 2007, 02:25 | #1 | Link |
likes to tinker
Join Date: Jan 2004
Location: girt by sea
Posts: 635
|
deblock_qed quant1,quant2 ?
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.ph...nt2#post879259 suggests how to test http://forum.doom9.org/showthread.ph...597#post872597 mentions usage Any comments on the other parameters would be valued, too. Anyone know ? Last edited by halsboss; 26th January 2007 at 02:28. Reason: spelling |
26th January 2007, 11:35 | #2 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
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, and follow the link that's given there.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
26th January 2007, 14:23 | #3 | Link |
likes to tinker
Join Date: Jan 2004
Location: girt by sea
Posts: 635
|
Thanks Didee, the post http://forum.doom9.org/showthread.ph...394#post913394 in turn pointed to a rather interesting technical discussion at http://videoprocessing.11.forumer.co....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.ph...643#post933643 Code:
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 ) } |
26th January 2007, 20:03 | #4 | Link |
Registered User
Join Date: Dec 2006
Location: Heidelberg (DE), Kraków (PL)
Posts: 519
|
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)? 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
__________________
"Only two things are infinite: the universe and human stupidity, and I'm not sure about the former."
Last edited by HeadBangeR77; 26th January 2007 at 22:39. |
26th January 2007, 23:08 | #5 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
The description in the readme is correct, but it's sort of a
Quote:
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, but that's not the one I've in mind.)
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
|
26th January 2007, 23:25 | #6 | Link | ||
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Quote:
Quote:
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.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
||
27th January 2007, 10:40 | #7 | Link | |
likes to tinker
Join Date: Jan 2004
Location: girt by sea
Posts: 635
|
Hi, thanks for the pointers.
Thought I'd have a go on a blocky noisy source per http://forum.doom9.org/showthread.ph...895#post943895 (xvid PAL 4x3 768x576 25fps) Source avi 50 frames 240kb - http://rapidshare.com/files/13598192...rames.avi.html Result avi q2 xvid including comparisons 7.4Mb - http://rapidshare.com/files/13598193...-xvid.avi.html Original frame 17 Original frame 35 Selected area frame 17 with various combinations of settings - Selected area frame 17 with various combinations of settings - Not sure if I'm altogether comfortable with the results... as Didee said QED's for OK sources... so per HeadBangeR77's suggestion Quote:
Thanks Rapidshare links in case the images go away :- Your Download-Link #1: http://rapidshare.com/files/13598192...rames.avi.html Your Download-Link #2: http://rapidshare.com/files/13598193...-xvid.avi.html Your Download-Link #3: http://rapidshare.com/files/13598194...pgQ90.jpg.html Your Download-Link #4: http://rapidshare.com/files/13598195...pgQ90.jpg.html Your Download-Link #5: http://rapidshare.com/files/13598196...pgQ90.jpg.html Your Download-Link #6: http://rapidshare.com/files/13598197...pgQ90.jpg.html Your Download-Link #7: http://rapidshare.com/files/13598198...s-CQ2.avs.html Your Download-Link #8: http://rapidshare.com/files/13599820...s-CQ2.avs.html brute-force avs acknowledged, just wanted a result Your Delete-Link #1: http://rapidshare.com/files/13598192...code=908153089 Your Delete-Link #2: http://rapidshare.com/files/13598193...ode=3488374581 Your Delete-Link #3: http://rapidshare.com/files/13598194...ode=2525053817 Your Delete-Link #4: http://rapidshare.com/files/13598195...lcode=12760647 Your Delete-Link #5: http://rapidshare.com/files/13598196...ode=3592071387 Your Delete-Link #6: http://rapidshare.com/files/13598197...ode=1443429062 Your Delete-Link #7: http://rapidshare.com/files/13598198...code=955946316 Your Delete-Link #8: http://rapidshare.com/files/13599820...ode=3245121920 Last edited by halsboss; 27th January 2007 at 10:54. |
|
27th January 2007, 15:25 | #9 | Link | |
likes to tinker
Join Date: Jan 2004
Location: girt by sea
Posts: 635
|
Quote:
Code:
# 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. |
|
27th January 2007, 20:19 | #10 | Link | ||
Registered User
Join Date: Dec 2006
Location: Heidelberg (DE), Kraków (PL)
Posts: 519
|
Quote:
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, designed for MSU filter, might be useful? Just in case... Quote:
cheers, HDBR77
__________________
"Only two things are infinite: the universe and human stupidity, and I'm not sure about the former."
|
||
27th January 2007, 21:04 | #11 | Link | |
Registered User
Join Date: Dec 2006
Location: Heidelberg (DE), Kraków (PL)
Posts: 519
|
Quote:
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) claims to be. Unfortunatelly the results aren't impressive, though I'm still trying (beeing a bit fed up with this already ). 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
__________________
"Only two things are infinite: the universe and human stupidity, and I'm not sure about the former."
Last edited by HeadBangeR77; 28th January 2007 at 05:44. |
|
27th January 2007, 22:01 | #12 | Link |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,556
|
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.
|
27th January 2007, 23:47 | #13 | Link | |
Registered User
Join Date: Dec 2006
Location: Heidelberg (DE), Kraków (PL)
Posts: 519
|
Quote:
Total overkill, far beyond not only my skills but even undestanding 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
__________________
"Only two things are infinite: the universe and human stupidity, and I'm not sure about the former."
|
|
28th January 2007, 08:00 | #15 | Link |
likes to tinker
Join Date: Jan 2004
Location: girt by sea
Posts: 635
|
Ah, just noticed " All existing deblocking algorithms implementations" by redfordxxx http://forum.doom9.org/showthread.php?t=119082
|
28th January 2007, 23:52 | #16 | Link | |
Registered User
Join Date: Dec 2006
Location: Heidelberg (DE), Kraków (PL)
Posts: 519
|
Quote:
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. Code:
# 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) I will post my experiences with MSU's filter in another post ( ) - moderate ranting expected. cheers, HDBR77
__________________
"Only two things are infinite: the universe and human stupidity, and I'm not sure about the former."
|
|
29th January 2007, 00:55 | #17 | Link |
Registered User
Join Date: Dec 2006
Location: Heidelberg (DE), Kraków (PL)
Posts: 519
|
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)
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.
__________________
"Only two things are infinite: the universe and human stupidity, and I'm not sure about the former."
|
5th February 2007, 16:52 | #18 | Link |
Registered User
Join Date: Dec 2006
Location: Heidelberg (DE), Kraków (PL)
Posts: 519
|
Deblock_QED works like charm! :)
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! ). 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) 1) 2) 0) 1) 2) 0) 1) 2) Please view at fullscreen resolution, otherweise it doesn't make sense.
__________________
"Only two things are infinite: the universe and human stupidity, and I'm not sure about the former."
Last edited by HeadBangeR77; 5th February 2007 at 17:27. |
5th February 2007, 17:21 | #19 | Link |
Registered User
Join Date: Dec 2006
Location: Heidelberg (DE), Kraków (PL)
Posts: 519
|
Pt. II
__________________
"Only two things are infinite: the universe and human stupidity, and I'm not sure about the former."
Last edited by HeadBangeR77; 5th February 2007 at 17:33. |
Thread Tools | Search this Thread |
Display Modes | |
|
|