Log in

View Full Version : Need Suggestions for VERY GRAINY source


Pages : 1 2 3 4 [5] 6 7

Amefurashi
13th February 2008, 21:25
I noticed a little problem on a scenechange using TemporalDegrain. Here are previous and next frame using

mpeg2source("...")
Spline36Resize(640,336,0,12,720,552).subtitle("source")

http://img165.imageshack.us/img165/811/source1np1.png
http://img292.imageshack.us/img292/181/source2lh5.png

...but applying the function at its defaults, video ends up like this:

mpeg2source("...")
Spline36Resize(640,336,0,12,720,552).subtitle("filtered")
TemporalDegrain()

http://img502.imageshack.us/img502/2240/filtered1oz9.png
http://xs224.xs.to/xs224/08073/filtered_2869.png


There's a slight ghost of MJF's jeans near the right shoulder of the bald guy. Could this be caused by high FFT's sigma of the denoised clip? I tried to lower the value, but that spot is still noticeable.

:confused:

Sagekilla
13th February 2008, 21:35
It could be the sigma; What value did you try afterwards? A more likely issue would be thSAD, so try tweaking thSAD1 and thSAD2 too, those two can have a ghosting effect if set too high.

@Nikos: I'll patch TD to limit to 1/2 of blksize. It defaults to blksize of 8 anyway, and the default overlap of 4 is 1/2 that. But, I'll add blksize param and adjust overlap so it doesn't go above 1/2 blksize.

Edit: It's patched now so overlap max is blksize/2. Values over this should default to half block size. The default overlap is now 0 also, to make it faster without impacting quality too much.

Nikos
13th February 2008, 22:09
You may also add and the limit parameter :)

limit: maximal change of pixel (like DeGrainMedian plugin to prevent some artefactes). Default is 255 (no limit).

Change the:
blksize = default( blksize, 8 ) # Larger is weaker and faster, smaller is stronger and slower.
to
blksize = default( blksize, 8 ) # 4 or 8 or 16, larger is weaker and faster, smaller is stronger and slower.

