New Filter: GrainOptimizer (2.02 -- Bug fixed with certain temporal denoisers)

[Dark Shikari]

>>>GrainOptimizer 2.02<<<

The only temporal-only grain reducer!

Simple summary:

This filter "slows down" the progression of grain over time to vastly decrease the bits required to encode that grain. On a per-frame basis, the filtered clip will look almost exactly the same as the original.

Pros: Huge bitrate drop over unfiltered clip (up to 40-50%+), and often higher image quality due to better bit distribution in encoding. Keeps the grainy look of the original source.

Cons: Temporal grain pattern isn't exactly the same as the original. Not as effective at lowering bitrate as a real, strong denoiser, if used alone. Less effective in very high-motion scenes; doesn't usually have negative effects but doesn't reduce the grain as effectively as in stationary scenes. Requires a powerful denoiser to input the denoised clip, so while fast alone, it isn't as fast in practice.

Full information:

One of the main problems with film grain is it is completely uncorrelated with the grain from the previous frame. This means that in low-detail blocks, such as the background of a frame (usually most of the blocks), the encoder is forced to use intra blocks instead of inter blocks, since the current frame's block is almost completely unrelated to the previous frame's block.

This filter resolves that by removing grain temporally but not spatially, in a manner in which the visual difference between the result and the original is minimal, and not even necessarily a negative difference. Using a combination of heuristics, it decides which areas of the frame should be acted on, and then which blocks should be retained between frames. As far as I have found in my testing, no visual artifacts are created by this technique as long as the proper heuristics are used.

This filter is somewhat motion-adaptive but not motion-compensated, and as a result it is quite fast (real-time on SD footage easily, even though it has no assembly code and is completely unoptimized). However, this also means it is not very effective in moving areas. This isn't really what the filter was meant to do to begin with though: its goal is to deal with background grain eating up bits, and that's what it does.

The end result is a basically "free" bitrate reduction of up to 50% at the same CRF/QP for high-grain sources, assuming that your bitrate is high enough that the encoder actually does attempt to preserve the grain--this is particularly important in x264, known for decimating grain at all but the lowest CRFs. Note that theoretically this filter will work for all encoders, not just x264--the benefits aren't as large in non-H.264 codecs, but both VC-1 and Xvid have shown bitrate drops of nearly 25% in my tests.

Note that you should have at least a few bframes and p4x4 blocks enabled to take full advantage of this filter. If it isn't clear at this point, the GrainOptimizer is intended as a preprocessing algorithm for a video encoder.

Syntax: GrainOptimizer(clip,denoisedclip,blocksize,strength,tdist,minrep)
Colorspaces supported: YV12 only (YUY2 and YV24 are possible in the future, RGB24/32 are not possible without drastically changing the algorithm.)

denoisedclip is the clip used for most of the internal heuristics and as such is very important. The better the denoiser you use, the better results you will get. A strong denoiser is recommended--losing details doesn't matter in this case, what matters is temporal stability. Inspect your denoised output if the filter doesn't seem to be working as well as it should; the denoised clip should have no noticable grain at all for maximum effectiveness. FFT3DGPU with a very high sigma (10+ for strong grain) + TTempSmooth works quite well, though I assume others like RemoveGrain(19) will work well also. Note this clip must be YV12.

blocksize is the size of the block (width/height) used for the block retention algorithm. 4 and 8 are the values currently supported, and 4 is the recommended default.

strength is by default 1 and is a decimal value. Note that as of version 2.0 the strength is automatically determined on a frame-by-frame basis--this number is simply a multiplier for the value determined internally. Don't change it unless the default has problems.

tdist is the maximum temporal distance, in frames, over which a block can remain static for due to the retention algorithm. It is by default 6: higher values will make the grain seem to move "slower", and lower values will make it seem to move "faster". A value as low as 2 will reduce the effectiveness of the filter somewhat but keep the grain's appearance almost exactly the same as the original. Higher values result in slower and slower grain, making it appear more like a static dither.

minrep sets the minimum number of grain replacements per macroblock. This is by default 8--higher values result in fewer blocks acted upon but more efficient action on those that are acted upon. Values cannot be above (256 / Blocksize^2) or below 0. The old behavior of the program, before this option existed, was equivalent to minrep=0.

Recommended: keep it at 8. Perhaps different values might be better with other codecs? Lowering the value will decrease efficiency but might make the result look more grainy.

This filter is experimental--report bugs and cases where it creates problems here, but don't complain about it doing so!

New version 2.02 (http://mirror05.x264.nl/Dark/force.php?file=./GrainOptimizer_2.02.zip)
New version 2.01 (http://www.mediafire.com/?5zgnzmp49gl)
Old version 1.2 (http://www.mediafire.com/?armdydnrwd1)

Version History:

2.02 -- Some temporal denoisers have very overly strong effects at scene changes, which tend to confuse the GrainOptimizer. This has been compensated for in most cases.
2.01 -- Bugs fixed with 2.0.
2.0 -- Rewrote over half the code. It now automatically determines the strength necessary on a frame-by-frame basis, to deal with changing grain patterns. The biggest change is that it requires a denoised clip as a second input, for much more accurate motion detection. Chroma option was removed for code simplicity.
1.2 -- Major improvements. Randomized starting array, resulting in slightly nondeterministic behavior but no "solid" appearance for the first few frames of an encode. A lot of improvements were made to considerably lower the bitrate by optimizing specifically for MPEG-4 ASP/AVC encoding styles and dealing with the residual costs of macroblocks. Additionally quality should be slightly improved, and some quality bugs fixed. New option added. Blocksize can now be 8, but is not recommended (though it should work).
Functional changes: the new version now should decrease bitrate on almost all input sources, including some reduction on already-denoised sources.
1.11 - Minor algorithm updates
1.1 - Major bugfix: GrainOptimizer now works correctly on longer sequences. Chroma heuristic added.
1.02 - Feature improvement: non-mod16 resolutions now supported.
1.01 - Minor bugfix: non-mod16 resolutions now correctly result in an error instead of a crash.
1.0 - Initial Release

[Guest]

What color spaces are supported?

[Dark Shikari]

What color spaces are supported?Added that info.

[Adub]

This certainly looks interesting. Do you mind if I ask were you go the 30% reduction numbers from? Just curious.

Unfortunately, I don't have any sources right now that would benefit from this filter, but as soon as I do, I will give it a try.

Unless you recommend using it on every single clip I might ever use? :)

[woah!]

mpc window crashes for me straight away :( script is ok without grainopt in it.

i see firsy frame and then mpc just closes itself with no error message.

[check]

I confirm it works.

@woah, are you running `GrainOptimizer()`?

[Dark Shikari]

This certainly looks interesting. Do you mind if I ask were you go the 30% reduction numbers from? Just curious.

Unfortunately, I don't have any sources right now that would benefit from this filter, but as soon as I do, I will give it a try.

Unless you recommend using it on every single clip I might ever use? :)
The 30% reduction is the max I got on some very very grainy sources given to me by Didee and Cruncher. The highest-motion, highest-detail sources with the least areas of flat background gave almost no improvement or none at all.

[Adub]

Huh. Good to know.

Theoretically, this might be a good filter for anime, no? They tend to have flat backgrounds and very little motion. I may have to try that out. I could also create some synthetic tests using addgrain() or something.

[Ebobtron]

@Dark Shikari
Thanks for the new filter.
With your filter in the AviSynth plug-in folder both VDub and avsFilmCutter crash without as much as a blink, wink or the famous request to phone home and tell mommy.

Both programs useAVSValue = env->GetVar("$PluginFunctions$");to load an AVSValue object full of the function names like "GrainOptimizer" and "GrainOpt_GrainOptimizer".

I am not much of a plug-in driver but as I remember it the trouble maybe in one of the following code examples. :)

// This is the function that created the filter, when the filter has been called.
// This can be used for simple parameter checking, so it is possible to create different filters,
// based on the arguments recieved.

AVSValue __cdecl Create_SimpleSample(AVSValue args, void* user_data, IScriptEnvironment* env) {
return new SimpleSample(args[0].AsClip(),env);
// Calls the constructor with the arguments provied.
}


// The following function is the function that actually registers the filter in AviSynth
// It is called automatically, when the plugin is loaded to see which functions this filter contains.

extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env) {
env->AddFunction("SimpleSample", "c", Create_SimpleSample, 0);
// The AddFunction has the following paramters:
// AddFunction(Filtername , Arguments, Function to call,0);

// Arguments is a string that defines the types and optional names of the arguments for you filter.
// c - Video Clip
// i - Integer number
// f - Float number
// s - String
// b - boolean

return "`SimpleSample' SimpleSample plugin";
// A freeform name of the plugin.
}

:thanks:

[Boulder]

I can't get the dll to load at all.. I'm running WinXP SP2. Autoloading or LoadPlugin doesn't do the trick, with LoadPlugin I just get the error message "Cannot load grainopt.dll". When autoloading, the function GrainOptimizer is not available.

[Daodan]

Not working here either. The script loads in vdm, but when I try to scroll it crashes.
Been following the other thread about this filter and the examples seemed to be pretty good, especially considering x264 kinda detemporalizes the grain by itself at medium bitrates, so maybe this can do same thing while preventing other side effects x264 makes at medium quants (~21 and up).

[Ebobtron]

This filter is experimental--report bugs and cases where it creates problems here, but don't complain about it doing so!Sorry didn't see that or more like notice before. Ok, I promise. :)

I thought I should note that in addition to my above remarks, that the filter seems to work fine for me when using "loadplugin". And yes it is very fast.

[Dark Shikari]

I forgot something: BOTH WIDTH AND HEIGHT HAVE TO BE MOD16, and I forgot to check for this :rolleyes:

New version uploaded.

[squid_80]

