New very slow FFT denoiser

[DarkFoon]

I thought U and V were sampled differently.
Ex. -YUV 4:2:0 (YV12, MPEG1/2, etc.) The luma is fully sampled, because the eye notices luma differences the most, and thus it is least compressed. U is subsampled, and V is even more so.
-YUV 4:2:2 (YUY2) The luma is not subsampled (perhaps that is the wrong word?) The U and V are equal, and because of such, there is more data than YV12.
-YUV 4:1:1 (DV) I'm noticing a luma pattern here The U and V are again equal, but smaller than YUY2.
-YUV 4:4:4 (???) fully sampled, lots of data.
I draw my data conclusions (which become the explanations for my understanding of this) by taking an AVS in said colorspace, and opening it in Vdub, and then looking at the bitrate in the information box.
YV12 is the smallest, RGB32 is the largest.
I think I may be right...
Unless I am totally misunderstanding the YUV numbers and such... ^_^;;

[Wilbert]

Ex. -YUV 4:2:0 (YV12, MPEG1/2, etc.) The luma is fully sampled, because the eye notices luma differences the most, and thus it is least compressed. U is subsampled, and V is even more so.

No. There's one UV sample per four (2x2) luma samples.

YUV 4:2:2 (YUY2)

One UV sample per two (horizontal) luma samples.

http://www.avisynth.org/Sampling

-YUV 4:1:1 (DV)

One UV smaple per four (horizontal) luma samples.

Yeah, the notation is a bit weird. I don't understand how you can read of the vertical subsampling. More info:

http://msdn.microsoft.com/library/de...YUVFormats.asp

[Poutnik]

YUV 4:2:0 : U and V are not sampled differently, but only one of them is coded in a TV line, alternating each other, i.e. one line U, one line V.

Y=+0.299 R + 0.587 G + 0.114 B
U=-0.1687 R - 0.3313 G + 0.5 B
V=+0.5 R - 0.4187 G -0.0813 B

[DarkFoon]

Thanks for clearing that up Wilbert and Poutnik!
I remember reading about all this a long time ago, I guess time has decayed my memory...

Y=+0.299 R + 0.587 G + 0.114 B
U=-0.1687 R - 0.3313 G + 0.5 B
V=+0.5 R - 0.4187 G -0.0813 B

Poutnik, what is this? The RGB-> YUV conversion table?

[Poutnik]

Yes, it is. It was related to Wilbert=s note:

"V is the red minus the luma. Highering V will turn your clip to red and lowering it to green (you can check that with ColorYUV(off_v=x))."

[DarkFoon]

Thanks again!
Now back to the topic:

@Fizick, is there a possibility of a speed increase in the near future with FFT3D? Or perhaps variable block size based upon some parameter M that defines the sensitivity to detail?
Tell us the ideas that you have for your filter. It seems the people here on the forum don't contribute ideas very often, so if you give it a jump-start with your ideas, then we all could comment and derive something, yadda, yadda, yadda...

[gst]

Or perhaps variable block size based upon some parameter M that defines the sensitivity to detail?

+1
I don't know what blocksize is the best for optimal quality, this M parameter would be a great idea.

[DarkFoon]

I have done some thinking about variable block size, and I think this 'parameter M' would be better suited to modifying the sigma value than the block size.
Changing block size (making it smaller) really doesn't affect the quality, it just makes the filter more ineffective. A large block size with a small sigma, in my opinion, is better than a smaller block size with a large sigma. And it would appear that the data is on my side: larger blocks remove more noise.
The 'parameter M' would be more useful as this:
a complexity calculator would be run over the block, if the block is a solid color with some noise (the complexity calculator would find this block to be very 'simple'), the sigma value would be raised, according to the value of 'parameter M'
Now, lets say the block is over an eye. The complexity calculator would find this block to be very complex, and would lower the sigma, so it wouldn't blur the delicate details.
A high 'parameter M' would mean that when the filter processes a complex block, it would blur it more, and ignore the fine details more. But a low 'parameter M' would mean that it would not blur complex details.
Ideally, the user could specify just the 'parameter M' and let the filter decide what is complex and what isnt. Or, the user could specify the 'parameter M' and sigma, and sigma would act as a bias to 'parameter M', such that, if sigma is low, then the sigma would not be raised very high even if the block is detected as 'simple'.
And if the sigma is high, then the sigma would be modified to be higher even if the block is detected as complex.