Sagekilla
13th February 2008, 23:07
See the Avisynth documentation (http://avisynth.org/mediawiki/Temporal_Degrain#Description) for better explanation of the parameters. The comments were meant mostly for people who wanted to tweak the script, since default settings worked perfectly fine 99% of the time. I've removed most of the information, now just providing a small blurb on what each parameter does (You should look up what each parameter does for the used function tbh). Anyone looking for proper syntax should look at the wiki now, until I can provide proper documentation within the script.

Also, thanks once again for the suggestion Nikos. I've updated the script to make use of limit as well as fixed a small issue where blksize was irrelevant. Try the new version Amefurashi with defaults, and tell me if it fixes anything. If not, lower limit from 255 to see if it fixes things.

Zanejin
13th February 2008, 23:55
Wait, I see some contradictions regarding blksize. While the Avisynth documentation on Temporal Degrain asserts that "higher values are faster, less accurate, and degrain less", one of Didée's posts (https://forum.doom9.org/showpost.php?p=1070187&postcount=71) states the opposite.

Terranigma
14th February 2008, 00:08
Blocksize 8 would be the most sufficient blocksize. With blocksize 4, you run the risk of actually having a frame or frames being skipped over by the analysis process, but as far as the actual denoising, it's more sufficient than 8 as it's more accurate and more sensitive to noise. Blocksize 16 is the least sensitive and fastest, but it's the safest to use as it's more than likely never to skip any frames (although I haven't seen any frames being skipped with a blocksize of 8 either).

Nikos
14th February 2008, 00:17
From mvtools doc:
blksize : Size of a block (horizontal). It's either 4, 8 or 16 ( default is 8 ). Larger blocks are less sensitive to noise, are faster, but also less accurate.

I am a little confuse!!!
Didée help us please.......

Edit:
Thanks Terranigma for the explain.

Terranigma
14th February 2008, 00:23
From mvtools doc:


I am a little confuse!!!
Didée help us please.......

The docs' correct.
Think of the blocksize also as a detection threshold, where higher values would pick up more frames in the detection process.

Blocksize 4 = the ultimate for denoising, but weakest for detection (may run the risk of skipping frames, leaving the frame untouched.)

Blocksize 8 = medium threshold detection, medium denoising.

Blocksize 16 = low denoising, highest detection.

Don't know how else to explain it. :P

Sagekilla
14th February 2008, 00:23
Well, I was a bit ambiguous there I guess. Blksize 4 in relation to Blksize 16 -- Blksize 4 is slower, and tends to denoise more strongly. Blksize 16 is faster, but doesn't denoise as strongly.

How's this? "MVAnalyse block size. Valid values are 4,8,16. Higher values are faster, more accurate in detection, and degrain less. Lower is the opposite, while blksize=8 is a happy medium between both."

Edit: I think it might be easier if I just said low values are slow and strong, while higher ones are faster but weaker.

Nikos
14th February 2008, 00:34
Now, with the Terranigma explain, we are all happy :)
Thanks again.

Zanejin
14th February 2008, 00:37
I still don't understand. Didée's post, referenced in my previous post, says,

With a blocksize of 4, the denoising is rather poor.
This is because with such a small blocksize, the ME engine is able to (partially) compensate the grain, which results in much less effective denoising.

How can blksize = 16 then offer the lowest denoising? There are even samples in his post that show blksize = 16 stabilizes and removes grain most effectively in comparison to blksize = 4 and blksize = 8.

Terranigma
14th February 2008, 00:40
I still don't understand. Didée's post, referenced in my previous post, says that "with a blocksize of 4, the denoising is rather poor.
This is because with such a small blocksize, the ME engine is able to (partially) compensate the grain, which results in much less effective denoising." How can blksize = 16 then offer the lowest denoising?
lowest as in, weakest in strength. Didée may be referring to the detection threshold as I was talking about. If you do some tests yourself between 16, 8, and 4, you'd see 4 being stronger than it's larger blocksize kin. Examine around edges, or in dark areas, that's where blocksize 16 and 8 tends to perform poorly. You win some, and lose some with whatever blocksize you choose. I stick to 8.

__
If i'm wrong on this (which I doubt from self-experience), then Fizick would need to update his doc. :D

Sagekilla
14th February 2008, 01:21
lowest as in, weakest in strength. Didée may be referring to the detection threshold as I was talking about. If you do some tests yourself between 16, 8, and 4, you'd see 4 being stronger than it's larger blocksize kin. Examine around edges, or in dark areas, that's where blocksize 16 and 8 tends to perform poorly. You win some, and lose some with whatever blocksize you choose. I stick to 8.

__
If i'm wrong on this (which I doubt from self-experience), then Fizick would need to update his doc. :D

I think it would solve a lot of problems if I just removed blksize all together and got rid of potential confusion, since 8 seems to be the "one size fits all"

That would go against giving you enough rope to hang yourself though ;)

Nikos
14th February 2008, 20:32
Sagekilla i thing that in post #116 you must change the red idx from 2 to 3.
# Second MV-denoising stage. We use MVDegrain2.
NR2 = (degrain==3) ? NR1x.MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,thSAD=SAD2,idx=2,limit=limit) :
\ (degrain==2) ? o.MVDegrain2(b1vec,f1vec,b2vec,f2vec,thSAD=SAD1,idx=2,limit=limit) :
\ o.MVDegrain1(b1vec,f1vec,thSAD=SAD1,idx=2,limit=limit)

Also may i replace the slow FFT3DFilter with the very fast RemoveGrain(mode=4) or for the prefiltered clip?

Terranigma
14th February 2008, 21:06
Sagekilla i thing that in post #116 you must change the red idx from 2 to 3.


No, that's correct; what he's doing there, is using the data from mvdegrain2 and then merging it with mvdegrain1 to create mvdegrain 3. If he wanted, he can even create mvdegrain 6, but only a crazed person would ever use it.

Also may i replace the slow FFT3DFilter with the very fast RemoveGrain(mode=4) or for the prefiltered clip?