The manifest seems to be missing from the .dll.

EDIT: or is it compressed? If so I'd suggest ditching the compression.

[Dark Shikari]

The manifest seems to be missing from the .dll.

EDIT: or is it compressed? If so I'd suggest ditching the compression.Its compressed using PECompact--whats the problem with it not having a manifest? It seems to load correctly.

[squid_80]

It seems to load correctly.
Apparently not for the four people who have already reported having problems. What's it compiled with?

[Guest]

I forgot something: BOTH WIDTH AND HEIGHT HAVE TO BE MOD16 That's a severe limitation. It doesn't have to be that way.

[Dark Shikari]

That's a severe limitation. It doesn't have to be that way.No, it doesn't, but the algorithm requires it. The only way to get around it is basically to pad the sides or similar. I could have my filter simply pad the sides, do the algorithm, and then unpad the sides, of course.

Wait... quick question. In x264, when a video isn't mod16, does it pad all sides of the video or just one? The problem is that if the macroblocks in the video are off from what my filter thinks are the macroblocks, the filter will be drastically less effective.
Apparently not for the four people who have already reported having problems. What's it compiled with?
VC++ 2005 Express.

I replaced it with a non-compacted version--try it out now.

[Terranigma]

Thanks for the new filter. It seems promising. :)

[Boulder]

I replaced it with a non-compacted version--try it out now.Nope, still won't load:(

[Dark Shikari]

Non-mod16 now supported. The algorithm just doesn't act on the extra pixels, simple as that.

[Ebobtron]

@Dark Shikari
Thank you,
With current version VirtualDubMod and FilmCutter start and id funcition names correctly. :) :thanks:
@squid_80If so I'd suggest ditching the compression.Do you have time to describe the relevant issue with the compressed version of the dll ? :thanks:

[Mtz]

I'm not good in avisynth, but I made a small test on a VOB source.
In the first 177 frames (the duration of a movie scene), the filter is working. At frame 178 and after this frame when the action of the movie is changed, the filter is not working anymore.
Screenshots:
Frame 177
http://i23.tinypic.com/10z7q85.jpg
http://i22.tinypic.com/if0kyu.jpg


Frame 178
http://i20.tinypic.com/1231p4x.jpg
http://i22.tinypic.com/28kuhpc.jpg

The first screenshot from 177 and 178 is the original.

enjoy,
Mtz

[Dark Shikari]

I'm not good in avisynth, but I made a small test on a VOB source.
In the first 177 frames (the duration of a movie scene), the filter is working. At frame 178 and after this frame when the action of the movie is changed, the filter is not working anymore.
Screenshots:
Frame 177
http://i23.tinypic.com/10z7q85.jpg
http://i22.tinypic.com/if0kyu.jpg


Frame 178
http://i20.tinypic.com/1231p4x.jpg
http://i22.tinypic.com/28kuhpc.jpg

The first screenshot from 177 and 178 is the original.

enjoy,
MtzYup, I found an algorithm bug dealing with the improper (lack of) resetting some internal arrays... fixing now.

[rfmmars]

Yup, I found an algorithm bug dealing with the improper (lack of) resetting some internal arrays... fixing now.

Here's what I am finding using it in AVS-p.........I only see a small numbers of pixals in the center changing shape. so this may be related to the other members post about after frame 177.

Richard

[squid_80]

@@squid_80Do you have time to describe the relevant issue with the compressed version of the dll ? :thanks:
Because it was compressed it wasn't telling the OS correctly about what .dll files it needed to run.

If anyone is still having problems install the Visual Studio 2005 SP1 Redistributable Package.

[Dark Shikari]

Here's what I am finding using it in AVS-p.........I only see a small numbers of pixals in the center changing shape. so this may be related to the other members post about after frame 177.

RichardYup, there is a MAJOR bug in the current version that drastically decreases its capability. I have a working version right now and I'm recording bitrate decreases of over 30% in some cases, and on longer clips also (the bug caused anything other than short clips to end up in uselessness). Updated version will be uploaded soon.

[Dark Shikari]

Results on Cruncher's source material, settings 4-25-10-true, 2484 frames, 1920x800, at CRF 18:

Without GrainOptimizer:
18301kbps
SSIM: 0.961

With GrainOptimizer:
13970kbps
SSIM: 0.959

This is with the new, fixed version. Uploaded and fixed :)

[burfadel]

Works great, the 4,25,10 setting is much more effective, or seems to be, than the default. The strength of 25 actually resulted in a smaller file size than that if it were set to 50! (only slight, 4kb on the clip I used but thats still significant). I did find a few other things, although this is with only testing on that one 30 second segment of video...

- It does not work well with other noise reducers. I tried a clip with a couple of different types, enabled and disabled, and with the grainoptimise above and below them. In all cases the grainoptimiser by itself seemed to be better... and resulted in a smaller file. The actualy quality would be better than the combined settings unless the source is chronic.

- The optimiser HAS to be run before the resize filter, not after. On the test clip I used having it before the resize filter increased its effectiveness close to 100 percent over that of when its placed after the resizer (its twice as effective if placed before). The clip Dark Shikari used for his test wasn't resized (from what I can tell), and hence he got his 30 percent effectiveness. I got 15 percent reduction with the filter right after the resizer (spline64resize) and 30 percent right before the resizer! :)

- Its quite fast, faster than most other noise reducers I've seen. Once optimised it will likely to be one of the fastest available! :)

[Dark Shikari]

- The optimiser HAS to be run before the resize filter, not after. On the test clip I used having it before the resize filter increased its effectiveness close to 100 percent over that of when its placed after the resizer (its twice as effective if placed before). The clip Dark Shikari used for his test wasn't resized (from what I can tell), and hence he got his 30 percent effectiveness. I got 15 percent reduction with the filter right after the resizer (spline64resize) and 30 percent right before the resizer! :) Now this is very interesting. I would have expected running it after the resize filter to be much better, since its meant to operate on the same macroblocks the encoder operates on. It would be interesting to figure out exactly why its so much better before the resizer. Perhaps because a resizer like Spline "spreads out" the effect of the grain a lot?

[ToS_Maverick]

i tested your filter with the suggested settings from above and got some artifacts:

normal, "optimized"
http://img73.imageshack.us/img73/6905/110origsmallzh2.th.png (http://img73.imageshack.us/my.php?image=110origsmallzh2.png) http://img522.imageshack.us/img522/5051/110optsmallbs6.th.png (http://img522.imageshack.us/my.php?image=110optsmallbs6.png)

http://img522.imageshack.us/img522/2149/330origsmallyg2.th.png (http://img522.imageshack.us/my.php?image=330origsmallyg2.png) http://img256.imageshack.us/img256/6541/330optsmallvj4.th.png (http://img256.imageshack.us/my.php?image=330optsmallvj4.png)

in the first example some horizontal lines got introduced, in the second example the background get's "optimized" away :D

[Dark Shikari]

i tested your filter with the suggested settings from above and got some artifacts:

normal, "optimized"
http://img73.imageshack.us/img73/6905/110origsmallzh2.th.png (http://img73.imageshack.us/my.php?image=110origsmallzh2.png) http://img522.imageshack.us/img522/5051/110optsmallbs6.th.png (http://img522.imageshack.us/my.php?image=110optsmallbs6.png)

http://img522.imageshack.us/img522/2149/330origsmallyg2.th.png (http://img522.imageshack.us/my.php?image=330origsmallyg2.png) http://img256.imageshack.us/img256/6541/330optsmallvj4.th.png (http://img256.imageshack.us/my.php?image=330optsmallvj4.png)

in the first example some horizontal lines got introduced, in the second example the background get's "optimized" away :DThat looks very good to me--what horizontal lines are you talking about? That looks like the filter actually made the result a bit sharper, which looks quite good IMO. Are these images after or before encoding?

Edit: Ah yes, I see the slight horizontal lines... I would suggest you use slightly weaker settings.

[ToS_Maverick]

first example the background wall, left of johnny's shoulder.

also there are 4x4 blocks during motion scenes, do you want a shot of it as well?

EDIT: oh, the images are from the avs-script, before encoding

[Terranigma]

I can attest to this as well. :stupid: What do you propose Shikari? This is coming from the default settings of just GrainOptimizer(). Perhaps you didn't thoroughly check the filter before submitting the newer build?

[Dark Shikari]

That looks really strange, because my code has something to specifically stop that sort of thing... can one of you upload a VOB/M2V sample for me to test on?

[Mtz]

