Need Suggestions for VERY GRAINY source

[Zep]

Zep, could you post your final AVS script that you used to make that final build? I would love to learn off of it. I have other movies that I own that are grainy and it ticks me off each time I watch them. They are as bad as 300, especially the first two Harry Potter movies. It's like they cone back to Video Tape days. :(

And I too have learned a lot about grain in this thread. The tips posted here are invaluable.


so I take it you watched the clips and like my final result? if you compare them side by side the difference really is huge and at half the bitrate I am very happy with the result.

so which one would you watch? hahaha

yes I will post the script first chance I get.

[Zep]

Yeah but there's exactly that: You have HD vs my SD. I don't know how well my source would hold up to your script. I'd love to test your script on my SD source but I haven't found a script (or didn't look hard enough, will later when I'm not so busy)

yeah my script may not work so well on lower rez stuff. I admit I spent hours and hours tweaking to the point it may only work on this movie and its grain for all I know.

What is even worse the speed. Even pass 1 in x.264 was only like 10 FPS and I normally get like 40 FPS when do just basic filtering.

Pass 2 was like 1.7 FPS :(


Did you get a chance to look at the final encode? Just curious as to your thoughts about it and if you felt it kept enough detail.
yes there was and will always be a little loss of detail but I tried very hard to keep the loss in the detail areas to a minimum via masking. it is by no means perfect.

[Zep]

In a nutshell:

- Grain removed, at the price of:

- faces often times look soapy
- some detail is emphasised, some detail is lost or blurred
- there is edge ringing and mosquito noise / texture echoes caused by FFT3DFilter

For what you have there, the bitrate is fully sufficient. More bitrate won't help for the downsides introduced by your filterchain.

It's by all means a respectable try, but "remastering" (your words) needs a bit more than this.

well if you look at the original there is just as much mosquito noise and even more in some scenes which I could upload if you really wanted to see more. And I could get rid of it with more tweaking and a mosquito noise filter in the chain. heck even adding undot may fix it since it is so light mosquito noise but I haven't gotten that far yet and I doubt I ever will.

"It's by all means a respectable try" thank you and I can improve and may give it a go some more in the areas you noted. I too saw the cons but it is slow going to test. I need a 8 core box for sure haha


Please do not twist context/meaning of what I said. I certainly did not say it is "remastering" in the hard core way you are trying to make it sound like I said.

what I did say however was "I feel is re-mastering type of filtering"

"I feel" as in my opinion

"type of filtering" as in it is not remastering in the classic sense but in the general sense of giving an over all better experience even at the cost of some things taking a slight hit. Also note this really is meant to be seen in motion. That is what I tweaked it for. if you do frame to frame compares only then yes you can see the cons a lot easier and will not even see the dancing grain in stills which was my main goal to get rid of even if it meant other areas had to take a slight degradation. This thread is about grain removal first and foremost after all. ;)

of course even with the cons the big question is, based on just the 1 clip which would you rather watch? Me I can't stand the dancing grain so you know what I would watch :D

[Zep]

It's by all means a respectable try


BTW - since you do have the original source clip why not give it a go and see what you can do with it and upload here so we can all learn even more. I for one would use anything you come up with to make it even better.

thanks,

Zep

[dbzgundam]

Be grateful you guys can at least enjoy the grain as an unmuddied mess in the Blu-Ray version. :)