You could, but he shouldn't; fft3d would be better than rg4. Don't have him change up the script unless he figures out good values for dfttest and use that instead. :D

Sounds like you're trying to turn this into what mc_spuds already is. :)

Nikos
14th February 2008, 21:23
Terranigma i am not an experienced user but in post #61 from Didée's script:
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)

Also from post #74:
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.)

Final look at post #148
Until Sagekilla comes around for cleaning, here's the corrected script:
.......
# Second MV-denoising stage. We use MVDegrain2.
NR2 = (degrain==3) ? NR1x.MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,thSAD=SAD2,idx=3) :
\ NR1x.MVDegrain2(b1vec,f1vec,b2vec,f2vec,thSAD=SAD2,idx=3)
The dfttest i thing is slow, any other fast filter for prefiltering?
Because we don't want quality but speed in prefiltering stage.

I have not read the mc_spuds until now, but i will give a try :)

Terranigma
14th February 2008, 21:33
Terranigma i am not an experienced user but in post #61 from Didée's script:

Actually, take a look @ post #70 to see how and what the script does; Didée breaks it down and tells you how it works.

Now about the same idx thing, take a look at this (http://forum.doom9.org/showthread.php?t=132310&page=7) post and scroll down a bit to see where using the same idx comes from. :)

Now, I like dfttest and fft3d for pre-filtering, because it lets you adjust all frequencies from a source with a given float value, whereas removegrain(#) might just operate on one frequencies, but always at the exact same strength; quality matters for pre-filtering too to a degree. ;)

Sagekilla
14th February 2008, 21:36
So is FFT3DFilter -- In fact, the way it was set up by Didee (bt=5, bw=16, bh=16, ow=8, oh=8) is EXTREMELY slow, but very high quality prefiltering. And yes, you do want quality in prefiltering. That's why I went a step further to add in a (optional) HQDn3D pass after FFT3DFilter to clean it up more. If you read the comments, ideally you want a very clean clip (no noise) clip so you can get better motion vectors, since there won't be any noise moving around to screw it up.

I'll test dfttest and FFT3DFilter to see the speed comparison, and play with the settings to see how good I can get dfttest to work. Also, if you want speed for prefiltering I suggest using FFT3DGPU in place of the CPU version, it can run in near realtime if you have a GPU (I'll add support for using GPU mode instead soon)



Results from testing dfttest:

Higher sigma means slower processing (at least it seemed to be much slower)
sigma=3 and tbsize=3 in the chain is half the speed of FFT3D (!) for the same quality.


Will work on other combinations, perhaps increasing tbsize a lot isn't the solution.

Adub
14th February 2008, 22:14
Yeah, you should be able to follow the link I posted, look to your left and find the "Upload File" Section. Under the Destination File name type "TemporalDegrain.avs" and select your TemporalDegrain.avs file using the browse button. It should say, "A file already exists with this filename, do you want to overwrite?" Just say, save or something like that, and double check on the main page that it is the correct version. Then, change the version number in the Function header on the main page.

Terranigma
14th February 2008, 22:18
Results from testing dfttest:

Higher sigma means slower processing (at least it seemed to be much slower)
sigma=3 and tbsize=3 in the chain is half the speed of FFT3D (!) for the same quality.


Will work on other combinations, perhaps increasing tbsize a lot isn't the solution.


Atm, the temporal operation of this filter (tbsize>1) is quite a bit slower than it needs to be since I don't cache the 2d transforms on each frame. The upside of the current method is that it uses a lot less memory (especially for small windows with large overlaps). If I get the time I will add optional caching.

If you think the quality's the same, then try changing the window method and increasing the overlap size. Unlike fft3d, the blocksize doesn't have to be blocksize/2, you can do something like this:
sbsize=8,sosize=6.
..and if you use subtract, you can see a big difference between overlap 4 and 6. :)

Nikos
14th February 2008, 22:35
Terranigma i read your suggestion, the script on post #116 and the script on post #148.
Now i thing that there are two more mistakes in post 116 (red color):
# 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)