Also bad encodes with the file from attachment. I uploaded the file to test yourself your plugin because I don't want to post here too many screenshots. On this source I think xvid encode will look better than x264 with or without grainoptimizer.
The vob is here. (http://www.mytempdir.com/2036161)

enjoy,
Mtz

[Dark Shikari]

first example the background wall, left of johnny's shoulder.

also there are 4x4 blocks during motion scenes, do you want a shot of it as well?

EDIT: oh, the images are from the avs-script, before encoding4x4 blocks.. can you please upload the source? I'll need to update my heuristic to fix this.

[Dark Shikari]

It seems some of the problems seem to be caused by using GrainOptimizer with another denoiser, which seems to always give negative results. I've noted this in the original post.

[Sagittaire]

Encoder like VC1 PEP or Cinevision encoder use particular HVS masking filter for grain: spatial/temporal filtering in dark area.

[ToS_Maverick]

@Dark Shikari:
here is a still active link (http://forum.doom9.org/showthread.php?p=1028047#post1028047) to the source.

as Sagittaire suggested, you could include something like that to x264, so that x264 behaves like XviD with grain, if somebody is interested in such behaviour. maybe the more you compress, the less random the grain gets.

[burfadel]

Now this is very interesting. I would have expected running it after the resize filter to be much better, since its meant to operate on the same macroblocks the encoder operates on. It would be interesting to figure out exactly why its so much better before the resizer. Perhaps because a resizer like Spline "spreads out" the effect of the grain a lot?

I did another lot of tests regarding this, and came up with the same result. Putting the grain optimiser right before the resizer always came up with a smaller file (I haven't checked the measured quality, my post is about final file size alone) - although the files seem identical.

This is not just confined to the spline64 resizer. I tried the spline36 resizer, Lanczos resizer (with 3 taps, 4 taps, and 6 taps), and Bicubic resizer. All of these were reducing the resolution of the encode. I also tried an encode with the enlarged, and still it came up with a better result with the grain optimiser before the resizer!

The difference isn't overly large, but there is a difference. On one encode it yielded a better difference than that of between using a Subme of 6 and subme of 7!

It may be because the resizer affects the grain in a negative way, reducing the effectiveness of the removal? ... I guess the only thing is to try it for yourself! lol

[Terranigma]

@Dark Shikari:
here is a still active.
Tos, are you using grainoptimizer after denoising? If so, then that's your problem.

[ToS_Maverick]

nope, no denoising.

[Dark Shikari]

@Dark Shikari:
here is a still active link (http://forum.doom9.org/showthread.php?p=1028047#post1028047) to the source.

as Sagittaire suggested, you could include something like that to x264, so that x264 behaves like XviD with grain, if somebody is interested in such behaviour. maybe the more you compress, the less random the grain gets.I'll try this source next and see if I can replicate the problem.

[ToS_Maverick]

thank you, that's the script i'm using for comparison:

DGDecode_mpeg2source("Black.Pearl.Sample.d2v", idct=7)
opt=last.GrainOptimizer(blocksize=4,strength=25,tdist=10,chroma=true).crop(4,58,712,360).LanczosResize(768,320)
crop(4,58,712,360).LanczosResize(768,320)
interleave(last,opt)

[Dark Shikari]

I've made some modifications but I'm not even sure if they're positive or not--I think the simple conclusion is that your source isn't grainy enough for the filter to be useful.

[Dark Shikari]

I managed to fix the main artifacting issues, but the main problem is with the source itself--its covered in artifacts! Look at the first frame that contains a close-shot of Orlando Bloom's face--its a complete mess of blocks.

[Dark Shikari]

Updated to 1.11 with some slight algorithm changes to fix some of the previously found artifacts. Here's a frame comparison with Elecard Streameye of a B-frame in a max-setting Mainconcept-encoded clip, at 12000kbps.

(click for full)

Key: Red/orange = intra, blue = inter, yellow = skip, green = direct

Without GrainOptimizer:

http://i22.tinypic.com/97pfkk.png (http://i22.tinypic.com/97pfkk.png)

With GrainOptimizer:

http://i24.tinypic.com/rmmlhz.png (http://i24.tinypic.com/rmmlhz.png)

:cool:

Terranigma asked me to do a test with artificial grain, so I denoised that same clip with mocomp'd fft3dfilter and then used addgrain(20,0.2,0.2). The result was 25 megabits at CRF18 without GrainOpt, and 14.5 megabits with GrainOpt, a massive difference. Moreover, GrainOpt actually looked slightly better--though the background grain moved slower, as a result more bits were available to keep the grain in moving areas, and so the grain looked much more accurate to the original (original output of the script that is) IMO.

[Dark Shikari]

A test on Xvid shows that the latest version decreases bitrate by 18% at CQ3 on max settings. an almost exactly equivalent decrease was measured in VC-1 on Quality 90 (15.2mbps -> 12.5 mbps).

[burfadel]

Anyone else found the optimsier works better (for example) right before the resizer instead of right after?

[Wishbringer]

@Dark Shikari: Does FFT3Dfilter count as Denoiser for your plugin?

[Didée]

Source: strong Grain sample (http://home.arcor.de/dhanselmann/_samples/Alien2_scene1_source.m2v)

Using GrainOptimizer v1.11.

Achieved relative filesizes:

no filters GrainOpt() GrainOpt(str=24) GrainOpt(str=50)

Xvid q2 100% 100.5% 101.2% 100.3%

h264 q18 100% 101.7% 101.3% 97.5%


On this source I get at best minimal bitrate savings with very high strenght.

With default settings of GrainOptimizer, the achieved bitrate *increases*.

Who's to blame -- me, the filter, the source?

[Dark Shikari]

Source: strong Grain sample (http://home.arcor.de/dhanselmann/_samples/Alien2_scene1_source.m2v)

Using GrainOptimizer v1.11.

Achieved relative filesizes:

no filters GrainOpt() GrainOpt(str=24) GrainOpt(str=50)

Xvid q2 100% 100.5% 101.2% 100.3%

h264 q18 100% 101.7% 101.3% 97.5%


On this source I get at best minimal bitrate savings with very high strenght.

With default settings of GrainOptimizer, the achieved bitrate *increases*.

Who's to blame -- me, the filter, the source?
That's extremely strong grain--much stronger than the sources I tested on. Try a very, very high strength value--perhaps 250 or higher--the default settings aren't meant for grain with that insane of a standard deviation. I just tested 250 and there didn't seem to be any particularly noticeable visual artifacting in a quick scan of the encoded stream.

[foxyshadis]

Having a little trouble here myself, I just can't seem to make it strong enough to help much. You can get a copy of the source yourself from:
BlankClip(pixel_type="YV12",color=$808080).AddGrain(1000,0,0)

(Well, it was the next logical step.... j/k :p)

[rfmmars]

Having a little trouble here myself, I just can't seem to make it strong enough to help much. You can get a copy of the source yourself from:
BlankClip(pixel_type="YV12",color=$808080).AddGrain(1000,0,0)

(Well, it was the next logical step.... j/k :p)

Same here not large reduction of grain. When you are using the word "film", to me that means 8mm, Super 8mm home movie film which has large grain, did you really mean "Video" or video made to look like film?

Richard
photorecall.net

[Terranigma]

I had Shikari do a test last night with addgrain through irc, with mild settings ((20,.2,.2): Not as strong as yours, but I did suggest 10,000 in place of 20 =P) with and without grainoptimizer (encoding using x264 with a fixed crf). Without grainoptimizer, he ended up with a file having a bitrate of 25139kbps. Using GrainOptimizer, he ended up with a file having a bitrate of 14553kbps (I'm not sure, but I think he used the default settings of grainoptimizer). I think that's pretty impressive if you ask me.

[Dark Shikari]

I had Shikari do a test last night with addgrain through irc, with mild settings ((20,.2,.2): Not as strong as yours, but I did suggest 10,000 in place of 20 =P) with and without grainoptimizer (encoding using x264 with a fixed crf). Without grainoptimizer, he ended up with a file having a bitrate of 25139kbps. Using GrainOptimizer, he ended up with a file having a bitrate of 14553kbps (I'm not sure, but I think he used the default settings of grainoptimizer). I think that's pretty impressive if you ask me.And improvements are coming--I discussed a few of the finer aspects of inter/intra MB coding with Akupenguin last night and I'm working on some modifications to improve efficiency.

[Fizick]

for real film grain you need in real degrainer (degrainmedian, etc). BTW they will decrease filesize too ... ;)

[Dark Shikari]

for real film grain you need in real degrainer (degrainmedian, etc). BTW they will decrease filesize too ... ;)The entire point of this plugin is to not actually remove the grain--to keep the grainy feel while decreasing the filesize ;)

Ideally it should work on any "level" of grain as long as the grain is weaker than the image itself--I may decide to "linearize" the strength so that you don't have to massively raise to deal with grain that is, say, 2x stronger.

[rfmmars]

for real film grain you need in real degrainer (degrainmedian, etc). BTW they will decrease filesize too ... ;)

Yes I am very happy with your plugins, so far its the best.

Richard

[rfmmars]

The entire point of this plugin is to not actually remove the grain--to keep the grainy feel while decreasing the filesize ;)

Ideally it should work on any "level" of grain as long as the grain is weaker than the image itself--I may decide to "linearize" the strength so that you don't have to massively raise to deal with grain that is, say, 2x stronger.

Ok I should have read more into the name of the plugin. For me file size isn't important at all, so you have answer my question.

Many thanks,

Richard

[burfadel]

Hey Dark Shikari? habe you checked the before and after the resizer thing I mentioned? or is there an issue in the filter that will be fixed with the new improvements beyond 1.11 that you mentioned?

Its great filter btw, simple in concept but exremely effective!

[Raere]

Pardon my stupidity, but by grain, do you mean noise? If so, should I use the optimizer, then a denoiser?

[burfadel]

by grain its means the (usually) slight fuzzy dots which appear in the picture. This optimiser is much better than a denoiser in my opionion, as some noise can actually make the picture look better, at least a very slight noise (heavy noise is different). For heavy noise a denoiser would probably be more appropriate depending on the situation.

The other thing with denoisers is that they often remove some picture quality as well, whereas the optimiser doesn't (not noticeably). The best thing to do is use a short 30 second clip and judge the best thing for your use. If you keep the clip the same, use the denoiser in one, and the optimiser in the other. Running a denoiser and the optimiser together doesn't work properly as the denoiser will annialate the work of the optimiser, and if the optimiser is user after it won't work properly on the now modified blocks.

[MfA]

Instead of copying the blocks from previous frames couldn't you try to copy the noise/grain? Ie. subtract degrained images from the originals and add the result to the following degrained frames for static blocks, and just copy the original for motion blocks. The damage which can be done due to misdetected motion is far less than when you copy previous frame blocks.

[Dark Shikari]

Instead of copying the blocks from previous frames couldn't you try to copy the noise/grain? Ie. subtract degrained images from the originals and add the result to the following degrained frames for static blocks, and just copy the original for motion blocks. The damage which can be done due to misdetected motion is far less than when you copy previous frame blocks.That's a lot more difficult though--defining exactly what the grain is is much more difficult than defining whether or not a block is grainy.

Odds are that would probably create more artifacting due to misdetection of what is and is not grain in a grainy block.

[Didée]

That's extremely strong grain--much stronger than the sources I tested on. Try a very, very high strength value--perhaps 250 or higher--the default settings aren't meant for grain with that insane of a standard deviation.
Of course that is strong grain -- that's where the fun is. Dealing with elfin grain (can only be seen at full moon) is easy ...

I just tested 250 and there didn't seem to be any particularly noticeable visual artifacting in a quick scan of the encoded stream.
... where in contrary, at times there are way too much artfefacts even with the conservative default settings:

source:
http://img232.imageshack.us/img232/6950/sourcegrainoe5.th.png (http://img232.imageshack.us/my.php?image=sourcegrainoe5.png)

GrainOptimizer(strength=8) # default
http://img119.imageshack.us/img119/5998/defaultgrainoptimizerar3.th.png (http://img119.imageshack.us/my.php?image=defaultgrainoptimizerar3.png)

Zoom in - to my eyes, that's one huge 4x4 blocking festival. Isn't it?

[Kurth]

The plugin is not loading here =(

http://img213.imageshack.us/img213/8574/errorhr3.png

Any ideas on how to make this plugin load correctly?

[Boulder]

Try installing the the Visual Studio 2005 SP1 Redistributable Package, it worked for me (forgot to report).

[Kurth]

Thanks Boulder :)

[Sagekilla]

@Didee, I noticed something similar to that myself. I was doing a quick visual inspection through mpc and I ended up noticing in certain areas there was some really funky artifacts going on.

Shikari, any word on why this is happening? I'll see if it happens again and try to post some screenshots or the videos themselves.

[Dark Shikari]

@Didee, I noticed something similar to that myself. I was doing a quick visual inspection through mpc and I ended up noticing in certain areas there was some really funky artifacts going on.

Shikari, any word on why this is happening? I'll see if it happens again and try to post some screenshots or the videos themselves.I'll try to work on it a bit over the weekend if I can.

[burfadel]

This filter is already fast, how much faster do you think it would be once is it optimised? also, did you find out why the filter works better before the resizer? or is that only occurring with me? lol oh, I also don't get any artifacts at 25, or seem to anyway, but when I ramped it up to 250 I noticed that there were bad artifacts on darkish late afternoon sky (with a bit of thin cloud).

[Dark Shikari]

New version released--lots of improvements made. The bug previously mentioned should be fixed. Full improvement list in the original post.

Note that it now seems to work effectively on all sources, even those with no grain, at least bitrate-wise. That means its even useful after, say, FFT3Dfilter :)

[Terranigma]

Is this filter now safe to use, or will Didée show us some more bad examples? =P

[Dark Shikari]

Is this filter now safe to use, or will Didée show us some more bad examples? =PPerhaps, so far it seems fine (Didee's sample clip works fine for me with the new version at 4,25,8,true,8, for example).

[ChrisW77]

Great filter, love it.

Just a couple of questions,

Does this filter work well if you add grain to a source ?

For example, I have a lot of old VHS material, and it looks good if you add grain near the end of the script, as it does a good job of fooling the eyes into thinking your source is actually better than it actually is.

Lastly, what codec do you recommend to use on a grainy source ?
Is x264, able to keep most of the grain, using (for example) a high quality profile ?

[Dark Shikari]

Great filter, love it.

Just a couple of questions,

Does this filter work well if you add grain to a source ?
Yes; better than on the original grain, in fact. My test on artificial grain showed over a 40% bitrate reduction versus without the filter when on the normal grain it gave roughly a 30% bitrate reduction. With the improvements now I'm guessing the reduction could approach 50% depending on the source and settings.
Lastly, what codec do you recommend to use on a grainy source ?
Is x264, able to keep most of the grain, using (for example) a high quality profile ?Depends. With the GrainOptimizer plugin, x264 likely does a much better job than it normally would. Try it out, but make sure to compare to Xvid, which does a very good job on grain retention, though requires pretty high bitrates to do it.

Some other H.264 encoders (payware) have some various forms of grain optimization, also.

[Dark Shikari]

OK, did the test on 500 frames of Cruncher's footage at CRF 18. Denoised with Mocomp'd FFT3DGPU and then AddGrain(20,0.2,0.2)'d.

Result:

No GrainOptimizer: 18379kbps, 0.946 SSIM, 42.035 OPSNR.
GrainOptimizer(4,25,8,true,8): 12499kbps, 0.959 SSIM, 42.857 OPSNR.

[ChrisW77]

Yes; better than on the original grain, in fact. My test on artificial grain showed over a 40% bitrate reduction versus without the filter when on the normal grain it gave roughly a 30% bitrate reduction. With the improvements now I'm guessing the reduction could approach 50% depending on the source and settings.

Thanks for the quick reply. Sounds great.
I was thinking of removing the usual VHS noise with Fitz's excellent mvtools + mvdegrain, than adding some grain to the end of the script. It really works well on this particular piece, but I've never been able to capture the grain with a codec. Xvid, need far too much bitrate just to preserve some of it.

Depends. With the GrainOptimizer plugin, x264 likely does a much better job than it normally would. Try it out, but make sure to compare to Xvid, which does a very good job on grain retention, though requires pretty high bitrates to do it.

Yeah, cheers. I'll probably give x264 a go, probably at a bitrate of around 1500+.

[Dark Shikari]

Turns out there was a major bug with the chroma search that decreased efficiency. This has existed since the introduction of the chroma search but only manifested itself significantly with blocksize 8 (which by the way, proves to be "curiously" effective :) ). Fix will come tonight or tomorrow.

Edit: Perhaps I was premature on the 8x8 block bit. It seems that 8x8 blocks have an inherent problem--they're less effective at detecting very slight motion within the block. Example--if the block is at the border between a slightly lighter and slightly darker area, and the block shifts a pixel to the right due to motion, you'll notice the artifact if the block is retained, so it shouldn't be retained. With an 8x8 block, the amount of area the border covers is 2x larger... but the block is 4x larger, so its "half as good" at detecting the movement. The only way to resolve this IMO is... yet another heuristic, of some sort, that would deal with the issue. 8x8 blocks do give a valid benefit--somewhat more efficient B-frame coding--but until this problem is fixed they're basically useless IMO.

[cestfait]

WOW!! :eek: This filter has SERIOUS potential! I was just noticing how LESS denoised clips are often better compressed than smooth ones with x264. Guess it's just a matter of optimization!

However, I have a problem: In certain dark or flat areas, entire blocks seem to "ghost" in a strange way (similar to problems I have had with high AQ strength and low sensitivity). Here are some screenshots of the animated source I discovered this bug with (although it shows up in other ones I have tried, as well).

Original:

http://img155.imageshack.us/my.php?image=originaliq3.png

With Artefacts:

http://img148.imageshack.us/my.php?image=blockghostinglv1.png

[Yes, I accidentally let it crop and resize the artefacted clip, but I'm pretty sure that's not the problem. Anyway, see below script:]

The problem persists even on lower settings ("grainoptimizer(4,1,1,false)"), although I used defaults for this example. The script for the example was:

LoadPlugin("C:\Documents and Settings\Adam\Desktop\yatta\plugins\dgdecode.dll")
LoadPlugin("C:\Documents and Settings\Adam\Desktop\grainopt.dll")


function Preset0(clip c) {
#Name: Default
c
grainoptimizer(4,8,6,false)
return last
}

DGDecode_Mpeg2Source("C:\Documents and Settings\Adam\Desktop\haibane 01\haibane.d2v")


PresetClip0=Preset0()

PresetClip0.Trim(0,41229)


Crop(10,6,-6,0)
Spline36Resize(704,480)

Another thing I have noticed is that when I preview a frame in YATTA, the frame does not have any artefacting unless I move a few more preview frames in. The problem still shows up in the encode, though.

This filter looks like a wonderful idea, and I would love to start using it on a regular basis! Any idea what could be causing this problem?

EDIT: I was using 1.2, by the way.

[Dark Shikari]

Can you upload a short clip of your original source for me to test on? Use Mediafire if you need a hosting site. I love to find clips where the filter fails--its the best way to improve it :)

The reason that it doesn't show up in YATTA is because the filter is sequential--that is, if you call it on an arbitrary frame, it does nothing; it only does anything if its called for many frames in sequence.

The only way to avoid this would be to call the function recursively in the code, which would be a TERRIBLE idea.

[cestfait]

Wow! That was one hell of a fast reply! :) Forgot to add that I had also tried to MoComp with DePanEstimate, which failed. Then again, I had no idea why I was doing it; just thought I would poke my nose into areas of encoding that I don't understand...