The DVD version is not as forgiving (http://thevideophile.blogspot.com/2007/08/biggest-fucking-letdown-ever.html)

The heavy grain look as of late is just a mystery to me. I understand wanting SOME grain in an image, but film stocks have improved drastically over the last few years in constant efforts to reduce this if anything, and the advent of digital video has only led to nearly-grain-free (Well it is grain free, but has noise now) picture quality... Oh well.

I actually used degrain1 for this beast, and it handled it pretty well. The movie is actually fairly compressible due to the softness of the picture, large amount of slow motion scenes, and while it does have high contrast, a lot of blown out areas make it that much less difficult to compress.

[Sagekilla]

yeah my script may not work so well on lower rez stuff. I admit I spent hours and hours tweaking to the point it may only work on this movie and its grain for all I know.

What is even worse the speed. Even pass 1 in x.264 was only like 10 FPS and I normally get like 40 FPS when do just basic filtering.

Pass 2 was like 1.7 FPS :(


Did you get a chance to look at the final encode? Just curious as to your thoughts about it and if you felt it kept enough detail.
yes there was and will always be a little loss of detail but I tried very hard to keep the loss in the detail areas to a minimum via masking. it is by no means perfect.

Yes I did look at the encode, and personally I think if I were to use your script for encoding 300 it wouldn't be too bad since I'm using a much smaller resolution. (864x368 vs 1920x816) Plus I do use 1-pass crf so wouldn't have to worry about it being slow on a first pass since I am doing only one :)

[Zanejin]

The heavy grain look as of late is just a mystery to me. I understand wanting SOME grain in an image, but film stocks have improved drastically over the last few years in constant efforts to reduce this if anything, and the advent of digital video has only led to nearly-grain-free (Well it is grain free, but has noise now) picture quality... Oh well.

Grain is apparently becoming more and more popular and is not as undesired as one may think. It may give the illusion of detail and improve perceived color depth by dithering, or its abundance may simply appear more attractive to the general public. Much of 300's grain was added after filming.

[Sagekilla]

Grain is apparently becoming more and more popular and is not as undesired as one may think. It may give the illusion of detail and improve perceived color depth by dithering, or its abundance may simply appear more attractive to the general public. Much of 300's grain was added after filming.

In the case of 300 though, us DVD users pretty much get screwed over considering how poor our source quality is to begin with. Oh, what I would do for a Blu-ray player for my computer..

[Pookie]

Looks like Kassandro has chimed in on this topic-

http://videoprocessing.11.forumer.com/viewtopic.php?t=102

[Didée]

To not get accused of only babbling & critizising, without demonstrating something better, I gave it a go. Note it was quite an effort, since my PC is sub- (sub-sub-sub-...)-par for using demanding filters on & H264-encoding of HD content. You guys have machines that crunch 10 times faster than mine ...

Sample: MegaUpload (http://www.megaupload.com/de/?d=MVMZ5GTJ) -or- RapidShare (http://rapidshare.com/files/76643066/easy.mkv.html) (67MB)
[edit: now with working links...]

Bitrate came out a tad higher than that of Zep's sample (his: 4992 kbit, mine: 5066 kbit). No color correction was done. The grain was processed strictly temporal (spatial processing was only used for probability checks, but not applied in the denoising chain), and straightforward: no kind of area/detail/whatever masking was used.
Also, no arbitrary "pimp-it-up" sharpening was used; what has been used is a "dont-add-more-than-what-was-removed-previously" kind of sharpening. The goal was to keep the result looking the same as the original does ... just without the grain.

The filterchain definetly could benefit from some additional twists, but my pre-Christian Celeron doesn't allow for more. (That's why the result is named "easy".) The x264 encoding surely could be done better too - I'm an old-fashioned Xvid user, tweaking x264 is too complicated for me.:) (truley, I'm not fully satisfied with what I managed to get from x264. Is someone giving lessons?)


Some screenshots:

(middle= original / left= Zep's / right= my try)

Frame 50: http://img89.imageshack.us/img89/8953/fr50zeptx4.th.png (http://img89.imageshack.us/my.php?image=fr50zeptx4.png) <= http://img502.imageshack.us/img502/2481/fr50origfj5.th.png (http://img502.imageshack.us/my.php?image=fr50origfj5.png) => http://img502.imageshack.us/img502/5325/fr50easyis9.th.png (http://img502.imageshack.us/my.php?image=fr50easyis9.png)

Frame 686: http://img502.imageshack.us/img502/6344/fr686zephs1.th.png (http://img502.imageshack.us/my.php?image=fr686zephs1.png) <= http://img262.imageshack.us/img262/6521/fr686orighy8.th.png (http://img262.imageshack.us/my.php?image=fr686orighy8.png) => http://img502.imageshack.us/img502/4734/fr686easyyh5.th.png (http://img502.imageshack.us/my.php?image=fr686easyyh5.png)

Frame 910: http://img502.imageshack.us/img502/6100/fr910zepwh2.th.png (http://img502.imageshack.us/my.php?image=fr910zepwh2.png) <= http://img502.imageshack.us/img502/6963/fr910origci3.th.png (http://img502.imageshack.us/my.php?image=fr910origci3.png) => http://img502.imageshack.us/img502/2824/fr910easygd4.th.png (http://img502.imageshack.us/my.php?image=fr910easygd4.png)

Frame 1274: http://img502.imageshack.us/img502/5051/fr1274zepne5.th.png (http://img502.imageshack.us/my.php?image=fr1274zepne5.png) <= http://img502.imageshack.us/img502/9753/fr1274origmy6.th.png (http://img502.imageshack.us/my.php?image=fr1274origmy6.png) => http://img502.imageshack.us/img502/1777/fr1274easyjz6.th.png (http://img502.imageshack.us/my.php?image=fr1274easyjz6.png)

Frame 2100: http://img502.imageshack.us/img502/281/fr2100zepmx7.th.png (http://img502.imageshack.us/my.php?image=fr2100zepmx7.png) <= http://img502.imageshack.us/img502/9140/fr2100origux3.th.png (http://img502.imageshack.us/my.php?image=fr2100origux3.png) => http://img502.imageshack.us/img502/5899/fr2100easydb1.th.png (http://img502.imageshack.us/my.php?image=fr2100easydb1.png)


[post break because of image limit]

[Didée]

[continued]

Four Zoomings to quickly point out differences:

http://img262.imageshack.us/img262/5415/fr910zoom1zepja4.th.png (http://img262.imageshack.us/my.php?image=fr910zoom1zepja4.png) vs. http://img262.imageshack.us/img262/4253/fr910zoom1easybp7.th.png (http://img262.imageshack.us/my.php?image=fr910zoom1easybp7.png)

http://img262.imageshack.us/img262/6372/fr910zoom2zeprb1.th.png (http://img262.imageshack.us/my.php?image=fr910zoom2zeprb1.png) vs. http://img262.imageshack.us/img262/2808/fr910zoom2easyhz2.th.png (http://img262.imageshack.us/my.php?image=fr910zoom2easyhz2.png)

http://img262.imageshack.us/img262/3802/fr1274zoom1zepbb7.th.png (http://img262.imageshack.us/my.php?image=fr1274zoom1zepbb7.png) vs. http://img262.imageshack.us/img262/2751/fr1274zoom1easyqd3.th.png (http://img262.imageshack.us/my.php?image=fr1274zoom1easyqd3.png)

http://img262.imageshack.us/img262/2857/fr1274zoom2zepdm7.th.png (http://img262.imageshack.us/my.php?image=fr1274zoom2zepdm7.png) vs. http://img262.imageshack.us/img262/7929/fr1274zoom2easyku0.th.png (http://img262.imageshack.us/my.php?image=fr1274zoom2easyku0.png)


Hope this is sufficient to make my point: removing grain is okay if it annoys, but I'd want my result to keep the "natural" look. Sharp soup I like to eat, but not to watch.


Edit - the script: (compact version)

# LoadPlugins: FFT3DFilter.dll / mt_masktools.dll / MVTools.dll / RemoveGrain.dll / Repair.dll

AVCSource("X:\original.dga",deblock=true)

o = last
fft = o.fft3dfilter(sigma=16,sigma2=10,sigma3=6,sigma4=4,bt=5,bw=16,bh=16,ow=8,oh=8)
fftD = mt_makediff(o,fft)

b3vec1 = fft.MVAnalyse(isb = true, delta = 3, pel = 2, overlap=4, sharp=2, idx = 1)
b2vec1 = fft.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1)
b1vec1 = fft.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1)
f1vec1 = fft.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1)
f2vec1 = fft.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1)
f3vec1 = fft.MVAnalyse(isb = false, delta = 3, pel = 2, overlap=4, sharp=2, idx = 1)