# Second MV-denoising stage. We use MVDegrain2.
NR2 = (degrain==3) ? NR1x.MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,thSAD=SAD2,idx=2,limit=limit) :
\ (degrain==2) ? o.MVDegrain2(b1vec,f1vec,b2vec,f2vec,thSAD=SAD1,idx=2,limit=limit) :
\ o.MVDegrain1(b1vec,f1vec,thSAD=SAD1,idx=2,limit=limit)
o???

Look at post #148 Didée's opinion:
# 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)


# Second MV-denoising stage. We use MVDegrain2.
NR2 = (degrain==3) ? NR1x.MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,thSAD=SAD2,idx=3) :
\ NR1x.MVDegrain2(b1vec,f1vec,b2vec,f2vec,thSAD=SAD2,idx=3)
If i am wrong forgive me.
Didée help, please.

Sagekilla
14th February 2008, 22:39
Thank you for pointing that out nikos, that is indeed an error. I'll upload a fixed version shortly.

In regards to dfttest vs FFT3DFilter: I've found dfttest(sigma=2.5,tbsize=1,sbsize=8,sosize=6) works very well. It seems to retain a smidge more detail and handles the classic "grain and snow to soup" scene in 300 very well. Plus, in the two tests I've run it was faster than FFT3DFilter -- 2:08 vs 2:17 and 0:56 vs 1:25 (m:s, dft vs fft)


Edit: After this string of extremely bad syntax errors on my part, I'll take some time today to comb over my code and make sure no more like that arise.

Sagekilla
14th February 2008, 23:11
Alright, I've fixed a number of things and added a new parameter (for now) called ppass. If you use ppass="dft", dfttest will be used. Likewise, ppass="fft" will utilize FFT3DFilter.