Here's another little something I can't quite make out: How can I cut up my VOB to upload to you?

[Dark Shikari]

Wow! That was one hell of a fast reply! :) Forgot to add that I had also tried to MoComp with DePanEstimate, which failed. Then again, I had no idea why I was doing it; just thought I would poke my nose into areas of encoding that I don't understand...

Here's another little something I can't quite make out: How can I cut up my VOB to upload to you?I think VobBlanker can do it?

[Boulder]

Or simpler: use DGIndex to select a small range, then choose "save project and demux video". You'll get a demuxed m2v file out of that.

[cestfait]

Ok, the clips are up. The "haibane_renmei_clip.m2v" has the ugliest artefacts, but the artefacts manifest in a bunch of... creative... ways in the "mononoke-hime_clip.m2v". I especially think that you should note the panning shot of the ironworks and, right at the end, the shot of the group walking toward the camera. The whole frame shakes there, for the most part... freaky!

Mononoke:

http://www.mediafire.com/?5veythzwdi3

Haibane:

http://www.mediafire.com/?d9fhn1eumlg

[Didée]

Is this filter now safe to use, or will Didée show us some more bad examples? =P
Well, I didn't want to appear as an old nagger who makes everything seem bad, so I waited a while. ;)

v1.2 of GrainOptimizer is a good improvement over the previous versions. Still, issues are not difficult to find.

