Deblocking question.

[rkalwaitis]

I was looking at a script by Caroliano; SMDegrain. It is a rather simple clip and straight forward. I added contrasharpening by Didee and was attempting to incorporate an occlusion mask as I have problems with blocking, with this script. I tried to use the example from MVtools documentation as shown below, but I was not smart enough to use it. So I opted for an easier way for me at least by calling Deblock_QED. Still trying to figure out the best settings but that is okay. I would really like to incorporate the "blocky blur problem" way below. But my real question is would this method be worth it? I have never seen it used. Everyone usually uses deblock_qed. But I was thinking that the version using compensation from mvtools may be the way to go since the mdegrain is from the same package of goodies. So based on the vast knowledge base out there, who has tried it and was it worth it?

From Mvtools documentation. To blur problem (blocky) areas of compensated frame with occlusion mask: I would love to try this way for deblocking.

AVISource("c:\test.avi") # or MPEG2Source, DirectShowSource, some previous filter, etc
super = MSuper()
vectors = MAnalyse(super, isb = false)
compensation = MCompensate(super,vectors) # or use MFlow function here
# prepare blurred frame with some strong blur or deblock function:
blurred = compensation.DeBlock(quant=51) # Use DeBlock function here
badmask = MMask(vectors, kind = 2, ml=50)
overlay(compensation,blurred,mask=badmask) # or use faster MaskedMerge function of MaskTools


Here is the script

###########################################################################################
### ###
### Simple MDegrain - SMDegrain() ###
### ###
### By Caroliano ###
### ###
### Special Thanks: Sagekilla, Didée and MVtools people ###
### ###
### v0.2 - 24 Jan 2010 ###
### ###
################################################################################################
###
### +-----------+
### | CHANGELOG |
### +-----------+
###
### v0.2 : - Added this introductory section
### - Added more parameters
###
### v0.1 : - Basic working version
### - Not released
###
###
### +--------------+
### | DEPENDENCIES |
### +--------------+
###
### -> MVtools2 (v2.5.8.1 or higher)
### -> MVtools depends on anything?? If yes, those things.
###
###
###
### +------------------+
### | BASIC PARAMETERS |
### +------------------+
###
###
### tr [int: 1, 2, 3]
### --------------
### Temporal radius. Select between MDegrain 1, 2 or 3. Higher is better, but also much slower.
### Default is 2.
###
###
### thSAD [int]
### --------------
### Strenght of denoising. Low values can result in staggered denoising,
### large values can result in ghosting and artefactes. Default is 400.
###
###
### plane [int: 1, 2, 3, 4]
### --------------
### Select the color planes you wish to process:
### 0 - luma only, 1 - chroma U, 2 - chroma V, 3 - both chromas, 4 - all.
### Default is 4 - all.
###
###
###
### +---------------------+
### | ADVANCED PARAMETERS |
### +---------------------+
###
###
### limit [int: 1 - 255]
### --------------
### Maximal change of pixel luma (post-process like DeGrainMedian plugin
### and LimitChange function of SSETools plugin, to prevent some artefactes).
### Default is 255 (no limit).
###
###
### limitc [int: 1 - 255]
### --------------
### Maximal change of pixel chroma. Default value = limit.
###
###
### pel [int: 1, 2, 4]
### --------------
### Accuracy of the motion estimation. 1 means a precision to the pixel.
### 2 means a precision to half a pixel. 4 means a precision to quarter a pixel, produced by
### spatial interpolation (more accurate but slower and not always better due to big level scale step).
### Default is 2.
###
###
### sharp [int: 0, 1, 2]
### --------------
### Subpixel interpolation method for pel=2,4.
### Use 0 for soft interpolation (bilinear), 1 for bicubic interpolation (4 tap Catmull-Rom),
### 2 for sharper Wiener interpolation (6 tap, similar to Lanczos. Default is 2.
###
###
### blksize [int: 4, 8, 16]
### --------------
### Size of a block (horizontal). Default is 8.
### Larger blocks are less sensitive to noise, are faster, but also less accurate.
###
###
### overlap [int]
### --------------
### Must be *even* and *less* than block size. Try use overlap value from blksize/4 to blksize/2.
### The greater overlap, the more blocks number, and the lesser the processing speed.
### Default is 2
###
###
### Search [int= 0, 1, 2, 3, 4, 5]
### --------------
### 0= 'OneTimeSearch', 1 = 'NStepSearch', 2= Logarithmic, 3= Exhaustive, 4= Hexagon, 5= Uneven Multi Hexagon
### Default is 4. See details at MVtools documentation.
### http://avisynth.org.ru/mvtools/mvtools2.html
###
###
###
###
### +-------------+
### | FINAL NOTES |
### +-------------+
###
### If there is an important parameter not implemented, please ask.
### Or better yet, implement it yourself and post in the Doom9 thread.
###
### Many paremeters will likely never be implemented,
### and you are better off using the original MVtools way.
###
################################################################################################



function SMDegrain ( clip input, int "tr", int "thSAD", int "plane", int "limit", int "limitc", int "frames", int "strength", \
int "pel", int "sharp", int "blksize", int "overlap", int "search", \
bool "contrasharp", bool "unblock")