NR1 = o .MVDegrain3(b1vec1,f1vec1,b2vec1,f2vec1,b3vec1,f3vec1,thSAD=300,idx=2)
NR1D = mt_makediff(o,NR1)

DD = mt_lutxy(fftD,NR1D,"x 128 - abs y 128 - abs < x y ?")
NR1x = o.mt_makediff(DD,U=2,V=2)

NR2 = NR1x.MVDegrain3(b1vec1,f1vec1,b2vec1,f2vec1,b3vec1,f3vec1,thSAD=300,idx=3)

s = NR2.minblur(1,1)
allD = mt_makediff(o,NR2)
ssD = mt_makediff(s,s.removegrain(11,-1))
ssDD = ssD.repair(allD,1) .mt_lutxy(ssD,"x 128 - abs y 128 - abs < x y ?")

NR2.mt_adddiff(ssDD,U=2,V=2)

return(last)

#------------------------------------------
# Taken from MCBob.avs:
function MinBlur(clip clp, int r, int "uv")
{
uv = default(uv,3)
uv2 = (uv==2) ? 1 : uv
rg4 = (uv==3) ? 4 : -1
rg11 = (uv==3) ? 11 : -1
rg20 = (uv==3) ? 20 : -1
medf = (uv==3) ? 1 : -200

RG11D = (r==1) ? mt_makediff(clp,clp.removegrain(11,rg11),U=uv2,V=uv2)
\ : (r==2) ? mt_makediff(clp,clp.removegrain(11,rg11).removegrain(20,rg20),U=uv2,V=uv2)
\ : mt_makediff(clp,clp.removegrain(11,rg11).removegrain(20,rg20).removegrain(20,rg20),U=uv2,V=uv2)
RG4D = (r==1) ? mt_makediff(clp,clp.removegrain(4,rg4),U=uv2,V=uv2)
\ : (r==2) ? mt_makediff(clp,clp.medianblur(2,2*medf,2*medf),U=uv2,V=uv2)
\ : mt_makediff(clp,clp.medianblur(3,3*medf,3*medf),U=uv2,V=uv2)
DD = mt_lutxy(RG11D,RG4D,"x 128 - y 128 - * 0 < 128 x 128 - abs y 128 - abs < x y ? ?",U=uv2,V=uv2)
clp.mt_makediff(DD,U=uv,V=uv)
return(last)
}

Note#1: The green part in the "ssDD=..." line was actually missing:eek: when I was creating the sample! Without that lutxy(), in some places a small amount of the original low-freq flicker is reintroduced. Consequentially, the sample is worse than it should have been. (a bit, at least) :)

Note#2: The script uses MVDegrain3. If you don't have MVTools v1.9.0, you can either use MVDegrain2 instead (with slightly worse results), or make a donation to Fizick (recommended!) to get the goodies more early. :)

[Zanejin]

Didée, both download links for your clip are... mis-pasted, shall we say? The results look great, though, and the zoomed-in screen-captures definitely show that your encode removes grain at a lower cost to detail—especially facial detail and skin features.

[jeffy]

Didée, please, could you:
1) correct the links to your samples
2) post the final script you used for encoding
EDIT: added: 3) the x264 commandline you used
Thank you.

[Didée]

The links are correct now. Sorry, it was in the middle of the night ...

post the final script you used for encoding
With pleasure. The final script used for encoding was this:

l = AviSource("processed_left_half.avi") .crop(0,0,640,528)
r = AviSource("processed_right_half.avi") .crop(64,0,640,528)

stackhorizontal( l, r ) ;) :)


The commandline was
--bframes 3 --b-pyramid --ref 4 --deblock -3:-3 --crf 18.75 --ipratio 1.25 --partitions all --direct temporal
--weightb --me hex --subme 5 --mixed-refs --bime --8x8dct --no-fast-pskip --aq-strength 0.2 --aq-sensitivity 12.5
--deadzone-inter 5 --deadzone-intra 9 -o "X:\easy.mkv" "X:\glue.left.right.avs"

[Terranigma]

EDIT: added: 3) the x264 commandline you used
Thank you.
use avinaptic to get the info.

The x264 encoding surely could be done better too - I'm an old-fashioned Xvid user, tweaking x264 is too complicated for me.:) (truley, I'm not fully satisfied with what I managed to get from x264. Is someone giving lessons?)


People tend to optimize their settings for maximum efficiency, and what I mean by this is optimizing for top quality alongside speed and grain retention. Because of how trellis-2 operates, no one really uses it (unless adaptive quantization is used as well to help with grain retention.)

Settings that aren't, and shouldn't be used for this type of processing, is b-rdo, subme-7, and trellis-2 for one. Also, sometimes, cpu usage plays a part in this as well, so mixed references is usually a no no :)

If you'd' like to see what the experts tends to leans towards, then you can get an idea from this commandline:

