removing noise: techniques for animation versus live action

[McQuaid]

Currently, I'm using TemporalSoften(2,5,15) as a general purpose noise removal for both cartoons and live action. Temporalsoften is pretty good for me, but a fair bit of detail is lost. Do people recommend using different noise filters for animation versus live action. Also, I'd assume order would matter when doing a resize. I would think doing a noise filter after a resize would be faster but not as good, but I'm finding it difficult to tell the difference between the two. I'm capturing off television, full frame, there is a fair amount of noise coming from my signal but its not too bad.

I just wanted to get a heads up on peoples different noise removal techniques.

[bb]

I prefer Dynamic Noise Reduction (Donald Graft's scriptable version preferred). You won't get rid of all the noise, but you won't lose much detail, and there's no ghosting. Mostly I use a threshold of 8, sometimes I increase it to 10. The default of 12 is too high for my taste.

Also experimented with TemporalCleaner and TemporalSmoother. Too much loss of detail IMO, too much ghosting...

bb

[High Speed Dubb]

I haven’t used AVISynth, so I don’t know the best filters and settings for noise reduction. But based on the way noise filtering works — Yes, you should use much more aggressive noise reduction with cartoons. That’s for two reasons: 1) Animation tends to have very well defined boundaries, so you get fewer artifacts, and 2) Animation tends to have plainly shaded regions, so noise is more visible.

So just increase the amount of noise reduction when processing animation and the resulting image should look much nicer.

(I wonder if the board will mess up my signature smiley?)

[b0b0b0b]

Hello high speed dubb. Are you the fellow that wrote the gradual/adaptive noise filters for dscaler?

How do you think they compare to those available for avisynth?

Want to port yours to avisynth?

[High Speed Dubb]

b0b0b0b,

Yep, I’ve been working on DScaler noise filtering.

The adaptive and gradual noise filters are (literally) incomparable to anything available in AVISynth...

...because I haven’t yet run AVISynth. ;)

It would be nice to port them over. It may be a little while, though, so I can get some more work done at school. Anyone who wants to beat me to it is welcome to convert the filters to AVISynth (or take relevant parts, if you’re able to understand the code). It’ll probably be worth porting the comb filter, too.

You can get the source from DScaler’s CVS at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/deinterlace/DScaler/Plugins/

[Guest]

@High Speed Dub

Can you please tell us about the principles of operation of these filters you've mentioned. Thank you.

[High Speed Dubb]

In terms of noise filters, Gradual Noise is the better one to start with, since it’s much simpler, and is the basis for Adaptive Noise. Gradual Noise is also commented more thoroughly — I think it has more comments than code. Also, Adaptive Noise’s assembler code is sort of garbled, because I started to use a cool profiler while I was writing it and wanted to make use of my new toy.

Gradual Noise uses the local color value differences as a rough estimate of the probability that there’s motion at a pixel. Where it’s likely that the pixel isn’t in motion, it heavily weights the old pixel value. (But it always moves at least one toward the new value so that the color depth is maintained.) Where motion is likely, most or all the weight is given to the new pixel value.

Adaptive Noise is based on Gradual Noise, but adds two things. It uses a better motion estimate (basically by blurring the noise estimates at nearby pixels, and by using past noise estimates at the same pixel). And it automatically changes the amount of noise reduction to correspond with a user defined approximate quantile of the noise distribution.

The source code for the Gradual Noise filter has a really good explanation of what it’s doing. FLT_AdaptiveNoise.txt has a reasonably good explanation of that filter, but there are still some holes, there — especially in terms of the justification for the algorithm.

Temporal Comb is also pretty well commented. The general idea there is to detect pixels which have been “shimmering,” i.e., wavering back and forth between two values. That’s a telltale of color crosstalk (dot crawl and shimmer) problems. When shimmering is detected, it’s averaged out. That doesn’t completely remove the inaccuracy in color crosstalk areas, but it does make them much nicer to look at. The trick here is distinguishing shimmering from areas with a lot of motion. I just check to make sure the amount of change among even and among odd frames (yes, frames) isn’t too great.

Anyhow, I’d be happy to help with any unclear parts of the code or comments.

[High Speed Dubb]

Probably the best explanation of what the Temporal Comb is for is at the end of its docs -- See

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/deinterlace/DScaler/Help/TemporalComb.htm?rev=1.8

[Guest]

Thank you. That is very helpful and interesting.