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

Dark Shikari · 7th October 2007, 20:54

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

Ebobtron · 7th October 2007, 21:38

@Dark Shikari

Thank you,
With current version VirtualDubMod and FilmCutter start and id funcition names correctly.

@squid_80

Quote:

Originally Posted by squid_80

If so I'd suggest ditching the compression.

Do you have time to describe the relevant issue with the compressed version of the dll ?

Mtz · 8th October 2007, 01:28

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 · 8th October 2007, 02:05

Quote:

Originally Posted by 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

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

rfmmars · 8th October 2007, 03:48

Quote:

Originally Posted by Dark Shikari

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 · 8th October 2007, 04:02

Quote:

Originally Posted by Ebobtron

@@squid_80

Do you have time to describe the relevant issue with the compressed version of the dll ?

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 · 8th October 2007, 04:06

Quote:

Originally Posted by rfmmars

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

Yup, 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 · 8th October 2007, 05:18

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 · 8th October 2007, 05:57

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 · 8th October 2007, 06:18

Quote:

Originally Posted by burfadel

- 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 · 8th October 2007, 10:35

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

normal, "optimized"

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

Dark Shikari · 8th October 2007, 15:24

Quote:

Originally Posted by ToS_Maverick

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

normal, "optimized"

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

That 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 · 8th October 2007, 15:29

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 · 8th October 2007, 15:33

I can attest to this as well.

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 · 8th October 2007, 15:57

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 · 8th October 2007, 17:55

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.

enjoy,
Mtz

Dark Shikari · 8th October 2007, 18:03

Quote:

Originally Posted by 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

4x4 blocks.. can you please upload the source? I'll need to update my heuristic to fix this.

Dark Shikari · 8th October 2007, 18:13

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 · 8th October 2007, 18:40

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

ToS_Maverick · 8th October 2007, 19:04

@Dark Shikari:
here is a still active link 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.

8th October 2007, 05:57	#29 \| Link
burfadel Registered User Join Date: Aug 2006 Posts: 2,229	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! Last edited by burfadel; 8th October 2007 at 05:59. Reason: Correction

8th October 2007, 15:29	#33 \| Link
ToS_Maverick x264 Tester Join Date: Dec 2005 Location: Austria, near Vienna Posts: 223	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 Last edited by ToS_Maverick; 8th October 2007 at 15:35.

8th October 2007, 15:33	#34 \| Link
Terranigma Space Reserved Join Date: May 2006 Posts: 953	I can attest to this as well. 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? __________________ Kurama Link And Fox Doom10 - It's brighter on the other side

8th October 2007, 18:40	#39 \| Link
Sagittaire Testeur de codecs Join Date: May 2003 Location: France Posts: 2,484	Encoder like VC1 PEP or Cinevision encoder use particular HVS masking filter for grain: spatial/temporal filtering in dark area. __________________ Le Sagittaire ... ;-) 1- Ateme AVC or x264 2- VP7 or RV10 only for anime 3- XviD, DivX or WMV9

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

7th October 2007, 20:54	#21 \| Link
Dark Shikari x264 developer Join Date: Sep 2005 Posts: 8,666	Non-mod16 now supported. The algorithm just doesn't act on the extra pixels, simple as that.

8th October 2007, 01:28	#23 \| Link
Mtz Registered User Join Date: Sep 2003 Location: On The Beach Posts: 714	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

8th October 2007, 05:18	#28 \| Link
Dark Shikari x264 developer Join Date: Sep 2005 Posts: 8,666	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

8th October 2007, 10:35	#31 \| Link
ToS_Maverick x264 Tester Join Date: Dec 2005 Location: Austria, near Vienna Posts: 223	i tested your filter with the suggested settings from above and got some artifacts: normal, "optimized" in the first example some horizontal lines got introduced, in the second example the background get's "optimized" away

8th October 2007, 15:57	#35 \| Link
Dark Shikari x264 developer Join Date: Sep 2005 Posts: 8,666	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?

8th October 2007, 17:55	#36 \| Link
Mtz Registered User Join Date: Sep 2003 Location: On The Beach Posts: 714	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. enjoy, Mtz

8th October 2007, 18:13	#38 \| Link
Dark Shikari x264 developer Join Date: Sep 2005 Posts: 8,666	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.

8th October 2007, 19:04	#40 \| Link
ToS_Maverick x264 Tester Join Date: Dec 2005 Location: Austria, near Vienna Posts: 223	@Dark Shikari: here is a still active link 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.