If this doesn't make sense (as I suspect it wont) please message here, and I'll try to explain it better. This is just my rough idea.

[Mug Funky]

the trick here is how to determine what's visually complex (ie, relating to human perception) rather than complex in frequency. with FFT the most complex you're going to get is white noise. in this case, i think FFT3d will probably pass about half of it through (i'm guessing here, as i can't be bothered generating test videos and running fft3dfilter on them), possibly regardless of the sigma value used.

my understanding is that if there's "spikes" in frequency plus a background that would approach pink or white noise, then sigma determines where to draw the line between the noise floor and the spike (which is assumed to be detail). of course, i too may be wrong.

anyhoo, it strikes me that it would be exceedingly difficult to determine from the FFT that you have a complex object like an eye in the spatial domain.

however, some kind of adaptive sigma is still a good idea. i wonder how it would work? rather like LAME's floating ATH is how i imagine it, where the noise floor is determined per-block, and the threshold (ATH in LAME, or sigma in FFT3dfilter) expresses a desired ratio rather than a constant. this would also mean that no matter the block size, sigma can be kept constant and perform the same (right now larger blocks mean more noise removal for the same value of sigma).

btw, this baby works REALLY well when you motion-compensate it i can't wait for MVtools to include overlapped-block motion compensation, so it doesn't throw off FFT3d's groove...

[DarkFoon]

I imagine the edge detector in Msmooth as the complexity calculator. I mean, what is (fine) detail? Edges! So, perhaps an edge detector could act as a good complexity calculator. Only problem is, it could pick up the noise as edges.. :/
I also remember seeing while using libAVcodec to encode MPEG2, an RC control algorithm called "texture complexity", perhaps there's a complexity calculator that could be taken from there?
I quote these because they are open source, and the source could be used in the filter, I guess.
Your ideas, Mug Funky, intrigue me. I can't say I like or dislike the idea of a ratio. It just... intrigues me. OH!
How I wish I could program so I could test all these things and see if they're any good!

By the way, what do you mean:

this baby works REALLY well when you motion-compensate it i can't wait for MVtools to include overlapped-block motion compensation, so it doesn't throw off FFT3d's groove...

How do you motion compensate this filter? Why do you do that? Explain... Tell me your knowledge!

[State of Mind]

Will someone just go flat out and show some screenshots of their oisy DV footage and the outcome screenshots of this noise remover? I would like at least three examples...
Hope this isn't asking too much, plus others would get better idea too.

[Mug Funky]

@ darkfoon:

motion compensating it means that the temporal component uses frames that are deformed such that they match the current frame as closely as possible. this is useful because it makes it easier to distinguish between noise and signal - the more alike you get 2 frames looking, the more likely any differences will be noise, and can safely be removed.

in my case, i'm using manao's excellent MVtools to motion compensate the previous and next frames, then i'm running fft3d on the result. this helps get rid of the ghosts that you'd possibly get otherwise with smooth video and a high sigma value.

at this point, MVtools isn't ideal for anime, though it does help quite a bit. the only problem is that you want to make sure blocks don't show through. in reality it's quite hard to do this, as it looks like the blocking is small enough or large enough to be ignored by FFT3d.

here's a very alpha function to do this. beware there's no artefact-protection-through-masking that i'd usually put on an experimental denoiser, so blocks can and probably will show up.

also beware that it probably wont give much of a different result from running fft3d on it's own (but it'll be lots slower )

