VagueDenoiser 0.35.1: a 2D Wavelet denoiser/smoother

[Fizick]

V0.31
Added noise ratio parameter for Wiener pass.
Fixed interlaced mode. Seems it now work.
3DNow mode of Qian thesholding temporary replaced by SSE or C versions.

[Lefungus]

Thanks for your updates Fizick !

About my adaptative thresholding part, i dropped it due to unsatisfying results.

[Fizick]

My implementation of automatic thhsholding is also simply experimental.

[Kurosu]

Originally posted by Fizick
Kurosu! I am glad to see you !
Thanks :)

EDITED: Seems, Brislawn 9/7 is popular CDF 9/7 wavelet (A. Cohen, I. Daubechies, and J. C. Feauveau)
I do not know what is used in "Wavelet 9/7 codec". Thanks for link.
Yes, that's the one used in the lossy part of JPEG-2000.

It is possibly, that some new wavelet types can give better results (coiflets etc). It is still researched.
There are a bunch of wavelets to choose from, depending on their abilities. I don't know what wavelet that would work in the current frame work. For instance, the "wavelet transform modulus maxima" method is well-known for its ability to separate details, but can't be used directly here (and I would say, not easily).

But seems, I have not any difference in speed not with 3dnow not with SSE (probably due to slow SDR memory for Athlon XP 2400).
Anybody can post some speed results with 0.29 and 0.30 (for various settings)?
I always found better results with 3DNow! than SSE with my Athlon Barton 2800 (DDR333). I even found that in some situations, the SSE part was horribly slower, maybe due to a mix of bad pairing and lack of proper prefetching.
Overall though, videos that are MOD64 (like 512 or 640) takes a huge stall somewhere in the filter. I don' recall well where, but that's why I suggested to filter before resizing. Maybe it decreases the speed difference in your case.

4. 3DNow mode of hard thesholding simly not works (null transform) for my compiled source of original version 0.29. I try VC6 and NASM 098. Released binary 0.29 works O.K.
You must look to it (not my 0.30 version, but enough original 0.29).
*must* ? ;)