--pass 2 --bitrate xxxx --keyint 250 --min-keyint 25 --ref 5 --no-fast-pskip --bframes 3 --b-pyramid --bime --weightb --filter -2,-2 --subme 6 --trellis 1 --partitions all --8x8dct --direct auto --ratetol 1.5 --me umh --threads auto --thread-input --cqmfile "Prestige CQM.cfg" --progress --no-psnr --no-ssim --output "C:\Output Video.mkv" "C:\Input Video.avs"

Of course, getting to know what bitrate should be used, a crf encode is usually done first of a rate between 18.0 - 22.0. Mostly, 20.0

nice grain/quality/cpu usage/encoding speed. Adaptive quantization most of the times isn't needed with the above.

[jeffy]

The links are correct now. Sorry, it was in the middle of the night ...


With pleasure. The final script used for encoding was this:

l = AviSource("processed_left_half.avi") .crop(0,0,640,528)
r = AviSource("processed_right_half.avi") .crop(64,0,640,528)

stackhorizontal( l, r ) ;) :)




Didée: you know what I meant, we're not playing scrabble, are we? :) :D
Could you please post *cough* all the scripts you used until you reached these final encodes in their final form? :p
(I don't think think I will find a better wording.)

[foxyshadis]

The interesting thing about yours, Didée, is that it seems to meld the grain into what looks like fine detail. It's probably not the detail that was on the film prints, but it's essentially the same fake detail that the eye creates out of the grain.

Frankly, I'd love to use whatever you did on some detail-free videos, by first overlaying them with layers of grain. I've been trying to do that for years, but I could never find the right add/remove cycle to keep it from dancing and swimming.

[Sagekilla]

Very nicely done Didee.. Your script looks like it retains much more detail than Zep's does, with that said I have to hand it to both of you.. Both are an amazing improvement over the original, well done :)

I'd really love to see the filter chain you used to degrain the movie like that Didee! Also, it seems like the reason why yours was a slightly higher bitrate could because of the more detail yours retains. I noticed in the close up of faces yours had more skin detail than Zep's.

[Terranigma]

I noticed in the close up of faces yours had more skin detail than Zep's.
Perhaps because zep's was oversharpened? Sure, it may look great while playing, but when zoomed, you can see the detail that was destroyed. It's never good to oversharpen; there's a detail analysis out there that talks about edge-enhancement; maybe you could find it. :)

[Didée]

Could you please post *cough* all the scripts you used until you reached these final encodes in their final form?
You man ALL the scripts I used until finally arriving where we are now? Are you serious? That's probably thousand scripts and more, over all the years! :p


@ Terranigma: Thanks for the tips.;) In fact it's not too surprising ... it's a few details which are hard to judge from the theoretical side, while practice then may be different even more. (And doing much of testing is no fun for me ... if you had my PC, you would understand why...)
BTW, the latest plaything of Dark Shikari (new AQ) seems to come along very nice. I like it much. Hope that it's "generic" enough to become an official feature...

* * *

OK, I added the script to post#61 (http://forum.doom9.org/showthread.php?p=1076276#post1076276). The only change is that I added a small check that ultimately should have been there, but wasn't :o ...

In my opinion, the script's processing is rather easy, technically. It's kind of slow because quite some MV-stuff is used - but the mere processing chain is in no way fancy, but pretty straightforward. (It's a stripped-down-to-bare-bone version of really fancy grain removal scripts...)

The script again, blown up with some comments and hook-in points for easier modification:
AVCSource("X:\original.dga",deblock=true)

o = last
fft = o.fft3dfilter(sigma=16,sigma2=10,sigma3=6,sigma4=4,bt=5,bw=16,bh=16,ow=8,oh=8)


# "srch" is a prefiltered clip on which the motion serach is done.
# Here, we simply use FFT3DFilter. There're lots of other possibilities. Basically, you shouldn't use
# a clip with "a tiny bit of filtering". The search clip has to be CALM. Ideally, it should be "dead calm".
srch = fft


# "spat" is a prefiltered clip which is used to limit the effect of the 1st MV-denoise stage.
# For simplicity, we just use the same FFT3DFilter. There're lots of other possibilities.
spat = fft
spatD = mt_makediff(o,spat)


# motion vector search (with very basic parameters. Add your own parameters as needed.)
b3vec1 = srch.MVAnalyse(isb = true, delta = 3, pel = 2, overlap=4, sharp=2, idx = 1)
b2vec1 = srch.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1)
b1vec1 = srch.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1)
f1vec1 = srch.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1)
f2vec1 = srch.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1)
f3vec1 = srch.MVAnalyse(isb = false, delta = 3, pel = 2, overlap=4, sharp=2, idx = 1)


# 1st MV-denoising stage. Usually here's some temporal-median filtering going on.
# For simplicity, we just use MVDegrain.
NR1 = o .MVDegrain3(b1vec1,f1vec1,b2vec1,f2vec1,b3vec1,f3vec1,thSAD=300,idx=2)
NR1D = mt_makediff(o,NR1)

# limit NR1 to not do more than what "spat" would do
DD = mt_lutxy(spatD,NR1D,"x 128 - abs y 128 - abs < x y ?")
NR1x = o.mt_makediff(DD,U=2,V=2)


# 2nd MV-denoising stage. We use MVDegrain.
NR2 = NR1x.MVDegrain3(b1vec1,f1vec1,b2vec1,f2vec1,b3vec1,f3vec1,thSAD=300,idx=3)


# contra-sharpening: sharpen the denoised clip, but don't add more to any pixel than what was removed previously.
# (Here: a simple area-based version with relaxed restriction. The full version is more complicated.)
s = NR2.minblur(1,1) # damp down remaining spots of the denoised clip
allD = mt_makediff(o,NR2) # 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.