function fftMC (clip c, int "pel", int "blocksize", float "sigma", int "bw", int "bh", bool "chroma")
{
	pel = default(pel,2)
	blocksize = default(blocksize,8)
	sigma = default(sigma,2.0)
	bw = default(bw,16)
	bh = default(bh,16)
	chroma = default(chroma,false)
	
	vfw = c.mvanalyse(pel=pel, isb=false, blksize=blocksize)
	vbw = c.mvanalyse(pel=pel, isb=true, blksize=blocksize)
	
	cro = interleave(c.mvcompensate(vfw),c,c.mvcompensate(vbw))
	\.FFT3DFilter(sigma=sigma,bw=bw,bh=bh,plane=0)
	\.FFT3DFilter(sigma=sigma,bw=bw,bh=bh,plane=1)
	\.FFT3DFilter(sigma=sigma,bw=bw,bh=bh,plane=2).selectevery(3,1)
	
	lum = interleave(c.mvcompensate(vfw),c,c.mvcompensate(vbw))
	\.FFT3DFilter(sigma=sigma,bw=bw,bh=bh,plane=0).selectevery(3,1)
	
	(chroma==true)? cro : lum
	
}

enjoy

[edit]

btw, i like your avatar.

[DarkFoon]

@ State of Mind

Here are those noisy DV samples you wanted.

The "unfiltered" examples have only been deinterlaced: they haven't been converted to YV12 for FFT3D. What I mean when I say "from frame 90" is that, I jumped to frame 90, and then I stepped frame-by-frame to frame 100. I do this whenever I am testing a filter with a temporal component, to give it time to kick in. Here's the script I used:

loadplugin("C:\plugins\kerneldeint140.dll")
loadplugin("C:\plugins\FFT3DFilter.dll")
avisource("capture.avi")
kerneldeint(order=0, threshold=0, twoway=false, sharp=false, map=false)
converttoYV12(interlaced=false)
FFT3dFilter(sigma=2.0, bt=3, plane=0, bh=48, bw=48, measure=false)
FFT3dFilter(sigma=3.0, bt=2, plane=1, bh=48, bw=40, measure=false)
FFT3dFilter(sigma=4.0, bt=2, plane=2, bh=48, bw=40, measure=false)

Note the block width used for the chroma. I remembered at the last moment that the chroma in YV12 has one quarter the pixels of the luma.
So, I had to pick block sizes that divide into 360x240, not 720x480.
Here are the differences:


The script I used there is:

loadplugin("C:\plugins\kerneldeint140.dll")
loadplugin("C:\plugins\FFT3DFilter.dll")
avisource("capture.avi")
kerneldeint(order=0, threshold=0, twoway=false, sharp=false, map=false)
converttoYV12(interlaced=false)
clip1 = last
clip2 = FFT3dFilter(sigma=2.0, bt=3, plane=0, bh=48, bw=48, measure=false).FFT3dFilter(sigma=3.0, bt=2, plane=1, bh=48, bw=40, measure=false).FFT3dFilter(sigma=4.0, bt=2, plane=2, bh=48, bw=40, measure=false)
Subtract(clip1,clip2)
Levels(112,1,144,0,255)

@Mug Funky

so that's what motion compensation does... I never knew. Is DePan better for anime? Or is MVtools better than depan? Or are they incomparable? Thanks for the script function! Though, I probably can't use it, because FFT3D is already so slow on my computer
btw, thanks for the compliment. I like your avatar as well.

[edit]
got my regular host back! now its fast(er)!

[State of Mind]

Judging from the screenshots, the image gets a bit blurrier after the noise is removed. However, I also realize that is why you guys have Sharpening filters, especially the one with the most hype at the moment (Limited Sharpen), which apparently doesn't get "edgy" when sharpening.
Anyway, the filter looks cool, but I still wonder why blur takes place after noise removal. The image on the bottom which appear to be sky or something, I can see serious noise removal, but not 100%. I guess this is currently impossible as far as software denoisers go, but that's fine. Still a major improvement.