Yes, "filter(...) was a comment! I spend a lot of time until see it.:confused:
Well, releasing the source code is really not a hacker protection :p
No, I simply guess that was left from my in-between experiment on localized/in-place transform (the actual code is really bandwidth-hungry, I guess it's now the main limitation).

Anyway, I *did* fix all modes you reported as broken. I also fixed an annoying warning with the rodata section of the assembly objects. You can have get the fixed asm files from here (http://kurosu.inforezo.org/avs/filter.zip)

[Fizick]

Anyway, I *did* fix all modes you reported as broken. I also fixed an annoying warning with the rodata section of the assembly objects. You can have get the fixed asm files from here
O.K., one of us *must* ;) incorporate it to new version.

the actual code is really bandwidth-hungry, I guess it's now the main limitation
There are a bunch of wavelets to choose from, depending on their abilities
What about speed, MAY BE more fast would be using wavelets with integer (rational) coefficients (5/3 etc) with scaling, and using not float, but integer calculation. But it is full rewriting of the code.

And the last note (to all). Vaguedenoiser uses fast decimated wavelet transform. It is not shift-invariant. Therefore, if we shift image and apply filter, and re-shift backward, the result we be different from
sipmly apllying th filter. More precisely, the main features will be same, but some small details will be different. In particular, some artefactes will be also different. It may be used for improving the result by combining two (or more) images with Layer command.
It will be partially equivalent to undecimated wavelet transform.

Similar method is used by Didée for deblocking of Dust results.

AVIsource("h:\makar.avi")
loadplugin("masktools.dll")
loadplugin("vaguedenoiser.dll")

// some border mirror function motivated by Didée.

Function MirrorBottom( clip clp, int "v2" )
{
v2 = default( v2, 8 )
bot=clp.crop(0,clp.height-v2,-0,-0)
stackvertical( clp, bot.flipvertical() )
return last
}

Function MirrorTop( clip clp, int "v1" )
{
v1 = default( v1, 8 )
top=clp.crop(0,0,-0,v1)
stackvertical( top.flipvertical(),clp )
return last
}

Function MirrorRight( clip clp, int "h2" )
{
h2 = default( h2, 8 )
right=clp.crop(clp.width-h2,0,h2,-0)
stackhorizontal(clp,right.fliphorizontal())
return last
}

Function MirrorLeft( clip clp, int "h1" )
{
h1 = default( h1, 8 )
left=clp.crop(0,0,h1,-0)
stackhorizontal(left.fliphorizontal(),clp)
return last
}

converttoYV12()
input=crop(320,8,240,512) # for debug

# Shift image 2 pixels to the right and bottom
shifted=Crop(input,0,0,-2,-2).MirrorLeft(2).MirrorTop(2)
first=VagueDenoiser(input,threshold=27,method=0,nsteps=5,wavelet=1)
second=VagueDenoiser(shifted,threshold=27,method=0,nsteps=5,wavelet=1)
reshifted=Crop(second,2,2,-0,-0).MirrorRight(2).MirrorBottom(2)
sum=YV12layer(first,reshifted,"add",level=128)
stackhorizontal(input,first,reshifted,sum) # to see all


The summary result (and speed :( ) is similar to Wiener method.
See example.

http://bag.hotmail.ru/vague/makarl.png

[Fizick]

It seems, it is crached in SSE mode, if there are two or more Vaguedenoisers in script.
Anybody is here?
I also still wait speed report before releasing next ver.

[MfA]

Slow already? You still have to repeat the denoising 4^nsteps - 2 more times to become shift invariant :) (For true shift invariant transform based denoising you are better off just using a block DCT ... faster and easier.)

[d'Oursse]

Originally posted by Fizick
What about speed, MAY BE more fast would be using wavelets with integer (rational) coefficients (5/3 etc) with scaling, and using not float, but integer calculation. But it is full rewriting of the code.

i don't know if yo a re aware of algo too compute such wavelets (at least, scale functions), but you could use an induction algorithm to compute the scale function on the points k/2^j (j>=0, k \in Z). It's quite fast and i think quite optimizable, too

regards

[Fizick]

MfA, I do'nt want to become shift-invarint! :)
I simply use that i am not.

d'Oursse, interger wavelet well known (it used for example in loss-less jpeg2000).
I found a lot of them now. Fo example, 5/3 wavelet coef is:
h =-1/8 1/4 3/4 1/4 -1/8
g = 1/4 -1/2 1/4 0 0

In current code it is possible simply to change float to integer, and add integer divider (scale.)

But as Kurosu says:
the actual code is really bandwidth-hungry, I guess it's now the main limitation
The mostly time spend to copy with pitch (transpose colunm to lines etc). I checked it.
More over, I not found any speed increasing with assembler 3Dnow and SSE in wavelet multiplication part.

So, now i am a pessimist about speed in current framework. May be with lifting method?

[Soulhunter]

Originally posted by Fizick
I also still wait speed report before releasing next ver. I could do, if you give me a list of settings I should use for the test... ;)


Bye

[Lefungus]

Originally posted by Fizick
So, now i am a pessimist about speed in current framework. May be with lifting method?

I tried to add integer lifting methods (http://perso.wanadoo.fr/polyvalens/clemens/lifting/lifting.html) too without great success, but i still think it's the way to follow. The whole plugin would have to be changed though.

[Fizick]

Lefungus, it seems we stil will live with your plugin. :) :(

Soulhunter or somebody, please check speed of v.0.29 and 0.30 (or above) with wavelet=2 without Wiener, method=0, especially for Athlon:
Vaguedenoiser(threshold=2, method=0, wavelet=2)
Also it is interestly to compare speed for different wavelets .

But sizes must not be mod 64 (i.e. NOT 640)!
As Kurosu noted, there are big slowdown for such sizes. As I found, it is due to 2 COPY functions, mostly following (pitch2 is frame width or height):
_inline void Wavelet::copy(float register*p1, float register*p2, int pitch2, int length)
{ // very-very slow for pitch2 is mod64 (cache ?)
for(int i=length;i!=0;i--)
{
//*p2=p1[i];
*p2=*(p1++);
p2+=pitch2;
}
}

Very simple code (may be too). :rolleyes: Any processor and assembler guru here?

By the way, I prepare v.0.32.
Part of work was done by Kurosu!
Added Villasenor-Belzer-Liao 6/10 wavelet (not optimized C version only)
Changed estimation wavelets to more optimal pairs for WienerChop mode.
(Brislawn wavelet has too different thresholds and sharpeness).
3DNow optimized version of WienerChop and AutoThreshold - thanks to Kurosu. :)
3DNow mode of hard and Qian thesholding still have a some bugs and are not used. :( - Hard method produce some vertical lines, and Qian work more similar to hard than Qian.

I can not release it now due to some problem with www server.:confused: Later.
Probably I will have time to get report from Soulhunter. :)

[DarkNite]

Testbed

Athlon XP 2400+, 512MB PC2700, Windows XP SP1a

HelixYV12 AVI-> AviSynth 170604-> AVS2AVI 1.39-> HelixYV12 AVI

Script
loadplugin("vaguedenoiser29.dll")
#loadplugin("vaguedenoiser31.dll")
#loadplugin("vaguedenoiser32.dll")
avisource("intro_test.avi")
vaguedenoiser(threshold=2, method=0)
#vaguedenoiser(threshold=2, method=1)
#vaguedenoiser(threshold=2, method=3)
#vaguedenoiser(threshold=2, method=0, wavelet=1)
#vaguedenoiser(threshold=2, method=0, wavelet=2)
#vaguedenoiser(threshold=2, method=0, wavelet=3)
#vaguedenoiser(threshold=2, method=1, wavelet=1)
#vaguedenoiser(threshold=2, method=1, wavelet=2)
#vaguedenoiser(threshold=2, method=1, wavelet=3)
#vaguedenoiser(threshold=2, method=3, wavelet=1)
#vaguedenoiser(threshold=2, method=3, wavelet=2)
#vaguedenoiser(threshold=2, method=3, wavelet=3)

Raw
Average FPS = 80.99

VagueDenoiser 0.29

Method=0
Average FPS = 26.57

Method=1
Average FPS = 25.83

Method=3
Average FPS = 26.25

VagueDenoiser 0.31

Method=0
Wavelet 1: Average FPS = 24.43
Wavelet 2: Average FPS = 26.19

Method=1
Wavelet 1: Average FPS = 23.52
Wavelet 2: Average FPS = 26.12

Method=3
Wavelet 1: Average FPS = 23.54
Wavelet 2: Average FPS = 26.30

VagueDenoiser 0.32

Method=0
Wavelet 1: Average FPS = 23.46
Wavelet 2: Average FPS = 25.86
Wavelet 3: Average FPS = 23.13

Method=1
Wavelet 1: Average FPS = 23.39
Wavelet 2: Average FPS = 26.05
Wavelet 3: Average FPS = 23.14

Method=3
Wavelet 1: Average FPS = 23.50
Wavelet 2: Average FPS = 25.52
Wavelet 3: Average FPS = 22.75

Hmm... not much of a difference as far as I'm concerned.

[EDIT]: More results posted. It's been a long day. :)

[Fizick]

Thanks for report.
Hmm... not much of a difference as far as I'm concerned.
The most interesting thing is that v.0.29 use 3DNow! (Athlon) optimized thresholding filter function (and probably must be more fast), but v.0.31 use SSE instead of it. I have similar results with my old SDR PC133 DRAM memory.

What were test clip width and height?

And what about speed of new wavelet=1?

[DarkNite]

The test clip was 632x480. As for wavelet=1 test... I have 3 renders running now (that actually have a deadline) so that'll have to wait until I get some free cpu cycles tomorrow.

[Soulhunter]

Gladiator - Chapter No. 19 / XviD v.1.0.1 - Q2 - MPEG - VHQ1



Unprocessed:


Speed: 15.1 fps @ XP 3000+

Average bitrate: 5561.7 kbit/s



V.0.28 Results:


VagueDenoiser(threshold=1, method=0)

Speed: 8.8 fps @ XP 3000+

Average bitrate: 5486.2 kbit/s


VagueDenoiser(threshold=2, method=0)

Speed: 8.7 fps @ XP 3000+

Average bitrate: 5369.6 kbit/s



V.0.30 Results:


Vaguedenoiser(threshold=1, method=0, wavelet=2)

Speed: 9.0 fps @ XP 3000+

Average bitrate: 5486.5 kbit/s


Vaguedenoiser(threshold=2, method=0, wavelet=2)

Speed: 9.0 fps @ XP 3000+

Average bitrate: 5369.6 kbit/s



Now with some more noise...



Unprocessed:


Speed: 13.1 fps @ XP 3000+

Average bitrate: 8196.3 kbit/s



V.0.28 Result:


VagueDenoiser(threshold=3, method=0)

Speed: 8.1 fps @ XP 3000+

Average bitrate: 7499.5 kbit



V.0.30 Result:


Vaguedenoiser(threshold=3, method=0, wavelet=2)

Speed: 8.3 fps @ XP 3000+

Average bitrate: 7504.6 kbit/s



Bye

[Fizick]

Thanks for report. It seems , that 3DNow opimization is not better than SSE.

So, I released new version 0.32.
Addition to notes in my above message:
3DNow mode of hard and Qian thesholding re-enabled after some bugs were fixed by Kurosu and (at last ?) by Fizick.
Small speed increasing mainly due to copy reverse order (but big slowdown for mod64 still exist).
Ported to NASM memcopy assembly function (no more non-NASM assembly).
(SSE float-byte transforms still replaced by C).

Question - is optimization will be better for wavelet transform function ? (now C code for new wavelet 1 and 3).
I wait reports for different wavelets.

[DarkNite]

More results posted. See previous report.

[EDIT]
It's been such a long day I'm even considering doing a mod64 comparison later. :D

[Kurosu]

Originally posted by Fizick
[B]Lefungus, it seems we stil will live with your plugin. :) :(
But sizes must not be mod 64 (i.e. NOT 640)!
As Kurosu noted, there are big slowdown for such sizes. As I found, it is due to 2 COPY functions, mostly following (pitch2 is frame width or height):
_inline void Wavelet::copy(float register*p1, float register*p2, int pitch2, int length)
{ // very-very slow for pitch2 is mod64 (cache ?)
for(int i=length;i!=0;i--)
{
//*p2=p1[i];
*p2=*(p1++);
p2+=pitch2;
}
}

Very simple code (may be too). :rolleyes: Any processor and assembler guru here?

Ah yes, I recall why now. What happens is that all reads on p2 pointer are from different cache line size. ie, the processor caches 63 bytes for nothing. For K6 and P3, the same should happen with mod32 pitches. This is unavoidable with the current code, and that's why very specific rewriting of the code for vertical transform would be needed.

The lifting scheme has this advantage that there are well known in place transforms, which would help quite a bit with this.

3DNow optimized version of WienerChop and AutoThreshold - thanks to Kurosu. :)Did you test them? I didn't, and that's why I didn't talk about them.