NR2.mt_adddiff(ssDD,U=2,V=2) # apply the limited difference. (sharpening is just inverse blurring)

return(last)

This is what is done:

1) Make a pre-filtering with FFT3DFilter. This one will be used for analysis and probability comparisons.

2) search motion vectors on the (calm) pre-filtered clip.

3) Cut down the grain's amplitude by:

- 3a) Make a motion-compensated denoising (optimally by temporal medianfiltering with temp.radius=2, but I'm having serious issues with the [only] available filter)

- 3b) Limit the effect of 3a) by that of a spatial filter

4) Make a motion-compensated temporal averaging of the clip with flattened grain

5) Sharpen the denoised clip. This is done in such a way that the sharpener is not allow to "add" more than what was previously "removed" by the denoising.

... and that's all, nothing spectacular.


The biggest difference to Zep's denoising is - most probably, since we didn't see his script up to now - the usage of fft3dfilter. It seems that he used to much of it, or at to strong settings. All the ringing and texture echoing is a typical side-effect fft3dfilter, when not used with enough caution. Judging from the overall look, I'd guess that Zep first did an initial filtering with fft3dfilter, and then continued to further process the result with MV-denoising. (Some places look like fft3d-banding that has been temporally averaged, but it's hard to judge after x264-compression.)

In comparison, my script never applies fft3dfilter in the chain that produces the output clip. Instead, it is only used as a "brake" to keep the 1st temporal filter within reasonable bounds. (Which is essential in the bigger scripts where the 1st stage is done with median filtering.)


@ foxyshadis
Yeah, the effect of producing "fixed grainage" ... it's interesting that the effect is almost impossible to avoid when strictly using only temporal averaging. Earlier I tried to get rid of it (it looks poor when the grainage is too strong), but that alwas comes at the cost of serious detail loss. I settled for keeping the effect low, then it looks quite convincing, mostly.

Can't tell if you get the same effect with synthetically generated noise. I suspect the effect comes from the fact that compressed film grain has pretty much invariance in its variance (hope this makes sense), where the gaussian noise of the usual noise generators seems to be much more regular. So, it could be you'd need a way to make the added noise, well, more "dirty".

[Sagekilla]

How do you convert the parameters for MVDegrain3 to MVDegrain 2? I'm looking at the code and the documentation but I'm having a very hard time converting it.

Edit: Figured it out. To anyone else confused, just replace the MVDegrain3 function with the following in both places it appears in: MVDegrain2(b1vec1,f1vec1,b2vec1,f2vec1,thSAD=300,idx=2)

Edit 2: Love how the filter works, I got a 43% reduction in bitrate when I used the filter chain. I also skewed the results slightly because I had Dark Shikari's new AQ running in both the degrained and straight from source encodes.

[Spuds]

Didée

As always very nice script, I really like the contra-sharpening section I think I will put that to some use in my overly complicated script :) Seeing the results of degrain3 is also very nice.

There were a couple of things I did not quite understand so if you could be so kind as to help me :confused:

1) on the nr1= line you use idx=2, should that be idx=1 or does the call to mvdegrain3 need to point to a different cache then the idx=1 vectors?

2) on the nr2= line you reuse the original motion vectors in mvdegrain3 but on a different (denoised) frame. At what point do motion vectors become invalid for reuse? I was under the impression that once you changed the center frame that new wing vectors should be computed. I'm also confused by idx in this line but the answer to 1 should help here.

Thanks!

EDIT: Ah now I see what you did, that center frame is not changed but limited. Should have followed the nr1x creation a bit more closely before I typed in my question number 2, now I see why those vectors can be used. Still confused by idx.

[Sagekilla]

Also, I'd love to see this more complicated version if you know how to/have it! As slow as the script runs with my insane x264 settings (0.8 fps, 20 hours for 60k frames!) I have no qualms with running a several day long encode to degrain 300 at a higher quality. Even a simple little suggestion on how to improve it more would be great :) I wish I could test out MVDegrain3 to see how much better it works, but there's no way for me to make a donation to get it (Seeing as I'm only 17 = no way for me to make that donation)

[Didée]

Spuds: don't think too complicated!;)
Motion vectors never get "invalid" in that sense. With idx, it's always the same game:

vec = clip1.MVAnalyse( ..., idx = _idx1 )
foo = clip2.MVToolsFunction( vec,.., idx = _idx2 )

As long as clip1 == clip2 (identical), you can (and should) use identical values for _idx1 and _idx2.

As soon as clip1 != clip2 (not identical), you have to use different values for _idx1 and _idx2.

The vectors stored in 'vec' stay valid as long as clip1 and clip2 are of same size, and are in sync. (E.g. If one of both clips got trim()'ed, then you need new vectors, obviously.)

[Fizick]

Note in addition: If you use single MVTools function with some input clip, idx may be simply omitted (it will be set to unique numbers internally for every such call).

Didée,
you must provide some name for your new script! :)
LowFrequencyFlickerRemover (LFFR) or somewhat like MiddleFreqDegrain ?

Sagekilla, be patient. :)

[Didée]

Some things get posted in form of a Function(). Some things get posted in form of a plain script.

Functions do have names. Plain scripts are just nameless plain scripts.

Usually, there is a reason for the decision of whether to post something as function or as plain script. :)


(If it has to be by all means, how about YAMCGC_EV - "Yet another motion compensated grain cruncher (easy version)" ...) :P

[Zep]

Be grateful you guys can at least enjoy the grain as an unmuddied mess in the Blu-Ray version. :)