Perhaps, so far it seems fine (Didee's sample clip works fine for me with the new version at 4,25,8,true,8, for example).
Can't agree, sorry. "Fine" is something else, definetly. Did you try all the samples, or just one or two?

snip1 - no blocking artefacts. (*)
snip2 - artefacts on Mollari's forehead, and in the background when there is slow movement. Scene is degraded.
snip3 - no blocking artefacts. (*)
snip4 - mostly good. At the end of the sequence, there is the "static-curtain" effect on Garibaldi's face.
snip5 - some small artefacts, but visual appearance is good.
snip6 - there appear some bad blocking artefacts on the light beams.
snip7 - blocking / wrong block freezing of the slowly moving textures. A major degradation of the scene, inacceptable.

(*) on these scenes, the "slowing" of the grain in fact is very annoying to my eyes. Instead of the constant deviation of the original grain, there is a "blinking" effect created due to the grain freezing.

My temporary conclusion: for sources with stronger grain like this here, the filter is not well suited:
- when there is grain, I don't like the effect. Somehow reminds me of an encode that suffers bitrate.
- when there is no grain, the filter is still not safe against producing artefacts.
- when the filter mistakes (texture+motion) for grain, the resultant effect is particularly poor.


Regarding bitrate reduction - average over all seven test samples @ q18:

source: 100%
default, strength=08: 88.0% (-12.0%) - slightly degraded
default, strength=16: 84.5% (-15.5%) - slightly more degraded
default, strength=25: 83.0% (-17.0%) - noticeably degraded. Partly OK, partly unacceptable
default, strength=50: 80.4% (-19.6%) - seriously degraded, unacceptable
default, strngth=100: 79.3% (-20.7%) - seriously degraded, unacceptable

A link to the used test samples is in this post (http://forum.doom9.org/showthread.php?p=1051972#post1051972).

For the interested, here is a RAR archive to download (http://maxupload.com/8AC2CAB2) (30MB) that includes:

- source directly encoded at q18
- encode of GrainOptimizer(4,25,8,true,8) at q18

and for comparison:

- encode of a thorough grain remover (WIP snapshot) at q18. Overall bitrate reduction: 45%. (60%-80%% on strong-grain sequences).

[cestfait]

Could any insight be drawn from anyone's knowledge of the AQ patch for x264? For sources without much grain (including the ones I posted), high strengths had a tendency to produce similar lagging or jerking effects, although they did not take the shape of blocks.

[Dark Shikari]

As a result of your clip I made some huge changes to the code, changing a lot of the algorithms and hopefully making it a lot better--and best of all, you don't need to specify the strength anymore--it'll automagically find the correct strength per frame.

The downside is that now, though the result is more accurate, you need a denoised clip as input for the filter.

Improvement with artificial grain using AddGrain():

http://i24.tinypic.com/11smhdg.png

[cestfait]

WOWZER! :eek:

Nice changes! *goes off to test*

By the way, what do you mean by "denoised," to begin with? How [much] denoised? (fft3d, I assume, maybe mocomped, but settings?)

Would you mind posting an example script with the full chain beginning with "denoising" and adding grain and finally your filter?

Thanks again, and good luck on your other new projects (although I think this one is the most groundbreaking :) )

Edit: wow, I'm slow... just got that... still wouldn't mind an example, though.

[buzzqw]

yes, an example and a more accurate readme.txt in zip is more then welcome :D

BHH

[Manao]

How to you compute quality improvments ? If you use the SSIM figure at the end of the encoding process, it's completely bogus since you changed the source...

[Dark Shikari]

How to you compute quality improvments ? If you use the SSIM figure at the end of the encoding process, it's completely bogus since you changed the source...The point of the "quality" measure is that since the filter doesn't change the data in a spatial manner, each frame is individually just as hard to encode as the original, and therefore a higher SSIM means that you could lower the bitrate and achieve the same quality, ignoring the quality change caused by the filter. Basically its making the assumption that the quality change caused by the filter is already considered "acceptable" and is not quantifiable.

This wouldn't be valid for an ordinary denoiser, for example; using fft3dfilter one can easily get 0.99 SSIM at half the bitrate of 0.95 SSIM without denoising, but most of the "lost quality" in the original encode is because of the grain not being flawlessly retained, and therefore that detail is lost, lowering the SSIM. Since the GrainOptimizer, ideally, doesn't remove any grain spatially, this shouldn't be a problem.

Basically the assumption is that the filter does not change the source in a negative manner, or that if it does, it is not quantifiable and is assumed that the user of the filter has no problem with it.

The "quality" measure is not meant to measure deviation from the source--rather its meant to hopefully approximate visual quality relative to what is assumed to be a flawless input. This assumption is invalid if the user dislikes the change in the grain (in which case they shouldn't use the filter!) or if the filter causes spatial artifacts (which it shouldn't, but might).

Anyways, if you don't like the quality aspect of the graph, ignore it and just look at the bitrate aspect--but in my experience it is accurate, as making the grain "easier" to encode results in x264 retaining more of it, increasing quality.

[burfadel]

How do you actually use the new filter? it doesn't seem to work!

If you just put in:
Grainoptimizer()

It comes up with:
Evaluate: System Exception - Access Violation

A few examples on the proper usage would be greatly appreciated!

If you really do need a pre-denoised clip as a reference, and the grainoptimiser after the denoiser, then I'd like to suggest adding another fuction (predenoise will be used in this example), to simplify the process such that: (the dots are commands or a seriouis of commands, <resizer> is your chosen resizer, <denoiser> is your chosen denoiser)
.....
<resizer>
Grainstore()
<denoiser>
Grainoptimizer<>
.....

The purpose of the grainstore command would be just to store the pre-denoised clip in memory, then the grainoptimiser command can work its magic from the avisynth input and the frame stores in memory. This is a more simplistic way I think, and would be easy for anyone to understand how to use.

[Didée]

The syntax is not that difficult:

-----
o = YourSource
d = o.YourDenoiser()

GrainOptimizer( o, d, [parameters] )
-----

[cestfait]

:script:

yeah, I hate to harp on this point, but a sample script with specific filters and motion compensation techniques would be really nice. what kind of a script allows the filter to reference a suitably denoised clip for each frame?

I can imagine referencing a depan/fft3d/ttemporalsoften chain getting pretty arabesque...

EDIT: oops, didée slipped in afore me. still wouldn't mind the creator's feelings on the specific denoisers though... personally, I'm inclined just to do a really strong motion compensated temporalsoften or fluxsmooth for a reference clip...

[Dark Shikari]

Here's a very simple script:

SetMemoryMax(128)
clip1=DirectShowSource("300.divx").ConvertToYV12()
LoadPlugin("GrainOpt.dll")
clip2=clip1.fft3dgpu(sigma=3,bt=3).TTempSmooth(maxr=3,strength=4)
clip1.GrainOptimizer(clip2)

I should add an error catching feature to return an error if a second clip isn't given in the argument (i.e. using GrainOptimizer() instead of GrainOptimizer(clip2) ).

[cestfait]

:thanks:

Cheers! (until the next bug.... just kidding?)

Good work!!!

[squid_80]

I should add an error catching feature to return an error if a second clip isn't given in the argument (i.e. using GrainOptimizer() instead of GrainOptimizer(clip2) ).

Leave required parameters unnamed in the AddFunction call and avisynth will do the error catching for you. For example instead of:
env->AddFunction("GrainOptimizer", "[clip]c[denoisedclip]c[BlockSize]i[strength]f[tdist]i[minrep]i", Some_function, 0);
/* I guess this is what it looks like? */
You want something like this:
env->AddFunction("GrainOptimizer", "cc[BlockSize]i[strength]f[tdist]i[minrep]i", Some_function, 0);
/* any parameters that don't have default values *
* should be unnamed too */

[Boulder]

v2.0 crashes VDubMod almost immediately.

My script:
mpeg2source("test.d2v",cpu=4)
denoised=temporalsoften(2,5,5,8,2)
grainoptimizer(denoised)

[Dark Shikari]

v2.0 crashes VDubMod almost immediately.

My script:
mpeg2source("test.d2v",cpu=4)
denoised=temporalsoften(2,5,5,8,2)
grainoptimizer(denoised)Let me guess, denoised isn't YV12?

Also, how do I check the colorspace of the second clip given to me? Such checking doesn't seem to be in the SimpleSample code.

[Didée]

Boulder found something. Seems like it crashes if TemporalSoften is the last filter that processed the 'denoised' clip.

Crashes Always:
a = last
b = AnyOrNoFilter().Temporalsoften(..)
GrainOptimizer(a,b)

Always works:
a = last
b = Temporalsoften(..).AndAnotherFilter()
GrainOptimizer(a,b)

Until the cause is found, TemporalSoften(..).RemoveGrain(0) is a very fast workaround.

[Razorholt]

I have no problem with the following code:
clip1=DGDecode_mpeg2source("C:\Videos.d2v",info=3)
clip1 = clip1.colormatrix(interlaced=true)
clip1 = clip1.yadif()
clip1 = clip1.ConvertToYV12()
denoised = clip1.temporalsoften(2,5,5,8,2)
grainoptimizer(denoised)

[Boulder]

The colorspace is YV12, a regular DVD source. In fact, using MVDegrain2 or RemoveGrain(mode=0) alone for "denoised" also crash.

I'm using the latest Avisynth 2.5.8 alpha, all the other filters are working fine. My CPU is a Northwood P4 (MMX/SSE/SSE2 support), could this be another issue with CPU-specific code?

[Didée]

Razorholt: Exactly like you posted it, your script cannot work at all. You missed to deliver 'clip1' as input clip to GrainOptimizer, hence 'denoised' is interpreted as input clip, hence the 'denoised' clip is missing and an error (should) be thrown.

Boulder: Can't confirm. While I don't trust my crappy Celeron 100% on some things, RemoveGrain(x) does work, including x=0. MVDegrain2 works also, as does FluxSmooth, as does FFT3DFilter, as does DegrainMedian. That's the ones I tested. TemporalSoften for me is the only one that forces the crash:

src = mpeg2source("test.d2v")

vbw2 = src.MVAnalyse(isb=true, delta=2,idx=1)
vbw1 = src.MVAnalyse(isb=true, delta=1,idx=1)
vfw1 = src.MVAnalyse(isb=false,delta=1,idx=1)
vfw2 = src.MVAnalyse(isb=false,delta=2,idx=1)

nr = src
#nr = nr.MVDegrain2(vbw1,vfw1,vbw2,vfw2,idx=1) # works
#nr = nr.FFT3DFilter(sigma=4,bt=3) # works
#nr = nr.removegrain(0) # works
#nr = nr.DegrainMedian(mode=2) # works
#nr = nr.fluxsmoothst(20,2) # works
#nr = nr.temporalsoften(2,5,5,8,2) # -fails-

src.grainoptimizer(nr)

[Boulder]

I'll try downgrading Avisynth when my latest project finishes some time tomorrow. Opening a script with "last" fed in Grainoptimizer as the denoised clip crashes too. MPC shows a system exception - access violation error, address 0x0 reading from 0x0. Not much help there I think.

[Dark Shikari]

Question: for two YV12 clips with the same width and height, are there any values (pitch, etc) that can possibly differ between them?

[Manao]

Everything except width, height and colorspace can differ. Moreover, pitch can change from frame to frame.

[Razorholt]

Razorholt: Exactly like you posted it, your script cannot work at all. You missed to deliver 'clip1' as input clip to GrainOptimizer, hence 'denoised' is interpreted as input clip, hence the 'denoised' clip is missing and an error (should) be thrown.


Yes, I forgot clip1 in the last line. Now I get the error that you're talking about ... :(

[Dark Shikari]

Try this version (http://www.mediafire.com/?dotjnxysp3x) and see if it fixes the crashing.

[Razorholt]

Nope. Still crashing.

[Boulder]

Doesn't work here either :(

[burfadel]

Doesn't work here either, only for mpeg2source when there's editing involved (so virtualdubmod is used). Thought I had it working on a test clip, but can't get it to work again. I had used:

clip1=MPEG2Source("%source_file%").converttoyv12()

[Razorholt]

Have you managed to encode anything with your setting? I can load fine but the error occurs a few seconds after I launch the encoding. Do you mind posting your entire script?

Cheers.

[burfadel]

I don't know why it worked just that once, it didn't work the second time I tried, everything was exactly the same.

The grainoptimizer filter works with everything, its only when virtualdubmod loads to cut the wav file. I hope its a bug in the filter (sorry Dark Shikari) and not virtualdubmod, as virtualdubmod isn't updated/maintained any more and hasn't for 2 years.

There is a virtualdubmod mod :) by audx based on 1.6.0.0, still a very old version, that works as a replacement for virtualdubmod but still has the same problem in regards to the wav files.

I loaded the script in virtualdub-mpeg2 (which doesn't have all the required features of virtualdubmod to work in its place), and the video loaded fine with the filter! (with the picture in the panes etc etc) I assume when loading the script with the filter set up in it that virtualdub loads the filter too, which is why its causing the crash even though its only dealing with the audio. If loaded in virtualdubmod there is no picture! So is the crash caused by a bug in the filter that disagrees with virtualdubmod, or a bug in virtualdubmod/virtualdub (that has since been fixed) but is of no benefit unless an updated virtualdubmod and patches is released?

The same problem occurs with the main 2.0 release and the release 2.01 as referenced earlier.

[burfadel]

I found Temporalremovegrainhd is a good filter that apparently also temporally (temporal wise lol) removes noise, part of the removegrainhd filter. Even at default values. That filter has to be put in the right spot otherwise it crashes though (well the x264 outputs an almost empty file).

For Mpeg2 with a resizer I have to put it after crop but before resizer, and for avi where no resizer after crop. Weird I know but its a good filter to use until grainoptimiser is fixed. Mind you, it removes grain and not optimises it, so it does have a slightly different purpose. Quality is good though, as is the file reduction size. Haven't tried it with heavy noise.

[Razorholt]

Trying Temporalremovegrainhd (http://home.pages.at/kassandro/RemoveGrainHD/RemoveGrainHD.htm) right now. Thanks for the tip, burfadel.

[burfadel]

Trying Temporalremovegrainhd (http://home.pages.at/kassandro/RemoveGrainHD/RemoveGrainHD.htm) right now. Thanks for the tip, burfadel.

How did it work for you?

[Dark Shikari]

Yeah, I've been somewhat busy the past day or two; I'll see if I can fix it this weekend.

[hristoff2]

"There is no such function.." (avisynth 'plugins' dir)
LoadCPlugin / LoadPlugin = Don't work (can't open)
v2.0

Unfortunately this doesn't make any sense, can't use the filter on my 2nd pc which is almost identical to the computer where I'm writing this.
I'm posting this just in case someone had this weird error and found a weird solution..

[salehin]

"There is no such function.." (avisynth 'plugins' dir)
LoadCPlugin / LoadPlugin = Don't work (can't open)
v2.0

Same here... it was working with the previous edition of version 2:)

[Leak]

I'd hazard a guess you're missing this (http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en)...

[Razorholt]

@burfadel : It's a pretty clever filter. It reduces the file size without degrading the picture too much, like other denoisers.

@leak: what's your success rate with GrainOptimizer? Are you having the same issue that most of us have?


Thanks,
- Dan

[Terranigma]

@burfadel : It's a pretty clever filter. It reduces the file size without degrading the picture too much
There's denoisers out there that can greatly reduce the file size as well without degrading the picture quality at all (if you know how to use them properly, and know which ones can do this). ;)

[CruNcher]

hmmm any idea what is wrong here ?


grain=ffmpegsource("grain.m2v")
watter=ffmpegsource("G:\watter.m2v")
black2=ffmpegsource("G:\black2.m2v")
action=ffmpegsource("G:\action.m2v")
black1=ffmpegsource("G:\black1.m2v")
black3=ffmpegsource("G:\black3.m2v")
final=grain+watter+black2+action+black1+black3
source=final.autocrop(wMultOf=16,hMultOf=8,0).trim(500,550)


#### (1)
#clip2=source.RemoveGrain(mode=0, modeU=0, modeV=0).FFT3DGPU(sigma=5,plane=3,precision=0)
#source.GrainOptimizer(clip2)

#### (2)
#clip2=source.RemoveDirt(false).FFT3DGPU(sigma=5,plane=3,precision=0)
#source.GrainOptimizer(clip2)


both sections endup in the same result (not expected) ???

removing the clip2= and source.GrainOptimizer(clip2) gives different files (expected)

it almost looks like it would ignore all the things after the clip2=source. (and jump to the source=final) hmmm should it do that ?

PS: Im sure im doing something wrong here :P

[Dark Shikari]

There's denoisers out there that can greatly reduce the file size as well without degrading the picture quality at all (if you know how to use them properly, and know which ones can do this). ;)They can, but they remove the grain--the point of this filter is to reduce file size without getting rid of film grain (and it works even after a normal denoiser, though its less effective).

As I said, I'll try to find the problem this weekend.

[Raere]

I'm a little confused here, and haven't really tried it yet. It reduces filesize, meaning that you can increase the bitrate and still hit the same filesize? So, basically free bitrate increasing?

[Boulder]

The bitrate will remain the same because (bits per second) * (length of the source in seconds) will determine the filesize you want to hit. Using a grain remover/optimizer, the encoder just doesn't need to use as high quantization levels to achieve that filesize. One could consider it "less aggressive compression".

[Shinigami-Sama]

I'm a little confused here, and haven't really tried it yet. It reduces filesize, meaning that you can increase the bitrate and still hit the same filesize? So, basically free bitrate increasing?

say you've got a bunch of towels
you can just try and jam into the closet(bitrate) and you have to squish them hard to get them to fit, this might mess up their shape a little(lower quality)

now if you take those same towels and fold them, they fit, and with a little room left over(less bitrate needed for the same quality)

thats what this filter does the grain, shuffles it into better spots

dark can correct me if I'm wrong

[burfadel]

Depends on the mode used :) thats true for CBR & ABR modes only. To over simply it, the encoder can concentratrate more bitrate on picture detail and not grain detail, so for these two modes the result should be a higher quality image when typical bitrates are used.

For a constant quality/quantiser mode, the bitrate will drop, possibly significantly, as less information is needed to be encoded to achieve the same perceptual quality.

[woah!]

well i have tried this on alot of different clips and havent seen any drop of bitrate or anything to be honest. i "think" i am doing the correct process.

i used Dark Shikari avs scripting above in my own to get it running ... i think..

src = DirectShowSource("L:\FEATURE1.EVO.grf",fps=23.976,framecount=80016,audio=false)+DirectShowSource("L:\FEATURE2.EVO.grf",fps=23.976,framecount=87638,audio=false)


nr = src.DegrainMedian(mode=3)
src.grainoptimizer(nr)

trim(73600,74400)
ConvertToYV12()

[burfadel]

You will only see a drop in bitrate if CRF or quantiser mode is used, what settings are you using for the encoder?

[woah!]

--crf 18 --me-prepass --threads auto --thread-input --qpmin 1 --mvrange 511 -b 2 --bime --weightb -r 3 --mixed-refs --direct auto -f -1:-1 -A "All" -8 --me esa -m 5 --fpel-cmp sad --no-fast-pskip --progress -o

[Leak]

@leak: what's your success rate with GrainOptimizer? Are you having the same issue that most of us have?
Success rate: NaN (division by zero, actually...)

I just took a look at the file to see which version of the VC runtime it needs, I didn't try it. :D

[CruNcher]

Ok found the problem the v 2.1 seems to be buggy v 2.0 (official) works at least gives a different final result for both sections

[burfadel]

Ok found the problem the v 2.1 seems to be buggy v 2.0 (official) works at least gives a different final result for both sections

2.1? I take it you mean 2.01?

[Dark Shikari]

Oh god, this is embarrassing. I found the main bug; it was fetching a write pointer instead of a read pointer :scared:

Try a new fixed version here (http://www.mediafire.com/?5zgnzmp49gl).

[burfadel]

Well, um, at least you found a bug!

The problem is still occurring with Virtualdub audio (wave file) cutting as before, which is found in edited tv programmes. I did a quick try with a dvd vob cutting (which is AC3 cutting) and it seems to work fine.

[Dark Shikari]

Well, um, at least you found a bug!

The problem is still occurring with Virtualdub audio (wave file) cutting as before. I did a quick try with a dvd vob cutting and it seems exempt, it seems only to occur in my case, with TV recordings.What problem are you referring to? I'm referring to the crashing with TemporalSoften :)

[burfadel]

I'm talking about the Virtualdub crash upon audio editing :) It just doesn't like the grainoptimizer filter! With every other filter etc there aren't any problems. Other people have had the same problem too, on page 6 :). I think its a separate issue?

[Boulder]

v2.01 works now on my system, no VDub crashes anymore.

[burfadel]

v2.01 works now on my system, no VDub crashes anymore.

What type of file were you encoding? was it dvd or tv?

It works fine with me with DVD, its only TV source where its using mp2 (so cuts a wave file) that is the problem that I'm having :)

[burfadel]

Here's a very simple script:

SetMemoryMax(128)
clip1=DirectShowSource("300.divx").ConvertToYV12()
LoadPlugin("GrainOpt.dll")
clip2=clip1.fft3dgpu(sigma=3,bt=3).TTempSmooth(maxr=3,strength=4)
clip1.GrainOptimizer(clip2)

I should add an error catching feature to return an error if a second clip isn't given in the argument (i.e. using GrainOptimizer() instead of GrainOptimizer(clip2) ).

I found the source of the problem I was talking about! The above example you had earlier was the cause. For AC3 audio etc it worked fine, but when editing a TV record that used mp2 sound, the mp2 audio is converted to a wav file, then cut by virtualdubmod. Virtualdubmod does not like the code syntax:
clip1=(source type, for example Mpeg2source)
clip2=clip1.(denoiser)
clip1.grainoptimizer(clip2)

I confirmed this as no matter what filter you put in place of grainoptimizer, it did not work, but ONLY in the situation of wav file cutting!

Instead, I changed the above syntax to:
(source type)
(other filters here, such as deinterlacer, resizer etc)
clip1=(denoiser)
grainoptimiser(clip1)

That works flawlessly, and is, in affect, exactly the same as the other code but more simplified... and the main point of working with virtualdubmod.

Sorry Dark_shikari if you were searching for the problem! I did use your example :) lol, it wasn't expected so its ok! Thanks for a great filter!

[Dark Shikari]

New version up; fixes blocking issues after scene changes caused by overzealous temporal denoisers. Thanks to Infernix for catching this bug!

[Razorholt]

Thanks Darky! However the link is not working... it says "File doesn't exist."

[Dark Shikari]

Thanks Darky! However the link is not working... it says "File doesn't exist."Damnit... blame jarod... I uploaded it earlier and it simply disappeared :scared:. I've put up a backup mirror.

[buzzqw]

would be ever possibile to make a version (2.xx) that works without a previus "cleaned" picture ? just for making it faster..

thanks!

BHH

[desta]

Can't load 2.02 in vdub, and can't download 2.01 - link doesn't exist. :(


edit: working fine now... human error. My human error! :sly:

[salehin]

I was wondering if there is any way I can optimise this encode further. Optmise in the sense that removing the grains and then reintroducing it later via grainoptmizer. Here, I'm assuming that grainOpt can retain grains at a relatively lower bitrate without costing too much on average qp or crf

MeGUI cmd line at crf 18.5:
--crf 18.5 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -3,-3 --subme 7 --trellis 1 --analyse all --8x8dct --me umh --threads auto --thread-input --cqmfile "C:\Program Files\megui\Custom Matrices\Prestige.cfg" --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input" --aq-strength 0.3

avs script:
SetMemoryMax(128)
clip1=dgdecode_mpeg2source("J:\temp\crf test.d2v",info=3).ColorMatrix(hints=true,interlaced=true).tfm(order=0).tdecimate(hybrid=1)

a=clip1.crop(2, 8, -2, -2)
clip2=a.DeGrainMedian(limitY=2,limitUV=3,mode=1) #DeGrainMedian(limitY=2,limitUV=3,mode=1)
#clip2.LimitedSharpenFaster(Strength=50).Spline36Resize(1280, 720)
GrainOptimizer(clip2).LimitedSharpenFaster(Strength=50).Spline36Resize(1280, 720)

I get the following quants
avis [info]: 1280x720 @ 23.98 fps (1472 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 Cache64
x264 [info]: slice I:13 Avg QP:17.54 size:121194
x264 [info]: slice P:608 Avg QP:19.55 size: 40153
x264 [info]: slice B:851 Avg QP:21.54 size: 11909
x264 [info]: mb I I16..4: 0.9% 95.9% 3.2%
x264 [info]: mb P I16..4: 0.1% 7.1% 0.3% P16..4: 56.6% 22.6% 11.7% 0.3% 0.1% skip: 1.2%
x264 [info]: mb B I16..4: 0.0% 0.4% 0.0% B16..8: 25.8% 1.1% 5.3% direct: 8.5% skip:58.8%
x264 [info]: 8x8 transform intra:94.9% inter:81.9%
x264 [info]: direct mvs spatial:98.4% temporal:1.6%
x264 [info]: ref P 55.5% 28.3% 6.5% 6.7% 3.0%
x264 [info]: ref B 69.6% 22.3% 3.8% 2.7% 1.6%
x264 [info]: kb/s:4707.0

Also, I can't seem to be able run version 2.02 properly- i have already installed the required msft tool. Only v 1.2 works. Please advise
[Setup OS: xp home SP2 | MeGUI: 0.3.1004 | Avisynth: 2.57]

Thanks :)

[Razorholt]

Install this: http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en

[salehin]

Thanks Razorholt. :)