Cheers,
Jeremy

[DarkFoon]

what you have to understand is that noise makes things look "sharp". Ever used one of those really old sharpening filters in an image editor? The image gets increasingly grainy as you "sharpen" it. As I understand it, this is because the sharpener adds noise strategically (or maybe not) to make the image look for crisp and sharp.
All denoisers make the image look a little blurry( or distort it in some fashion). The reason these look so blurry is because there was quite a bit of noise in the first place, so I have to make the tradeoff between noise removal and image integrity. I have picked noise removal. Besides, these don't look bad if you watch them as a movie, and not as a single frame.
Also, these could look blurry because I am rather new to this filter, and I have not done much experimenting with it because A) my computer is slow, and B) it is going on the fritz so I can't leave it on for long periods of time.
btw, what 'sky' are you talking about in the 'bottom image'?
If you are talking about the two pictures at the very bottom by themselves, they are just showing how much noise was removed for the actual pictures posted above. I used the 'subtract' filter so that I could see how much noise was being removed. As you can see, quite a bit was removed from those two images.

[State of Mind]

I never really clued in that sharpening filters added noise that way. Interesting. I don't like noise at all and wish I had the proper hardware in between my DVC (Panasonic PV-DV953) and my PC (Pentium 4, 3.0 GHz, 512 DDR 333 MHz PC3200). And I know when watching the actual video would make a user feel a little better about the filtered product overall, but I guess I'm really picky, heh. Anyway, you've done a good job with this filter. I look forward to using it. Hey, wouldn't removing most of the noise make the encoder's job a lot easier? I have read that a lot of noise can through off the accuracy of a codec and make it hard for it to analyze what it's encoding. Have I worded this decently?

Cheers,
Jeremy

[708145]

Originally posted by State of Mind
I never really clued in that sharpening filters added noise that way. Interesting. I don't like noise at all and wish I had the proper hardware in between my DVC (Panasonic PV-DV953) and my PC (Pentium 4, 3.0 GHz, 512 DDR 333 MHz PC3200). And I know when watching the actual video would make a user feel a little better about the filtered product overall, but I guess I'm really picky, heh. Anyway, you've done a good job with this filter. I look forward to using it. Hey, wouldn't removing most of the noise make the encoder's job a lot easier? I have read that a lot of noise can through off the accuracy of a codec and make it hard for it to analyze what it's encoding. Have I worded this decently?

Cheers,
Jeremy

You're right. It makes a codec's job much easier if it doesn't have to encode the noise!

Regarding the "sharper" impression noise gives: That's why some decoders add noise while playback. The difficult thing about this is to know how much noise to add where!

Some newer codecs (AVC HP) allow to store this info in the video stream. I don't know (yet) how detailed this info is since different scenes and even different parts of a frame need different amount of noise.

<prophecy> 2005 will bring up interesting codecs with this in mind. </prophecy>

bis besser,
T0B1A5

[DarkFoon]

@State of Mind
A pv-DV953 huh? Isn't that one of their new 3-CCD 'prosumer' models?
anyways, the best way to get rid of noise is to not have it in the first place. Those noisy images were filmed using a digital8 camera I was borrowing, not very high quality. But I used my school's Panasonic PD-150, which has 3 CCD, and uses miniDV, to film another event, and there is no noise! I had to transfer that footage to a digital8 tape so I could import it at home (schools wont let you check out $3000+ equipment) and it still had no noise! So, its not the medium necessarily, but the quality of the CCD(s).
That was a complete tangent, and I'll get back on point.
I know how you feel about denoisers, I'm very picky with my own video (though I usually work on anime, and not DV video). If your work is destined for DVD, or ultimately going to be shown on a TV, you'll be suprised at how good things will look on a TV, even if they look awful on a computer screen. If you want a subtle sharpening effect, without the added noise, or artifacting, trying using lanczos4resize() to upscale the image, then scale it back down with lanzcosresize() and that should add a little sharpening. (lanczos4 is better for upsizing, but feel free to experiment)
Yes, removing noise means the encoder doesnt have to waste data on junk, meaning there is less artifacting when there is a high-motion scene, because it has more bits to work with. (Redundancy...)
if you have time and want to do something fun, take a short test clip, and use sharpen(1.0) on it twice, then encode it with a restrained bitrate like max 4000, average 1200(use whatever encoder you want, but MPEG2 will make the point better). Then take the same source clip, runa denoiser on it instead of sharpen, and encode using the same parameters. Look at the size of the clips, and them look at their quality. You'll see the purpose of noise reduction.
And with that...
Happy new year all!
signing off...