The DVD version is not as forgiving (http://thevideophile.blogspot.com/2007/08/biggest-fucking-letdown-ever.html)

The heavy grain look as of late is just a mystery to me. I understand wanting SOME grain in an image, but film stocks have improved drastically over the last few years in constant efforts to reduce this if anything, and the advent of digital video has only led to nearly-grain-free (Well it is grain free, but has noise now) picture quality... Oh well.

I actually used degrain1 for this beast, and it handled it pretty well. The movie is actually fairly compressible due to the softness of the picture, large amount of slow motion scenes, and while it does have high contrast, a lot of blown out areas make it that much less difficult to compress.

What really annoys me is that they ADDED the grain in post production on purpose. The I-MAX version has NO GRAIN.

[Sagekilla]

Note in addition: If you use single MVTools function with some input clip, idx may be simply omitted (it will be set to unique numbers internally for every such call).

Didée,
you must provide some name for your new script! :)
LowFrequencyFlickerRemover (LFFR) or somewhat like MiddleFreqDegrain ?

Sagekilla, be patient. :)

Will do :) I'm really curious as to how much of an improve MVDegrain 3 will be making, and it seems like (from what I can infer) it uses an extra forward and backward motion vector.

[Zep]

Yes I did look at the encode, and personally I think if I were to use your script for encoding 300 it wouldn't be too bad since I'm using a much smaller resolution. (864x368 vs 1920x816) Plus I do use 1-pass crf so wouldn't have to worry about it being slow on a first pass since I am doing only one :)

haha yeah that should speed things up a good bit :D

Also I use pretty high x.264 settings. When I do get the best script from this thread and all the great ideas from everyone.
I plan to run a HQ-INSANE (Every setting maxed out) MEGA final run which should look awesome for only take like a week to encode :D

Going by what Didee said I have done more tests today and I need to better be able to selectively mask areas so the cons he was talking about are not so bad.

[Sagekilla]

haha yeah that should speed things up a good bit :D

Also I use pretty high x.264 settings. When I do get the best script from this thread and all the great ideas from everyone.
I plan to run a HQ-INSANE (Every setting maxed out) MEGA final run which should look awesome for only take like a week to encode :D

Going by what Didee said I have done more tests today and I need to better be able to selectively mask areas so the cons he was talking about are not so bad.

Mmm, yes it is quite a bit faster than an HD source, a blazing 0.87 fps! Only settings not maxed are refs (6) and ME (umh)

But, back on topic though, was your script (generally speaking) about the same methodology that Didee was using for degraining?

[Terranigma]

Will do :) I'm really curious as to how much of an improve MVDegrain 3 will be making, and it seems like (from what I can infer) it uses an extra forward and backward motion vector.
Well, I guess you could compare frames 3 to frames 2 from spuds' mc denoiser. Not sure it'd be that much of a difference like that script though. For now, we must speculate. :P

The thing I'm most interested in, is the faster mvanalyze.
That's why I made this (http://forum.doom9.org/showpost.php?p=1075538&postcount=562) post. :)

[Zep]

Grain is apparently becoming more and more popular and is not as undesired as one may think. It may give the illusion of detail and improve perceived color depth by dithering, or its abundance may simply appear more attractive to the general public. Much of 300's grain was added after filming.

yes but they added dancing grain and that is what really bugs me.