I just installed that tool again- now v 2.02 works. Possibly it wasn't working due to some windows update or it simply wasn't installed properly. Did anyone have this problem?

[burfadel]

Thanks Razorholt. :)

I just installed that tool again- now v 2.02 works. Possibly it wasn't working due to some windows update or it simply wasn't installed properly. Did anyone have this problem?

Windows Update doesn't show all updates! it also doesn't show runtimes except for .NET. VS 2005 (and later, there's 2008 out now). This is one request that people have said to Microsoft but still they haven't added it. The other thing not added to Windowsupdate is the bimonthly Directx runtime updates, they have to be installed manually.

Also in their wisdom, service packs do not include new versions of Directx, WMP, IE, etc etc. They should at least have it as an option to install it when running the service packs.

Anyways, you didn't miss anything, unfortunately is just expected at times that people will find Directx etc by themselves! (from the microsoft download site etc.)

[squid_80]

If you read the VS docs, it says if you're going to link dynamically to the runtime libraries you should distribute either the libraries themselves with your app (typically requires an installer package) or link to their download page so it can be installed from there - again requires an installer if you want it done automatically, else you have to rely on the user reading the documentation you provide.

[Sasovics]

Folks,

I am trying to run GrainOptimiser, but every time I tried to load my avs script I am getting error message:

Script error: Invalid argumets to function "GrainOptimizer"
(I:\Video.avs, line 5)

My avs script is as follows (based on Salehin script found here (http://forum.doom9.org/showthread.php?p=1084695#post1084695)):


SetMemoryMax(128)
clip1=DirectShowSource("Untitled.grf", fps=23.976, framecount=165876, audio=false)
a=clip1.crop(0, 144, 0, -136)
clip2=a.DeGrainMedian(limitY=2,limitUV=3,mode=1)
GrainOptimizer(clip2).LimitedSharpenFaster(Strength=50).Spline36Resize(1280, 536)

What am I doing wrong here ??

fyi - I am using the latest GrainOpt.dll v 2.02

[salehin]

What am I doing wrong here ??
See here (http://forum.doom9.org/showpost.php?p=1084772&postcount=151)

[Sagekilla]

Salehin, that's not the issue here.

He's calling GrainOptimizer with the arguments GrainOptimizer(clip2,clip2) It's using the same clip for input and denoised clip, since any filter will take the last call as the input. Which, in this case, was clip2. Here's the proper filter chain:

SetMemoryMax(128)
clip1=DirectShowSource("Untitled.grf", fps=23.976, framecount=165876, audio=false)
a=clip1.crop(0, 144, 0, -136)
clip2=a.DeGrainMedian(limitY=2,limitUV=3,mode=1)
GrainOptimizer(a,clip2).LimitedSharpenFaster(Strength=50).Spline36Resize(1280, 536)

[Sasovics]

Thanks Sagekilla! As always! ;)

[salehin]

Salehin, that's not the issue here.
thanks for point out my mistake, sage. sorry for that

[Sagekilla]

thanks for point out my mistake, sage. sorry for that

Not a problem, may have well been both being a problem at once!

It's what we're here to do, help :)

[Sp00kyFox]

i've also got some strange lines with your plugin..

http://img341.imageshack.us/img341/4845/linesrp6.png

here is my script:

DGDecode_mpeg2source("C:\XFILES_DISC6\VTS_01_1.d2v",info=3)
ColorMatrix(hints=true,interlaced=true)
mcbob().selecteven()
crop( 2, 2, -14, 0)

clip=last
denoisedclip=fft3dgpu(sigma=4)
GrainOptimizer(clip,denoisedclip)

Spline36Resize(704,576)

am I doing something wrong or is it a bug in your plugin?

[Dark Shikari]

i've also got some strange lines with your plugin..

http://img341.imageshack.us/img341/4845/linesrp6.png

here is my script:

DGDecode_mpeg2source("C:\XFILES_DISC6\VTS_01_1.d2v",info=3)
ColorMatrix(hints=true,interlaced=true)
mcbob().selecteven()
crop( 2, 2, -14, 0)

clip=last
denoisedclip=fft3dgpu(sigma=4)
GrainOptimizer(clip,denoisedclip)

Spline36Resize(704,576)

am I doing something wrong or is it a bug in your plugin?My filter wasn't designed for interlaced video... though it seems you're deinterlacing...

That is very odd, and the kind of artifacting you're seeing doesn't even make sense to me... very weird.

I'm not really maintaining this plugin anymore--I'll probably post the code eventually and someone else can mess with it.

[Sp00kyFox]

jup I'm deinterlacing with mcbob so that shouldn't be the problem.
yes indeed - very weird oO
well I tested it again and the problem seems to lie in your filter.

[thetoof]

@Dark Shikari

I can't figure out which mode I should use when using this plugin with setmtmode()... since you wrote the code, do you know what would be the most appropriate mode?

Thx

[Dark Shikari]

@Dark Shikari

I can't figure out which mode I should use when using this plugin with setmtmode()... since you wrote the code, do you know what would be the most appropriate mode?

ThxI have no idea, since I have no experience with MTmodes.

Its far too fast a plugin to need MT though, I think. The bottleneck in speed will always be the external denoiser.

[LaTo]

i've also got some strange lines with your plugin..

http://img341.imageshack.us/img341/4845/linesrp6.png

here is my script:

DGDecode_mpeg2source("C:\XFILES_DISC6\VTS_01_1.d2v",info=3)
ColorMatrix(hints=true,interlaced=true)
mcbob().selecteven()
crop( 2, 2, -14, 0)

clip=last
denoisedclip=fft3dgpu(sigma=4)
GrainOptimizer(clip,denoisedclip)

Spline36Resize(704,576)

am I doing something wrong or is it a bug in your plugin?

I got the same problem with progressive video...

http://img84.imageshack.us/img84/6067/bugoi4.th.png (http://img84.imageshack.us/my.php?image=bugoi4.png)

Here is my script:
v0=directshowsource("D:\vid.GRF",convertfps=true,fps=23.976,audio=false)
a0=directshowsource("D:\aud.GRF",video=false)
audiodub(v0,a0)

crop(0,92,0,-92)

ulevels(preset="op",gamma=1.5)

src=last
sharp=src.fft3dgpu(sigma=0,sigma2=2,sigma3=2,sigma4=0,plane=1,bt=1,precision=2).limitedsharpenfaster(strength=120)
soothe(sharp,src,80)

ttempsmooth()
gradfun2db(1.2)

orig=last
grain=orig.addgrain(50,0,0)
grainoptimizer(grain,orig)

addborders(0,92,0,92)

spline36resize(720,576)

removegrain(1)
limiter()

[Chiba]

I got the same problem with progressive video...

http://img84.imageshack.us/img84/6067/bugoi4.th.png (http://img84.imageshack.us/my.php?image=bugoi4.png)


I've test it with interlaced videos and it's work great but, i've used something like :


MPEG2Source("Full.d2v",cpu=0,idct=4,iPP=true,showQ=false,fastMC=false,info=3)
colormatrix(hints=true)
tfm(d2v="Full.d2v")
tdecimate(mode=1)
crop(0,92,0,-92)
limiter()
Spline36resize(704,576)

src=last
sharp=limitedsharpenfaster(smode=1,strength=120)
soothe(sharp,src,15)

a=last
b=a.MT("frfun3b()",threads=2,overlap=8)
SeeSaw(a, b, Sstr=0.9, Szp=12, SdampHi=20, bias=40,ssx=1.7)

grainy=last.MT(filter="GradFun2dbmod(1.3)",threads=2,overlap=8)
clean=MT(filter="KenKunNR(180,2,10)",threads=2,overlap=8)
grainoptimizer(grainy,clean,tdist=9999)

MT("Ttempsmooth(maxr=4)",threads=4,overlap=8)

addborders(0,92,0,92)


I've no problem with film and animes ^^

Thanks for this great plug DarkShikari

[rkalwaitis]

DarkShikari

Here is what I tried. Although Im not totally sure that it is working the way it should. Although the image is pleasing to me.

# Set DAR in encoder to 87 : 35. The following line is for automatic signalling
global MeGUI_darx = 87
global MeGUI_dary = 35
DGDecode_mpeg2source("C:\Users\Kalwaitis\Desktop\Movies Done\Crossing Over\VTS_05_1.d2v", cpu=4, info=3)
ColorMatrix(hints=true, threads=0)
setmtmode(2)
smoothlevels(preset="tv2pc")
Deblock_QED(uv=3)
source=last
denoised=fft3dgpu()
#denoised=DeGrainMedian(limitY=2,limitUV=3,mode=1).DeGrainMedian(limitY=2,limitUV=3,mode=1)
superfilt=MSuper()
forvec1 = MAnalyse(superfilt,isb=false, delta=1, truemotion=true, blksize=16, overlap=8, pelsearch=2, search=3, searchparam=2, DCT=0, global=true, chroma=false,sadx264=0)
forvec2 = MAnalyse(superfilt,isb=false, delta=2, truemotion=true, blksize=16, overlap=8, pelsearch=2, search=3, searchparam=2, DCT=0, global=true, chroma=false,sadx264=0)
forvec3 = MAnalyse(superfilt,isb=false, delta=3, truemotion=true, blksize=16, overlap=8, pelsearch=2, search=3, searchparam=2, DCT=0, global=true, chroma=false,sadx264=0)
bacvec1 = MAnalyse(superfilt,isb=true, delta=1, truemotion=true, blksize=16, overlap=8, pelsearch=2, search=3, searchparam=2, DCT=0, global=true, chroma=false,sadx264=0)
bacvec2 = MAnalyse(superfilt,isb=true, delta=2, truemotion=true, blksize=16, overlap=8, pelsearch=2, search=3, searchparam=2, DCT=0, global=true, chroma=false,sadx264=0)
bacvec3 = MAnalyse(superfilt,isb=true, delta=3, truemotion=true, blksize=16, overlap=8, pelsearch=2, search=3, searchparam=2, DCT=0, global=true, chroma=false,sadx264=0)
#denoised =MDegrain3(superfilt,bacvec1,forvec1,bacvec2,forvec2,bacvec3,forvec3,thSAD=300, thSCD1=400, thSCD2=100, plane=4, limit=200)
denoisedclip=MDegrain3(superfilt,bacvec1,forvec1,bacvec2,forvec2,bacvec3,forvec3,thSAD=400, plane=4, limit=200)
#denoised =MDegrain2(superfilt,bacvec1,forvec1,bacvec2,forvec2,thSAD=400, thSCD1=400, thSCD2=135, plane=4)
return denoised.crop( 0, 64, 0, -64)
source.grainoptimizer(denoisedclip,tdist=18)

lsfmod()
GradFun2DBmod()


any suggestions are welcomed. Also I can not find the setting examples for the plugin. Could you please point me in the right direction.

Thanks

[Adub]

Although the image is pleasing to me.
Then you are done. Don't question the little graces in life.

[tormento]

@ Dark Shikari

Incredibly enough I have just discovered this plugin. Any version news?

[Dark Shikari]

@ Dark Shikari

Incredibly enough I have just discovered this plugin. Any version news?No, it was a bad idea to begin with and I wrote it when I was still a clueless newbie ;)

If I wrote something similar again, it would work very differently.

[Terka]

and would you?

[osgZach]

There are no bad ideas, only bad implementations ;)