Please test it on a number of scripts and tell me if there are any significant differences in quality and speed. I'd like to see if FFT3DFilter can be replaced by dfttest. Here's (http://avisynth.org/mediawiki/upload/6/69/TemporalDegrain.avs)the new version

Also, feel free to tweak the parameters of the dfttest call to see if you can improve it. Download the dfttest package from here (http://web.missouri.edu/~kes25c/) to get the documentation, or here (http://web.missouri.edu/~kes25c/dfttest.zip) for a direct link.

Terranigma
15th February 2008, 00:00
See, told you dfttest would be better. :P
I just wish the temporal operation was cached. If tritical takes request, then i'd only request for this to be fixed, and i'd like to be able to filter each frequency separately like with fft3d; That'd be very nice, but I think it might be better just to post this in the dfttest thread i've started.
Sage, could you try using the rectangular window instead of hanning (which is the default)? That's what i've found to be the better window type for denoising.

Also, for even faster processing, you can disable filtering the chroma planes, and just filter the luma like with fft3d by adding
Y=true, U=false, V=false to the filter. I've done a lot of tests with this filter, but one thing I still don't understand, is how to use cfile correctly; tritical would need to explain that a bit more or show some examples.
tritical, :script: :D

Sagekilla
15th February 2008, 00:03
Will do, I'll update dfttest to a rectangular window, disable chroma filtering and post results in a little bit.

Edit: New dft call takes 1:14 vs 1:17 for the old one. Quality differences may not be directly obvious though. Here's (http://avisynth.org/mediawiki/upload/6/69/TemporalDegrain.avs) the link to an updated TD

Sasovics
15th February 2008, 01:44
I have a problem playing back my avs script using the latest TemporalDegrain.avs v1.18

The clip plays, but the screen is completely black! What am I doing wrong ??

Here is my avs script:

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\dfttest.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\FFT3DFilter.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\mt_masktools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\MVtools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\HQdn3D.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\RemoveGrain.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\Repair.dll")
Import("C:\Program Files\AviSynth 2.5\plugins\TemporalDegrain.avs")

DirectShowSource("Source.grf", fps=23.976, framecount=165876, audio=false)
Crop(0,144,0,-136)
Spline36resize(1280,528)
Trim(0,5000)
TemporalDegrain()

The clip plays fine if I remove "TemporalDegrain()" line from my avs script...

Any idea guys ???

EDIT: @Sagekilla: Can you please post back the 1.17 version as that one was working fine for me, unfortunately I have overwritten it with this new one :(

Terranigma
15th February 2008, 01:55
add info() to your script, see what colorspace your source is. if it's anything other than YV12, then after directshowsource, add
ConvertToYV12()

___
It could be due to the changes he made; maybe he b0rk something, but i'm sure he'll have it fixed. :)

Sasovics
15th February 2008, 02:01
ColorSpace is YV12

Sagekilla
15th February 2008, 02:50
Very odd indeed -- Simply running TemporalDegrain() works fine for me. I'll go make sure the uploaded copy is identical to my local copy. Where did you download the script from? Avisynth wiki or from this thread?

Here's (http://avisynth.org/mediawiki/upload/6/69/TemporalDegrain.avs) a (slightly) updated copy. It may or may not fix your problem -- I'm not 100% sure.


On a side note, I really to start keeping copies of older versions.

Sasovics
15th February 2008, 02:57
Very odd indeed -- Simply running TemporalDegrain() works fine for me. I'll go make sure the uploaded copy is identical to my local copy.

Where did you download the script from? Avisynth wiki or from this thread?

I've downloaded it from here:

http://avisynth.org/mediawiki/upload/6/69/TemporalDegrain.avs

Sagekilla
15th February 2008, 03:04
I've downloaded it from here:

http://avisynth.org/mediawiki/upload/6/69/TemporalDegrain.avs

Hmm.. Did you try the copy that I just uploaded now?

Sasovics
15th February 2008, 03:08
Yes, still same issue :(

I have really no idea what might be going on ...

I have downloaded all the plugins as stated in your avs file,
except the fftw3.dll, that I had to download separately after my avs script complained about the missing DLL.

I have downloaded the fftw3.dll from here: http://forum.doom9.org/showthread.php?p=573156#post573156

EDIT: It works while encoding, but for some reason it does not work when I simply try to play my avs script in Windows Media Player or Media Player Classic.
also the x264 encoding is extremely slow! I am getting around 1fps in average... Is this normal ???

EDIT2: @Sagekilla: To avoid any version confusion, would you mind please to zip all your plugins used in this script (including your MT avisynth.dll) and upload it to RapidShare or MegaUpload ?
Many Thanks in advance!

Sagekilla
15th February 2008, 03:43
Yes, it's very normal for the encoding to run at 1 or 2 fps -- That's how slow the script runs. If you want it to run faster, try using TemporalDegrain(degrain=1,ov=2,pel=1,hq=2)

Also, I'll go zip the plugins used to mediafire in a moment for you. link (http://www.mediafire.com/?bdsfm4m2tzp)

Sasovics
15th February 2008, 03:45
What about loosing the quality using the above settings ? Is it noticable by naked eye ??

I just tried to encode couple of frames from Transformers HDDVD source and it gave me excellent results!

Sagekilla
15th February 2008, 03:47
No, there will be no loss of quality -- Only loss in degraining strength. MVDegrain2 (sometimes 3) is what I use on very heavily grained or noisy sources like 300. On the others I use MVDegrain1 because it's weaker, and much faster.

Sasovics
15th February 2008, 03:50
Great! Thx for the plugins.

One more question I have though ;)

What about the fftw3.dll ? Wasn't your avs script complainig about it ? I did not find it along with your archive.

Are you using the same version as I ? Downloaded from: http://forum.doom9.org/showthread.php?p=573156#post573156

Sagekilla
15th February 2008, 03:52
Sorry, forgot to include that.. You have to put that in your C:/Windows/System32/ folder. And yes, I run the same version.

thetoof
15th February 2008, 03:58
I don't know if it'll be of any help (and maybe you've already solved your problem), but here are a few things I can suggest you:

1 - Make sure fftw3 is in your system32 folder
2 - put all the plugins in avisynth's autoload plugin folder
3 - rename TemporalDegrain as "TemporalDegrain.avsi" and put it in avisynth's plugins folder
4 - Use a script with TemporalDegrain(whatever you like)

That's what I use and it works perfectly (you can still tweak some parameters in the .avsi if you want, but most sources will be handled very well), a simple script without any "loadplugin" or "import"... I have some other filters in my script, but it basically goes like this:

*Source("yourfilepathhere")
TemporalDegrain()

thetoof
15th February 2008, 04:04
@ Sagekilla

What is the difference in the corrected version you just uploaded? The only thing I can see is that "dft" and "fft" were switched in those lines. What's the effect of that tweak? I tried both and I can't see any visual difference...

filter = (ppass=="dft") ? filter.fft3dfilter(ncpu=ncpu,sigma=sigma,sigma2=s2,sigma3=s3,sigma4=s4,bt=5,bw=bw,bh=bh,ow=ow,oh=oh) : filter
filter = (ppass=="fft") ? filter.dfttest(sigma=2.5,tbsize=1,sbsize=8,sosize=6,u=false,v=false,swin=7,twin=7) : filter

Sagekilla
15th February 2008, 04:10
In my old script, the first line calls fft3dfilter IF prepass setting is "dft," while dfttest is called if prepass is "fft." It should be the other way around: fft calls fft3dfiler, and dft calls dfttest. It's a minor fix, but I also wen around making sure I had no syntax errors. I simply uploaded a new copy to be absolutely sure of this, so there may not be any other differences.

I'll try removing the dfttest filter and upload a new copy of Temporal Degrain labeled "experimental" that has this, while the standard one features the regular fft3dfilter call. I have a feeling that the problem is related to how I called fft3dfilter and dfttest.

Sasovics
15th February 2008, 12:19
Folks,

I've just encoded another 15000 frames from Transformers (h.264 1080p source - > x264 720p destination) and got more then excellent results!

AVInaptic reported VERY HIGH DRF quality when used Sagekilla's TemporalDegrain filter compared to MEDIUM DRF quality without the filter! Nice work Sagekilla!

The only backdraw is the speed.. At 2fps it would take almost 48h for me to encode the entire movie :( ... but that's the price paid for this quality boost

Adub
15th February 2008, 12:50
Just out of curiosity, were you using MT?

Sasovics
15th February 2008, 12:54
Actually no...

I have downloaded the MT version of the avisynth and have put this line into my avs script: SetMTmode(2), but for some reason
my encoding is even slower, and I have no idea why :(

fyi - I am running Intel Core 2 Duo E6700 2.6GHz


EDIT: Well, according to this (http://forum.doom9.org/showthread.php?p=852813#post852813) post, using MT when you already have 100%CPU usage (which I obviously have as x264 is running), will slow-down encoding even more...

Sagekilla
15th February 2008, 19:27
Thanks for the praise, but it should be directed towards Didee; He wrote the core functionality for TD. If you want, you can try TemporalDegrain(HQ=2,ov=2,Degrain=1) for a bit more speed. It doesn't degrain as strongly, but that's the offset of using MVDegrain1 over MVDegrain2.


I also have an extremely simple script that cleaned up 300 fairly well at about 6-8 fps. It's inherently multithreaded because I call MT() for the filter chain, so no need to use SetMTMode(). I'll send it to you if you're interested, but to be honest it's nothing special. Still, it did a fairly good job on degraining 300.

Sasovics
15th February 2008, 20:18
I am interested in that simplified script, please upload it to mediafire and I'll post back my feedback!

Thanks in advance!

Sagekilla
15th February 2008, 21:05
Here's the script, I couldn't upload it earlier because I was in school still. There should be a noticeable difference between Temporal Degrain and the Fast Degrain script, as well as a difference in sharpness since TD has Contra Sharpening.

Feel free to adjust any settings if you feel it isn't working for you, or you see room for improvement. Just ask that you send me a PM detailing any useful changes that I can add to this :) Only setting I recommend you be careful of is blksize, as sometimes you might getting blocking at 0 (I noticed this while testing on 300) If this is the case, raise it to 2.

###################################################################
# Fast Degrain by Sagekilla #
# #
# Nothing special, just removes noise and grain very quickly and #
# sharpens the image a bit. Runs at about 8 fps on my machine. #
# Tweak to your tastes, but defaults perform perfectly fine. #
# #
# Required plugins: HQDn3d.dll / LimitedSharpenFaster.avs #
# MT.dll / mt_masktools.dll / MVTools.dll #
# #
###################################################################

# Fast Degrain Syntax
#
# threads = Number of threads for MT -- Speeds up the program on multicores.
# degrain = Uses MVDegrain 1, 2, or 3. Each is progressively stronger and slower.
# thSAD = Affects overall degraining strength. Default works fine.
# limit = Limits maximum change from MVDegrain. Lower from 255 if you experience artifacts.
# pel = Subpixel accuracy for MVAnalyse. Increasing it raises quality of MVs and lowers speed.
# ov =

function FastDegrain( clip input, int "threads", int "degrain", int "thSAD", int "limit", int "pel",
\ int "blksize", bool "sharp", bool "post", int "str", float "ss", int "sft", int "oshot" )
{
threads = default( threads, 0 ) # Threads to use for MT
degrain = default( degrain, 2 ) # Degraining method
thSAD = default( thSAD, 350 ) # MVDegrain thSAD
limit = default( limit, 255 ) # MVDegrain limit
pel = default( pel, 1 ) # MVAnalyse pel
ov = default( ov, 0 ) # MVAnalyse block size
sharp = default( sharp, true ) # Toggles LSF
post = default( post, true ) # Toggles postprocessing
str = default( str, 150 ) # LSF strength
ss = default( ss, 1.5 ) # LSF supersampling
sft = default( sft, 40 ) # LSF soft
oshot = default( oshot, 0 ) # LSF overshoot
Return(input)
global idx1 = 50

MT("""
idx1 = idx1 + 1
f = last
o = f

# Search for motion vectors. No prefiltered clips because it slows things down too much.
b3vec = (degrain>=3) ? o.MVAnalyse(isb=true, delta=3,idx=idx1,pel=pel,ov=ov) : BlankClip
b2vec = (degrain>=2) ? o.MVAnalyse(isb=true, delta=2,idx=idx1,pel=pel,ov=ov) : BlankClip
b1vec = (degrain>=1) ? o.MVAnalyse(isb=true, delta=1,idx=idx1,pel=pel,ov=ov) : BlankClip
f1vec = (degrain>=1) ? o.MVAnalyse(isb=false,delta=1,idx=idx1,pel=pel,ov=ov) : BlankClip
f2vec = (degrain>=2) ? o.MVAnalyse(isb=false,delta=2,idx=idx1,pel=pel,ov=ov) : BlankClip
f3vec = (degrain>=3) ? o.MVAnalyse(isb=false,delta=3,idx=idx1,pel=pel,ov=ov) : BlankClip

# Degraining the video using MVDegrain. Nothing special here.
f = (degrain==3) ? f.MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,idx=idx1) : f
f = (degrain==2) ? f.MVDegrain2(b1vec,f1vec,b2vec,f2vec,idx=idx1) : f
f = (degrain==1) ? f.MVDegrain1(b1vec,f1vec,idx=idx1) : f

# Sharpen the video a bit to counter the slight loss of detail and texture.
# Follow this up by post processing to remove stray dancing pixels.
f = (sharp==true) ? f.LimitedSharpenFaster(strength=str,ss_x=ss,ss_y=ss,soft=sft,overshoot=oshot) : f
f = (post==true) ? f.HQDn3D(2,1,6,1) : f

return(f)
""",threads,2)
}

Enjoy.

Adub
15th February 2008, 21:59
Want me to add it to the wiki?

Sasovics
15th February 2008, 22:14
Where do I get the LimitedSharpenFaster.avs script ?

Adub
15th February 2008, 22:15
1. Using search.
2. Here:
http://avisynth.org/mediawiki/LimitedSharpen

Sagekilla
15th February 2008, 22:20
Want me to add it to the wiki?

You can stick it under the TemporalDegrain one as an alternative, faster degraining method. It uses pretty much the same syntax as TD does.