an example. The Spartan queen is very beautiful and in one close up shot of her face there was so much dancing grain her cute little birth mark could not be seen cause the dancing pixels were all over it to the point it to looked like grain. Same thing with her eye lashes. Total blasted out because of the dancing grain which makes it hard to see any detail that happens to be about the size of the grain. very distracting to me :(

[Sagekilla]

yes but they added dancing grain and that is what really bugs me.


an example. The Spartan queen is very beautiful and in one close up shot of her face there was so much dancing grain her cute little birth mark could not be seen cause the dancing pixels were all over it to the point it to looked like grain. Same thing with her eye lashes. Total blasted out because of the dancing grain which makes it hard to see any detail that happens to be about the size of the grain. very distracting to me :(

Indeed, I'm willing to settle with the level of grain present in 300 if it was not dancing grain. But, thanks to Didee I'll be using this script to see how well it degrains other noisy material and if it does work just as well, grain may very well disappear from my x264 encodes.

[Terranigma]

yes but they added dancing grain and that is what really bugs me.

I've noticed this dancing grain in newer dvd's as well. Looks like the only thing that can be done about it is to encode as mpeg-2, since it tends to hold grain easily, and banding? Not a problem with mpeg-2. :P

[Sagekilla]

I've noticed this dancing grain in newer dvd's as well. Looks like the only thing that can be done about it is to encode as mpeg-2, since it tends to hold grain easily, and banding? Not a problem with mpeg-2. :P

I've noticed that as well. MPEG-2 seems to handle video very well at a decent bitrate, whereas x264 you need to play around with the settings a bit to get it to work nicely, even with high bitrates. Kind of feels like we've gone two steps forward in terms of compression and a few more backwards in terms of grain retention/banding/other artifacts

[Zep]

To not get accused of only babbling & critizising, without demonstrating something better, I gave it a go. Note it was quite an effort, since my PC is sub- (sub-sub-sub-...)-par for using demanding filters on & H264-encoding of HD content. You guys have machines that crunch 10 times faster than mine ...

Sample: MegaUpload (http://www.megaupload.com/de/?d=MVMZ5GTJ) -or- RapidShare (http://rapidshare.com/files/76643066/easy.mkv.html) (67MB)
[edit: now with working links...]

Bitrate came out a tad higher than that of Zep's sample (his: 4992 kbit, mine: 5066 kbit). No color correction was done. The grain was processed strictly temporal (spatial processing was only used for probability checks, but not applied in the denoising chain), and straightforward: no kind of area/detail/whatever masking was used.
Also, no arbitrary "pimp-it-up" sharpening was used; what has been used is a "dont-add-more-than-what-was-removed-previously" kind of sharpening. The goal was to keep the result looking the same as the original does ... just without the grain.

The filterchain definetly could benefit from some additional twists, but my pre-Christian Celeron doesn't allow for more. (That's why the result is named "easy".) The x264 encoding surely could be done better too - I'm an old-fashioned Xvid user, tweaking x264 is too complicated for me.:) (truley, I'm not fully satisfied with what I managed to get from x264. Is someone giving lessons?)


Some screenshots:

(middle= original / left= Zep's / right= my try)

Frame 50: http://img89.imageshack.us/img89/8953/fr50zeptx4.th.png (http://img89.imageshack.us/my.php?image=fr50zeptx4.png) <= http://img502.imageshack.us/img502/2481/fr50origfj5.th.png (http://img502.imageshack.us/my.php?image=fr50origfj5.png) => http://img502.imageshack.us/img502/5325/fr50easyis9.th.png (http://img502.imageshack.us/my.php?image=fr50easyis9.png)

Frame 686: http://img502.imageshack.us/img502/6344/fr686zephs1.th.png (http://img502.imageshack.us/my.php?image=fr686zephs1.png) <= http://img262.imageshack.us/img262/6521/fr686orighy8.th.png (http://img262.imageshack.us/my.php?image=fr686orighy8.png) => http://img502.imageshack.us/img502/4734/fr686easyyh5.th.png (http://img502.imageshack.us/my.php?image=fr686easyyh5.png)

Frame 910: http://img502.imageshack.us/img502/6100/fr910zepwh2.th.png (http://img502.imageshack.us/my.php?image=fr910zepwh2.png) <= http://img502.imageshack.us/img502/6963/fr910origci3.th.png (http://img502.imageshack.us/my.php?image=fr910origci3.png) => http://img502.imageshack.us/img502/2824/fr910easygd4.th.png (http://img502.imageshack.us/my.php?image=fr910easygd4.png)

Frame 1274: http://img502.imageshack.us/img502/5051/fr1274zepne5.th.png (http://img502.imageshack.us/my.php?image=fr1274zepne5.png) <= http://img502.imageshack.us/img502/9753/fr1274origmy6.th.png (http://img502.imageshack.us/my.php?image=fr1274origmy6.png) => http://img502.imageshack.us/img502/1777/fr1274easyjz6.th.png (http://img502.imageshack.us/my.php?image=fr1274easyjz6.png)

Frame 2100: http://img502.imageshack.us/img502/281/fr2100zepmx7.th.png (http://img502.imageshack.us/my.php?image=fr2100zepmx7.png) <= http://img502.imageshack.us/img502/9140/fr2100origux3.th.png (http://img502.imageshack.us/my.php?image=fr2100origux3.png) => http://img502.imageshack.us/img502/5899/fr2100easydb1.th.png (http://img502.imageshack.us/my.php?image=fr2100easydb1.png)


[post break because of image limit]



I'm downloading the example now. Will check it out shortly.

Please delete some stuff in your inbox so I can reply to your PM.
I wrote back but am unable to send it to you as I get a "Can not send inbox is full error" :)

note I did not temporal really. mine was spatial removable mostly.

the single frames look good though that you did now to see if
the dancing is gone :P

[Zep]

Note#2: The script uses MVDegrain3. If you don't have MVTools v1.9.0, you can either use MVDegrain2 instead (with slightly worse results), or make a donation to Fizick (recommended!) to get the goodies more early. :)


I will give your script a go and yes though dancing grains is my main concern I do prefer at least 50% reduction in grain straight up. I truly feel they added too much heavy grain to this movie.


MVDegrain3?????? No fair!!!! access to tools we (I) do not have hahahahaha :D

[Sagekilla]

Personally, I think your spatial degrain looks a lot smoother and has an airbrushed look, Zep. Didee's looks like it retains more of the fine nuances in skin detail.

[Zep]

Very nicely done Didee.. Your script looks like it retains much more detail than Zep's does, with that said I have to hand it to both of you.. Both are an amazing improvement over the original, well done :)

I'd really love to see the filter chain you used to degrain the movie like that Didee! Also, it seems like the reason why yours was a slightly higher bitrate could because of the more detail yours retains. I noticed in the close up of faces yours had more skin detail than Zep's.

yeah I like them both a lot. I do want to pump up the selective sat more in Didee's and add in a some more selective masking to try and better hit only the areas that annoy ME but seem to be fine for Didee.


oh and hey slight advantage to didee for getting to work
FROM my better than original but I admitted could be improved starting point :) Now that I have his scripts I think I can do even better than either of ours by merging some of mine with his. Then didee will get to a new starting point to work from hahahaha

at this rate we may make it better looking than the I-MAX release :D

[Zep]

Perhaps because zep's was oversharpened? Sure, it may look great while playing, but when zoomed, you can see the detail that was destroyed. It's never good to oversharpen; there's a detail analysis out there that talks about edge-enhancement; maybe you could find it. :)

maybe. I used Didee SEESAW and it was the very first time I ever use it. I went with settings that pokie posted in a thread than brought out /sharpened and episode of "Lost"