{

clip = input
tr = default( tr, 2 )
thSAD = default( thSAD, 400 )
plane = default( plane, 4 )
limit = default( limit, 255 )
limitc = default( limitc,limit)

pel = default( pel, 2 )
sharp = default( sharp, 2 )

blksize = default( blksize, 8 )
overlap = default( overlap, 2 )
search = default( search, 4 )
contrasharp = default(contrasharp, false)
unblock = default(unblock, false)
#quant1 = default( quant1 , 0 ) # quant 1 for deblock_qed
#quant2 = default( quant2 , 45 ) # quant 2 for deblock_qed
#uv = default( uv , 1 ) # uv for deblock_qed

FUNCTION ContraSharpening(denoised, clip)
{

# contra-sharpening: sharpen the denoised clip, but don't add more to any pixel than what was removed previously.
# script function from Didee from the VERY GRAINY thread
s = denoised.minblur(1,1) # Damp down remaining spots of the denoised clip.
allD = mt_makediff(clip,denoised) # The difference achieved by the denoising.
ssD = mt_makediff(s,s.removegrain(11,-1)) # The difference of a simple kernel blur.
ssDD = ssD.repair(allD,1) # Limit the difference to the max of what the denoising removed locally.
ssDD = SSDD.mt_lutxy(ssD,"x 128 - abs y 128 - abs < x y ?") # abs(diff) after limiting may not be bigger than before.

denoised.mt_adddiff(ssDD,U=2,V=2) # Apply the limited difference. (Sharpening is just inverse blurring.)

RETURN (last)
}

# Motion vector search

super = input.MSuper(pel=pel, sharp=sharp)
bv3 = (tr > 2) ?
\ super.MAnalyse(isb = true, delta = 3, overlap=overlap, blksize=blksize, search=search) : BlankClip
bv2 = (tr > 1) ?
\ super.MAnalyse(isb = true, delta = 2, overlap=overlap, blksize=blksize, search=search) : BlankClip
bv1 = super.MAnalyse(isb = true, delta = 1, overlap=overlap, blksize=blksize, search=search)
fv1 = super.MAnalyse(isb = false, delta = 1, overlap=overlap, blksize=blksize, search=search)
fv2 = (tr > 1) ?
\ super.MAnalyse(isb = false, delta = 2, overlap=overlap, blksize=blksize, search=search) : BlankClip
fv3 = (tr > 2) ?
\ super.MAnalyse(isb = false, delta = 3, overlap=overlap, blksize=blksize, search=search) : BlankClip



# Finally, MDegrain

output= (tr == 3) ? input.MDegrain3(super, bv1, fv1, bv2, fv2, bv3, fv3, thSAD=thSAD, limit=limit, limitc=limitc) :
\ (tr == 2) ? input.MDegrain2(super, bv1, fv1, bv2, fv2, thSAD=thSAD, limit=limit, limitc=limitc) :
\ input.MDegrain1(super, bv1, fv1, thSAD=thSAD, limit=limit, limitc=limitc)

output = contrasharp ? ContraSharpening(output,clip) : output
# Make the call to deblock_qed if asked
output = (unblock) ? input.deblock_qed(quant1=24,quant2=28,uv=3) : output

return (output)
}

As you may have noticed I could not get it to get my attempted incorporated QED_Deblock to work properly and ended up changing the values myself.

Thanks

[Didée]

I noticed that if the option to use the unblock was turned of I received about 3.0 fps. With the option on it was almost doubled. Can anyone tell me why this happens.
Because your script does not use MVTools when deblock=true.
output = (unblock) ? input.deblock_qed(quant1=24,quant2=28,uv=3) : output - See?


Also, your "blocking" issue after MDegrain probably is because of too little overlap. Default is blksize=8 / overlap=2. Try overlap=4. The preferred overlap value usually is blksize/2, and that's for a reason. Guess which? ;)

Moreover, that kind of soft-blocking (caused by too small overlap) most likely can not be rescued by a deblock filter. Since it is soft blocking, there are not any "sharp block borders", which is what deblocking filters usually are looking for.

[rkalwaitis]

Thanks Didee Ill try the change. Thanks for helping me fix my problem. Maybe that overlap soft blocking issue is the reason I could not get the deblocker no matter what settings I tried to use help me out. Did I at least remember how to do the contrasharpening correctly in the script.


K

[rkalwaitis]