[State of Mind]

DarkFoon,
Well, the camera does have 3 CCDs and it works pretty well. If the lighting is superb, there won't be any noise at all. But once the light starts dimming, noise starts showing up. I think its best quality is catching the true clarity of color. If it's a bright summer day and Me and my friends are wrestling in a field somewhere in the valley, Im going to see absolutely beautiful image with not a speckle of noise because the lighting would be perfect. I don't have a little attachable light to go with my camcorder and sometimes we shoot stuff at nighttime and I keep stressing that we should be under a street light just so we can be seen. And even then I think to myself "I'm going to have to filter this clip like a son of a b....".
And I am well aware of how much better video is going to look on TV. Hell, I took some clip that was DV > MPEG-2 > DivX > MPEG-2 and was encoded with TMPGEnc, VirtualDub and then TMPGEnc again (this was over a very long period of time that I bothered with this particular clip and before I even knew about AviSynth) and the DivX bitrate was 1500 kbps and when I put it on DVD, I gave it a bitrate of 6000 kbps just to make myself feel better about putting 120 MBs worth of DVD video on a brand new DVD+R and even though the file didn't look so good on my PC, it still looked really good on my TV. So I know that after I get to know my way around AviSynth and the filters and figure out exactly how I want to use them, the resulting image on the TV will be excellent. But I also like to store AVIs of my videos on my external HD and I much prefer XviD over DivX because that way I get sharper looking video at smaller filesize.
Anyway, awaiting new mobo, will enjoy experimenting with filters. But, I need to ask for future usage, what is the default script command for your denoiser filter?

Cheers,
Jeremy

[Dreassica]

Originally posted by krieger2005
great filter, ass always... and you are right: it's very slow.

To prevent "bluring" of edges with high sigma-values one can use "FineEdges"-Function from "Didée" i guess. Here my try:

function CleanUp(clip c, int "eEnd", int "eStart", int "bw", int "bh", float "sigma", int "sharp", bool "mask"){c

eEnd=default(eEnd,8)
Flaechen" markiert
eStart=default(eStart,68)
bw=default(bw,32)
bh=default(bh,32)
sigma=default(sigma,3.0)
sharp=default(sharp,180)
mask=default(mask,false)

ed=c.FineEdge(16)
SurfaceMask=ed.Levels(eEnd,1,eStart,255,0,false)
ret=mask ? MaskedMerge(c,c.BlankClip(pixel_type="YV12", color=$66FF66),SurfaceMask,Y=3,U=3,V=3,useMMX=true) : NOP()
cleanSurface=c.AddBorders(0,0,bw+20,bh+20).FFT3DFilter(bw=bw, bh=bh, sigma=sigma).crop(0,0,-(bw+20),-(bh+20)).xsharpen(sharp)

ret= (!mask) ? MaskedMerge(c,cleanSurface,SurfaceMask,Y=3,U=3,V=3,useMMX=true) : ret

return ret
}

great job.

Thios script isnt working for me, even after removing the usemmx=true bit. I get missing quotation marks errors. I'd be damned if i knew where it be missing tho.