I never tweaked it because I do not know enough about SEESAW
to know what does what. The problem I am still having is getting the perfect masks. some scene I get a perfect one then other it is way off (even more so in a fast cut scene change the first frame or 2 the masks suck) :(

[Zep]

Mmm, yes it is quite a bit faster than an HD source, a blazing 0.87 fps! Only settings not maxed are refs (6) and ME (umh)

But, back on topic though, was your script (generally speaking) about the same methodology that Didee was using for degraining?

some yes some no. His is more temporal, mine more spatial.

the thing that I MUST make clear is that Didee's and my goals on the final are not the same. I want all dancing grain removed
and more non dancing grain removed.

Didee is ok with leaving a good amount of grain in and looking for more of a balance to save detail and maybe give it a more natural look etc...


Me am leaning more towards more grain removal at the expense of slight detail loss because for me it is all about MOTION. His frame to frame compares to mine will always be better. heck I like them better also. But when watching the clips I lean towards my latest test clips I did today. Granted I now am using Didee's script tweak added with my own.

MY WHOLE POINT of that RANT?


this stuff is very subjective! I thought I was ok with a fair amount of grain left in as long as it was not dancing grain but it appears I hate any grain more than I thought :D

[Zep]

I've noticed this dancing grain in newer dvd's as well. Looks like the only thing that can be done about it is to encode as mpeg-2, since it tends to hold grain easily, and banding? Not a problem with mpeg-2. :P

yes! and I want to know WHY? damn it they should leave it clear and crisp. If we want grain it is much easier to ADD then to remove. :P

[Terranigma]

yes! and I want to know WHY?
To annoy consumers :angry:

[Zep]

Zep!

Didee!


clean out your PM box I can't send my reply to you because your PM space is all used up :D

let me know in PM when I can try to send my reply again. yes I answered your questions and yes you will find it interesting
(your first sentence was correct on so many levels haha)


thanks,


Zep

[Zep]

To annoy consumers :angry:

LOL yeah :P


seriously though I wonder why they added so much to 300. Grain is one thing but all that *dancing* grain is another and really does take away from the enjoyment (For me anyway) of the movie.

[Zep]

Hope this is sufficient to make my point: removing grain is okay if it annoys, but I'd want my result to keep the "natural" look. Sharp soup I like to eat, but not to watch.



So you are saying pookie's settings to your SEESAW added too much sharpening to my final huh :D

yes I used SEESAW :P and it was the very first time ever I used it and since I had no idea what settings to use I used one pookie posted somewhere showing sharpening to an episode of "Lost". yeah now that I think about it I should have turned it down some as I see looking at the pookie post he really brought out the detail/sharpen a lot in his example still frame compare. I probably should have cut the sharpening in SEESAW by about half and went more temporal for the grain removal/dancing. I do like the added rich colors I did though. I think the original was a little bland also. I feel now that with your script and mine and the tweaks I did today it is really rocking.

only down side the final encode is gonna take a week :(

[Zep]

The biggest difference to Zep's denoising is - most probably, since we didn't see his script up to now - the usage of fft3dfilter. It seems that he used to much of it, or at to strong settings. All the ringing and texture echoing is a typical side-effect fft3dfilter, when not used with enough caution. Judging from the overall look, I'd guess that Zep first did an initial filtering with fft3dfilter, and then continued to further process the result with MV-denoising. (Some places look like fft3d-banding that has been temporally averaged, but it's hard to judge after x264-compression.)

In comparison, my script never applies fft3dfilter in the chain that produces the output clip. Instead, it is only used as a "brake" to keep the 1st temporal filter within reasonable bounds. (Which is essential in the bigger scripts where the 1st stage is done with median filtering.)




basically correct. I on purpose went overkill on fft3dfilter with sigma 8 on luma only to get rid of more than just dancing grain but as much grain as I could without totally destroying the detail. Some mush came from this and why I had to add masking and then later I decided to add SEESAW but now that I look back at the final encode I feel the settings were too strong on BOTH fft3dfilter and seesaw. If I went sigma 6 then I could have lowered the SEESAW strength a lot and got more balanced encode I guess.

Still I do like mine a lot than the original and up until just 2 weeks ago I never ever did grain removal before. This was my very first foray into this area.


I have learned much in this thread over the last 2 weeks and now with your script and some of mine added and tweaked I think my next final encode it gonna just be mega awesome! ( for my tastes anyway haha)

(you may still think I blasted out too much grain)

[Zep]

@ Didee,

I like very much your final test. (I just watched it) Even though it leaves a little grain it is more than ok even for me because the detail is more even across the whole clip :D (I clearly overdid removal which then forced me to over sharpen)

Now the hard part for you. That scene is on the LOW END of the grain dancing and brutal grain scale. I picked that scene because it is a favorite scene of mine and also why I left the audio in when I made the clips :D

I ran your script and it is now having a harder time on the night scenes and the scenes where the grain is really really bad. My original final made them great and better than the clips I uploaded. My guess is than some of the cons were hidden (like ringing or halo) because they are dark night scenes and the eye can't spot them so easy. The grain looks even worse then because dark night sky with WHITE grain dancing stands out even more etc...

So now it has me wondering if you would be able to add some way to determine darker scenes and/or more grain so that your script will adjust the strengths during those scenes.

I can UL some clips for you to test on if you think it is possible and worth adding to your script.

PM me so we can talk more :)


Huge thanks!


Zep

[Terranigma]

I ran your script and it is now having a harder time on the night scenes and the scenes where the grain is really really bad.

Hmm, I thought that was just me. :cool:

After looking at the script, I don't think it's designed for dark noise filtering, but I could be wrong.

[Zep]

Hmm, I thought that was just me. :cool:

After looking at the script, I don't think it's designed for dark noise filtering, but I could be wrong.

Well to be fair Didee only had a very bright day scene to work with and he did an amazing job with it. I like it better than mine on grain and detail but I like mine better in night scenes and mega grain scenes.

if he could add a way to detect and change strengths based on darkness and grain amount. I would not even bother with my script anymore and I would only add some color masking to the chain so I could pick and choose sat boost / color corrections because I feel the original color wise is bland and washed out some.