Didee I have done as you said. However I still get those small blocks, especially in dark/near black areas. According to Fast Degrain by Sagekilla, if one experiences artifacts to reduce the limit parameter. So I did, with no real help, I lowered it so much my encoder refused to run the codec :( Oh well.

Maybe I don't truly understand blocking. My artifacts are blocked shaped and move as the video does.

I attempted to attach two pictures of the problem. The pictures do not do the problem justice (sounds horrible). There seems to be much more and more intense when I play the file.

Is this blocking? Recommendations for repair. Im trying the same script from above. CRF=20 which usually does well. If you zoom in you can see the issue better.

[Didée]

With pictures attached to the post, we need some luck that a moderator comes along during the next few days. What about using free image hosters like imageshack, imagebam. picupload, imagevenue, tinypic, or even mediafire? So we don't have to wait?

[rkalwaitis]

http://img27.imageshack.us/i/vlcsnap2010012620h54m27.png/

http://img402.imageshack.us/img402/2602/vlcsnap2010012620h54m24.png

http://img294.imageshack.us/img294/2889/vlcsnap2010012620h53m42.png

Hope this works

after looking at the source it appears that the problem is already there. Not caused by the script. It is just hidden by massive grain. Ill try another source and see if it happens again. Im sorry if I wasted your time.

[Didée]

Sure it works. But oh ... THAT kind of blocking you mean. All kinds of +/-1 value difference, caused by the limited precision of 8bit-colorspace, best seen in large flat areas of pitch-black frames, even more so when a denoiser has removed all fluctuations that have been masking the problem? Sure! The problem is known since back when we started out with digital video processing.:)
Try Gradfun2db/Mod to dither it flat, or use Deband option in ffdshow during playback.

[rkalwaitis]

Thanks Didee, I thought it would not be possible to fix since the problem appeared to be on the original source hidden behind the grain. So Ill give Lato's script a shot. Im sure it will work fine. Thanks again. So that isnt really called blocking is it? Its banding right?

[thetoof]

Yes it is

[rkalwaitis]

TheToof,

Yes it is--blocking?

[Didée]

thetoof answered your very last sentence. "It's banding right?" -- "Yes it is"

Also, with a reasonably-well calibrated display setup, I can't even see any banding in your screenshots - unless I crank up gamma noticeably. It seems a modern disease - having a too bright display setup, then complaining because you see things that you are not supposed to be able to see (at least not too obviously).

[rkalwaitis]

Perhaps I should check my monitor settings. But I only notice it in this source and in veryfew others.

I think before I try the gradmod remedy ill see if I too suffer from a modern disease.

Thanks

[rkalwaitis]

Here I put a couple of the frames in a small file so you can see if you see them. I did not filter them in any way.
The script was nothing at all.

# Set DAR in encoder to 37 : 20. The following line is for automatic signalling
global MeGUI_darx = 37
global MeGUI_dary = 20
LoadPlugin("C:\Program Files (x86)\meGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("C:\Users\Kalwaitis\Desktop\Movies Done\Aliens In The Attic\VTS_01_1.d2v", cpu=4, info=3)
LoadPlugin("C:\Program Files (x86)\meGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
#deinterlace
crop( 8, 8, -8, -8)

#resize
#denoise
trim(1600,1800)
If not then I suppose its my laptop's monitor display setup. The pictures really do not do justice to my issue as they hardly show anything at all.

http://img191.imageshack.us/img191/7065/unfiltered.mp4

[Lyle_JP]

Also, with a reasonably-well calibrated display setup, I can't even see any banding in your screenshots - unless I crank up gamma noticeably. It seems a modern disease - having a too bright display setup, then complaining because you see things that you are not supposed to be able to see (at least not too obviously).

Mis-calibrated monitors have been the bane of digital video's existence since the beginning. I blame the manufacturers, who for years have been making their out-of-the-box settings way too bright and way too cool (color temperature-wise) so that the picture on their sets "pop" on a brightly-lit sales floor.

Anyone serious about this hobby who does not own Avia, Video Essentials, or some other test pattern generator are doing themselves a great disservice.

[rkalwaitis]

Okay, tomorrow I will break out another monitor. But I do not understand why the problem only exist for some sources and not all, if the monitor is the culprit.

Also if I use FFDShow's Deband option it cleans up the clip, so as you can see Im confused a bit. However, I really appreciate the input and help.

[Caroliano]

Maybe it have to do with levels being out of place. Use the histogram visualization for levels at ffdshow to see if they are using the whole spectrum, or if there is an cut (hard or partial) in above TV levels. If that is the case, then try messing around with SmoothLevels (http://forum.doom9.org/showthread.php?t=137479). Further discussion: http://forum.doom9.org/showthread.php?t=113991

[rkalwaitis]

Caroliano,

I thought about that last night and its seems to be a possible solution. Im going to play with it more today. I used the TV2PC setting which helped a bunch, but made things a bit to dark. At least I think so. It may be how it is supposed to look :)

[rkalwaitis]

Here is the results of Lato's script. Im trying to use Didees Ylevels now. I found the thread, but I need more help with the settings for the four functions. Still trying to find those. The Top is the corrected version. Bottom is of course source.

[Caroliano]

Have you tried something like:
SmoothLevels(preset="tv2pc", Lmode=2, chroma=20, DarkSTR=100) ?

You can tweak chroma if you think the saturation is too low or too high, and tweak DarkSTR to control how dark the final picture will be.

[rkalwaitis]

Thanks Caroliano, I will try that out. I may have to ask Lato for help. He is really good at this stuff, since he created the scripts. I did try to use the DarkSTR setting but I only made things worse. But of course I didnt try to change the chroma.