3DNow mode of hard and Qian thesholding still have a some bugs and are not used. :( - Hard method produce some vertical lines, and Qian work more similar to hard than Qian.
Ah, I saw in later posts that this was fixed. What had I forgotten?

And that one:
It seems , that 3DNow opimization is not better than SSE.
On my system (Athlon XP 2800+/512 L2 cache and DDR266), I noticed a rather important difference (around 20%); at that time, I really thought the SSE code was a waste of my time considering it's slower and I don't need it.

[MfA]

Yet another paper (http://dali.korea.ac.kr/publication/int_jour/paper/IntJour53.pdf) on how to do the transform better ... this is a variation on the local wavelet transform I think.

Marco

PS. I dont quite see why strides of a multiple of the cacheline size would cause a slow down. Also on my Athlon stride 259 accesses are about as fast as stride 67, but the slow down of stride 256 is 3 times greater than the slowdown of stride 64 ... so 64 isnt the only magic number. If you thought 640 was bad, try 768/1024.

I modified a test program from blitzwave a bit, see if you can make heads or tales of the results ...


#include "stdafx.h"
#include <iostream>
#include <time.h>
int _tmain(int argc, _TCHAR* argv[])
{
using namespace std;
int j = 0;
for (int e=5; e<=11; ++e) {
for (int stride=(1<<e)-3; stride<=(1<<e)+3; ++stride) {
int n = 345;
int *data = new int[n*stride];
double timer = clock();
for (int dummy=0; dummy<100000; ++dummy) {
for (int i=0; i<n; ++i) {
j += data[stride*i];
}
}
cout << "n: " << n << "\tstride: " << stride
<< "\ttime: " << (clock() - timer)/10000 << endl;
delete [] data;
}
cout << endl;
}
cout << j;
return 0;
}

[Fizick]

DarkNite: More results posted. See previous report.
Thanks. We see that not-optimized wavelet 1 is slower (a litle).

Kurosu, now for AthlonXP2400 I found a really big slowdown not for mod64, but only for width=256, 512 and 768 (i.e mod256):
256 - 9 fps
260 - 22 fps
384 - 16 fps
388 - 20 fps
512 - 4 fps
516 - 15 fps
640 - 11 fps
644 - 13 fps
704 - 11 fps
708 - 11 fps
764 - 11 fps
768 - 2.5 fps
(PAL)
Pentium 3 (512 MB cache) have not such big slowdown.

may be it is effect of cache Ll or L2 miss.
But we have not reading with pitch, but writing with pitch in this copy fuction. Reeading by 64 blocks is O.K. But probably writing also use the SAME cache line as reading block, and data will be replaced, and must be read again.
This is unavoidable with the current code
Another copy function have pitch for reading. Probably it can be MMX optimized (write 8 byte without write-cache?)
...this was fixed. What had I forgotten?
Nothing interesting (see source comments). But thanks to your bugs I began to understand a MMX code a little. :D

MfA, thanks for link! Very useful, as always from you.
Seems, it is almost the same method which I have in my head yesterday (but not in code).

For the present, bug-fixed version 0.32.1 is released.
Fixed bug in copy function, introduced in v.0.32.
Re-enabled SSE optimized float-byte and byte-float conversion after fixing some bugs.

[MfA]

The only thing I can think of is that the code might be trashing the TLB.

[Fizick]

I do not understand you. :confused:

[MfA]

Try

http://crd.lbl.gov/~dhbailey/dhbpapers/cache.pdf

and

http://citeseer.ist.psu.edu/cache/papers/cs/13015/http:zSzzSzwww.research.ibm.comzSzpeoplezSzdzSzdfbzSzpaperszSzBacon94Framework.pdf/bacon94compiler.pdf

Cant say I have my head around it entirely, but Id say the speed hit is a combination of both cache and tlb trashing. Because with 16 way associativity and 256 kb cache I dont think you would be hitting just cache sets often enough to explain the slowdown (unless you used a huge vertical resolution). Might be wrong though :) Not that it matters, some padding will fix both.

[Fizick]

I do not know what is "TLB" :confused:,
but I know (but not very sure) that Athlon have only 2-way cache level 1 (and exclusive 16-way cache level 2, yes).

[Fizick]

"Padded" version 0.33 released.
Fixed slowdown for mod64 width by padding (thanks to MfA)
Add partial denoising mode (by blending with source)
Fixed bug with AutoThreshold for 3DNow.
AutoThreshold is now also dependent from "wratio" parameter.
Added messages for Debugview utility.
Change some parameters default values to more optimal (for me?):
thresh=0 (auto), method=3, nsteps=4, wavelet=1, percent=75.

It is all. The bigger improvements are still shelved. :(

[MfA]

TLB == translation lookaside buffer, which maintains the mapping between virtual and physical memory addresses. At any time only part of the mapping is known to the processor, ie. cached ... and this cache can be trashed just as the data cache. With the same type of results.

How did you pad BTW? Personally Id try detecting multiples of 64 and pad with 16 bytes (being aligned on 16 byte boundaries is nice SSE parallelization).

[Fizick]

I use 2 point right pad (i.e. 8 byte float) if current plane width is mod64.
And I use mirror symmetry for this points to prevent border effects.

Id try detecting... BTW, for what (plugin ?)

[Soulhunter]

As promised, some more tests... ;)


VagueDenoiser v.0.33 test No. 1


Source:

Gladiator (PAL/R2) - Chapter 19


Settings:

XviD v.1.0.1 - Fixed Q2 / VHQ1 / MPEG / No extra stuff


My box:

Athlon XP2600 @ XP3000 / 1024MB DDR400 CL2 RAM / WindowsXP


Results:

Mpeg2source("C:\blah.d2v").Trim(1,1500)

Size = 45.35 MB / Speed = 14.9 fps


VagueDenoiser(0.75,3,6,0,false,false,1,true,0.5,75)

Size = 44.73 MB / Speed = 4.3 fps


VagueDenoiser(0.75,3,6,0,false,false,1,false,0.5,75)

Size = 44.07 MB / Speed = 7.1 fps


VagueDenoiser(1,3,6,0,false,false,1,true,0.5,75)

Size = 44.38 MB / Speed = 4.2 fps


VagueDenoiser(1,3,6,0,false,false,1,false,0.5,75)

Size = 43.55 MB / Speed = 7.1 fps


VagueDenoiser(2,3,6,0,false,false,1,true,0.5,75)

Size = 42.68 MB / Speed = 4.3 fps


VagueDenoiser(2,3,6,0,false,false,1,false,0.5,75)

Size = 41.59 MB / Speed = 7.2 fps


VagueDenoiser(0.75,3,6,1,false,false,1,true,0.5,75)

Size = 45.00 MB / Speed = 4.3 fps


VagueDenoiser(0.75,3,6,1,false,false,1,false,0.5,75)

Size = 44.29 MB / Speed = 7.1 fps


VagueDenoiser(1,3,6,2,false,false,1,true,0.75,75)

Size = 43.79 MB / Speed = 4.3 fps


VagueDenoiser(1,3,6,2,false,false,1,false,0.75,75)

Size = 43.45 MB / Speed = 7.1 fps


VagueDenoiser(1.25,3,6,0,false,false,1,true,0.5,75)

Size = 43.96 MB / Speed = 4.3 fps



VagueDenoiser v.0.33 test No. 2


Source:

Matrix Revolutions trailer (E)


Settings:

XviD v.1.0.1 - Fixed Q2 / VHQ1 / MPEG / No extra stuff


My box:

Athlon XP2600 @ XP3000 / 1024MB DDR400 CL2 RAM / WindowsXP


Results:

Mpeg2source("C:\blah2.d2v").trim(1,2500)

Size = 61.95 MB / Speed = 15.2 fps


VagueDenoiser(0.75,3,6,0,false,false,1,true,0.5,75)

Size = 61.04 MB / Speed = 4.3 fps


VagueDenoiser(0.75,3,6,0,false,false,1,false,0.5,75)

Size = 60.31 MB / Speed = 7.2 fps


VagueDenoiser(1,3,6,0,false,false,1,true,0.5,75)

Size = 60.69 MB / Speed = 4.3 fps


VagueDenoiser(1,3,6,0,false,false,1,false,0.5,75)

Size = 59.79 MB / Speed = 7.2 fps


VagueDenoiser(2,3,6,0,false,false,1,true,0.5,75)

Size = 59.18 MB / Speed = 4.3 fps


VagueDenoiser(2,3,6,0,false,false,1,false,0.5,75)

Size = 58.08 MB / Speed = 7.2 fps


VagueDenoiser(0.75,3,6,1,false,false,1,true,0.5,75)

Size = 61.42 MB / Speed = 4.3 fps


VagueDenoiser(0.75,3,6,1,false,false,1,false,0.5,75)

Size = 60.62 MB / Speed = 7.2 fps


VagueDenoiser(1,3,6,2,false,false,1,true,0.75,75)

Size = 60.10 MB / Speed = 4.3 fps


VagueDenoiser(1,3,6,2,false,false,1,false,0.75,75)

Size = 59.72 MB / Speed = 7.2 fps


VagueDenoiser(1.25,3,6,0,false,false,1,true,0.5,75)

Size = 60.31 MB / Speed = 4.3 fps


VagueDenoiser(1.25,3,6,0,false,false,1,true,0.5,100)

Size = 59.30 MB / Speed = 4.3 fps


VagueDenoiser(2,3,6,3,false,false,1,true,0.5,50)

Size = 59.06 MB / Speed = 4.2 fps


VagueDenoiser(1,3,6,2,false,false,1,true,0.5,50)

Size = 60.72 MB / Speed = 4.3 fps

VagueDenoiser(1.25,3,6,0,false,false,1,true,0.5,100)

Size = 43.05 MB / Speed = 4.4 fps


VagueDenoiser(2,3,6,3,false,false,1,true,0.5,50)

Size = 42.68 MB / Speed = 4.3 fps


VagueDenoiser(1,3,6,2,false,false,1,true,0.5,50)

Size = 44.37 MB / Speed = 4.3 fps



Bye

[SILICON]

Originally posted by Fizick
"Padded" version 0.33 released.

Change some parameters default values to more optimal (for me?):
thresh=0 (auto), method=3, nsteps=4, wavelet=1, percent=75.

You have a bug in this change.

If your use VagueDenoiser() the Avisynth give a ERROR: "Invalid Theshold"

[Fizick]

Confirmed. :(
Bug fixed in 0.33.2

Did anybody try Vague on Pentium 3 or 4? (for width=512)

[cheburashka]

@Fizick

I've tried it(0.33.1) for "38 popugaev" on P4 2.4. Result is pretty good and fps ~ 10-11. Clean enough with keeping details.

Default options and width 512.

[Fizick]

cheburashka, thanks for info.

(but i think (but not try), that "38 popugaev" original source is restored and very good without any filter)

To all (who uses YUY2).
YUY2 dont work since v.0.32.1 :(
Bug fixed in 0.33.3 (released today)

[krieger2005]

"38 popugaev" original source is restored (on DVD). But maybe cheburashka have this from TV-Capture or VHS-Capture...

I tried VagueDenoiser and it make the picture clean without bluring... But it can't remove this "blobs" (like in the example from you Fizick where the background is so green).

I tried for this Problem this:

sauber=VagueDenoiser(threshold=3,method=3,nsteps=6,chromaT=0.8, wiener=true, wratio=5, interlaced=false).
\UnDot.
\UnFilter(30,30)

a=ConvertToRGB32._2DClean(0,10,2,2).ConvertToYV12.
\DideeBlur(sauber.Blur(1),25).UnDot()
b=ConvertToRGB32._2DClean(0,10,2,2).ConvertToYV12
m=YV12subtract(a,b).
\YV12LUT(YExpr="x 129 > x 255 < & x 122 < x 0 > & | 255 0 ?")
MaskedMerge(sauber,m,Y=3,V=3,U=3,useMMX=true)
UnDot
UnFilter(40,40)


"sauber" should be clip without this "blobs" (it can be unsharp).
"a" should be tuned (i mean the value "25"), till the Blubs are away from the Picture.
"b" is a picture with Blubs
"m" here you can decide wich parts from "sauber" should be used. 129-255 are the dark blobs, 0-122 are the bright blobs. If the values are about 127/128 the function removes more... try it!

[Fizick]

New version 0.33.4 - August 23, 2004.
Fixed bug with 4 rigthmost mirrorred padded pixels.

[Soulhunter]

Nice... :)

Btw, could you maybe add a link (http://bag.hotmail.ru/vague/vaguedenoiser.dhtml) in your signature ???

Would be easier than searching it every time a new version is out... ;)


Bye

[Leak]

Originally posted by Soulhunter
Btw, could you maybe add a link (http://bag.hotmail.ru/vague/vaguedenoiser.dhtml) in your signature ???

Well, the WWW button under his posts leads to bag.hotmail.ru, where you'll get links to all his filters - isn't that close enough?

np: The Modernist - Prozac Europe (Kangmei)

[Soulhunter]

Originally posted by Leak
Well, the WWW button under his posts leads to bag.hotmail.ru, where you'll get links to all his filters - isn't that close enough?
... :o

[Fizick]

:cool:

[OBcecado]

Hi, sorry for bugging you, but isn't it possible to update the thread's subject ?
It'll be easier to find out when there are updates of this great filter.


All the best.

[Fizick]

But what do you want from update? :)

[celtic_druid]

I guess they just want the current version in the title when it is released.

[Wilbert]

For some reason unknown to me I can't update the title of this thread. Perhaps Sh0dan is so kind to update it each time :)

[Teegedeck]

Doesn't changing the title of the first post in the thread always do the trick?

[Wilbert]

Nope, as you can see I changed it to "VagueDenoiser 0.33: a 2D Wavelet denoiser/smoother", but the thread title remains the same.

[Fizick]

May be we must ask Lefungus? :)

[celtic_druid]

You just select edit thread from the admin tools drop down thingy and change it.

[Wilbert]

I guess one is never too old to learn something. Thanks!

[Lefungus]

Last time I tried to change the topic title for the new Fizick version, It was impossible. I guess once a mod change it, the first poster isn't able to change it anymore

[LigH]

A user not registered here (but in the german board) asked me to post a bug report here:

'interlaced=true' produces an access violation with 'Wiener=true'

Configuration:
Athlon Thunderbird 800 MHz
256 MB RAM
Windows XP Professional (no SPs, but all critical updates)

Tools:
AviSynth 2.55 (final 2004-08-31)
DGIndex 1.0.12 & DGDecode
VagueDenoiser 0.33.4 from http://bag.hotmail.ru/
VirtualDubMod 1.5.10.1 build 2439

Script:
LoadPlugin("DGDecode.dll")
LoadPlugin("VagueDenoiser.dll")
MPEG2Source("HeavyNoise_interlaced_PAL_DVD.d2v",iPP=true)
VagueDenoiser(interlaced=true,Wiener=true)

Procedure:
Open script in VirtualDubMod: "Avisynth read error: Avisynth: caught an access violation at 0x########, attempting to read from 0x########"