Just came across this myself.. So now I have to play around with it :p

[tormento]

I'm digging this thread up as I love this plugin, even if it was a bad idea to begin with ;)

Please, DARK SHIKARY, give us a newer version!

[LaTo]

I'm digging this thread up as I love this plugin, even if it was a bad idea to begin with ;)

Please, DARK SHIKARY, give us a newer version!

Yes, it would be great to fix the old "crop" bug...

OK:
src=last
den=src.FFT3Dgpu()

GrainOptimizer(src,den)

CRASH:
crop(8,4,-2,-6)

src=last
den=src.FFT3Dgpu()

GrainOptimizer(src,den)

BUG: (see the screenshot)
crop(16,16,-16,-16)

src=last
den=src.FFT3Dgpu()

GrainOptimizer(src,den)

http://img84.imageshack.us/img84/6067/bugoi4.th.png (http://img84.imageshack.us/my.php?image=bugoi4.png)

[tormento]

I use DGNVTools and the crop bug doesn't appear...

[Gser]

This looks ideal for Firefly. Now I just need a blu-ray drive :(

[tormento]

Dark Shikari, even if your plugin is bugged, old and anything else ;) could you please provide us a x64 test version? ;)

Thanks.

[sonu patel]

Grain Optimizer v2.02 downlaod fillter link is dead plz update it ....