Welcome Guest ( Log In | Register )


Important

The forums will be closing permanently the weekend of March 15th. Please see the notice in the announcements forum for details.

 
Temporal Smoother, Algorithm?
« Next Oldest | Next Newest » Track this topic | Email this topic | Print this topic
valja
Posted: Nov 22 2002, 08:01 PM


Advanced Member


Group: Members
Posts: 179
Member No.: 66
Joined: 1-August 02



This filter often makes miracles with noisy of bad quality files, so I would like to know, what's difference between different filtering levels. Just to be more conscious in use. Looks like working radius doesn't exceed 3-4(?) frames, but how changes threshold? Are different frames "weighted" - (nerarer frames have higher weight)?

In other word, who knows working algorithm of this filter - which parameters are changed and how when filtering level changes between 0 and 10?
 
      Top
fccHandler
Posted: Nov 22 2002, 08:37 PM


Administrator n00b


Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02



Only Avery Lee knows for sure, but here's my guesswork:

The filter creates a buffer to store the current color value for every pixel in the image (the first frame receives special handling). As subsequent frames arrive to the filter, each new pixel is compared with the old value in the buffer, and if it's not too different, the output pixel gets blended with the old value, and the buffer is updated accordingly.

The "Filter strength" value controls how much different a new pixel color must be before it is considered to be "too different."

BTW, another good filter (with lots of options) is Jim Casaburi's Temporal Cleaner.

--------------------
May the FOURCC be with you...
 
     Top
valja
Posted: Nov 22 2002, 09:48 PM


Advanced Member


Group: Members
Posts: 179
Member No.: 66
Joined: 1-August 02



Thanx for good answer, fccHandler. This filter does so good job that I thought it's more complicated - something like averaging over 3-4 consecutive frames with averaging threshold and weighting for different frames. But looks like such complicated and time-consuming algorithm is unnecessary.

Thanx also for link to another temporal filter. I will certainly play with it. Possibility of scene detection looks great.
 
      Top
fccHandler
Posted: Nov 22 2002, 10:48 PM


Administrator n00b


Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02



VirtualDub's temporal smoother probably is more complicated (for instance, what does "Lag: 4" mean?), but the source is uncommented ($@#%!) so I'm just guessing. I also suspect that a bit larger area (not just one pixel) is considered when calculating the threshold difference.

--------------------
May the FOURCC be with you...
 
     Top
phaeron
Posted: Nov 23 2002, 03:51 AM


Virtualdub Developer


Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02



Temporal smoother is a seven-frame centered, finite-response filter with per-pixel adaptive weighting. For each pixel position and for each pixel in that position in the seven-frame window, compute the 2-norm squared absolute RGB difference from the center window pixel to the current window pixel (d = |r|^2 + |g|^2 + |b|^2). Shift d right by N bits (divide by 2^N), where N is the filter power, then subtract it from 16 with clamping to zero. Compute a new vector (d, r*d, g*d, b*d). Accumulate all such vectors for all seven frames in the window, then divide the RGB terms by the alpha term to get noise reduced RGB for that pixel position in the center window frame. The alpha sum will never be zero since the center window pixel always matches itself perfectly. Finally, cycle a new source pixel into the window -- this will be three frames behind the currently output pixel. The output of the filter should never cycle back into the window, or else you will have an incorrect, recursive filter.

The source is uncommented because I basically prototyped the algorithm directly in MMX and never bothered to write a psuedocode or scalar version.

 
    Top
fccHandler
Posted: Nov 23 2002, 04:32 AM


Administrator n00b


Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02



@phaeron: Thanx for clearing things up! biggrin.gif

--------------------
May the FOURCC be with you...
 
     Top
valja
Posted: Nov 24 2002, 10:54 AM


Advanced Member


Group: Members
Posts: 179
Member No.: 66
Joined: 1-August 02



Thank you very much, phaeron. Your answer cleared things up and explains, why this filter is doing so good job - it is weighted by square deviation and in the same time has limited response.

Only thing is a bit unclear - why radius of filter is fixed to 4? Increasing of radius is probably unreasonable, but in case of noisy films with a lot of quick moves it's may be reasonable to use smaller radius and bigger strength? In other words, possibility to change radius would increase flexibility of the filter.

Avisynth's TemporalSoften has variable radius, but it has entirely another alogrithm. As I understand, it averages pixels inside radius and thresholds by luma nad chroma (without weighting), so pixels outside threshold haven't influence into output. In the VDub's filter such pixels have weighted limited influence.
 
      Top
valja
Posted: Dec 14 2002, 12:23 PM


Advanced Member


Group: Members
Posts: 179
Member No.: 66
Joined: 1-August 02



Played with different time smoother/cleaner filters and found that in most cases VDub temporal smoother is unbeatable. With one "but". In case of higher (but quick) noise, it's necessary to use higher filter's "strenght", but then bigger areas with almost the same color often looks like through "hot slowly waveing air".

Probable reason - too big radius of the filter(?). It's fixed to 3 and in case of 25fps film it covers 7 frames - 0.28 sec. May be in some cases (noise with relatively high amplitude but very quick), the filter with higher strength but smaller radius (2 or even 1) would give better results?

Adding a possibility to change radius (choises 1, 2, 3 would be enough) looks quite easy. Unfortunately I can't try it myself, haven't VC 6 yet
sad.gif
 
      Top
phaeron
Posted: Dec 15 2002, 12:19 AM


Virtualdub Developer


Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02



There are a number of concessions to implementation in VirtualDub's TS filter algorithm. By far the most critical is the divide approximation -- the weight sum is variable so the divide is not constant, and so reciprocal multiplication via a table is used. The MMX pmulhw instruction only allows multiplication by a 16-bit signed fraction from [-0.5, 0.5], and with a window of 7 the weight range is 16-112. Well, by the time you get down to 112 you're down to about 8 bits of fraction, which is especially dangerous since pmulhw truncates instead of rounding. The table is biased to squeeze out as much accuracy as possible. I believe the Avisynth version doubles the allowed window size by switching to unsigned multiplies (pmulhuw), which unfortunately require a Pentium III. One reason VirtualDub doesn't allow you to adjust the window size is that it's hardcoded into the inner loop for efficiency. Another concession is the RGB weighting -- channels are weighted equally instead of by luminance.

The two major problems with the TS algorithm are coring and sparkling. Coring occurs when you have a dark, shifting gradient fading into black, or a similar situation with a slowly changing gradient against a solid color -- what happens is that the closest parts of the gradient are locked to the solid color, giving a threshold effect around the borders. Sparkling occurs whenever you have severe scene changes at a high averaging threshold and totally unrelated pixels are averaged together -- this is caused by the lack of spatial awareness in the filter. It's not necessarily easy to fix because attempting to fix it could worsen the effect of shot noise in an otherwise steady scene.
 
    Top
valja
Posted: Dec 15 2002, 09:50 PM


Advanced Member


Group: Members
Posts: 179
Member No.: 66
Joined: 1-August 02



@phaeron: Thanx again for explanation.

What I meant, was just coring and I had hope, that the filter with smaller radius and higher strenght will work better in this case (just because of quicker response). But now I see, that it is not so simple.

Also variable radius implementation doesn't look so easy anymore. It will probably need at least own mutiplication table for every radius. Anyway, I have something to think about now. unsure.gif
 
      Top
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:
9 replies since Nov 22 2002, 08:01 PM Track this topic | Email this topic | Print this topic

<< Back to VirtualDub Filters and Filter Development