New Filters: TTempSmooth and TBilateral

[tritical]

Well, I started a little project a few days ago, which I've been planning for a long time, to make a mod of SmoothHiQ (for YV12 and a few algorithmic changes) and this is where it ended up. My changes to SmoothHiQ yielded almost no quality difference, but succeeded in making it 5 to 10 times slower. At which point, I thought why not make a temporal filter based off it. The result was TTempSmooth. It uses the same weighting/averaging as SmoothHiQ, but in the temporal domain. It processes the chroma/luma planes together when testing for pixel similarity, but separately when computing averages. It also uses a 2 frame distance pixel difference test aside from the single which helps to avoid some artifacts. Surprisingly, it is not really all that slow. It is not as fast as TemporalSoften though.

TTempSmooth v0.9.4 (http://www.missouri.edu/~kes25c/TTempSmoothv094.zip)

While I was doing that I started looking into bilateral filtering. It is a very similar inverse distance and inverse pixel difference weighting algorithm, but is slightly more complex. From that came TBilateral. It's a spatial smoother that uses the bilateral filtering algorithm. It is very good at smoothing out noise while maintaining picture structure. I didn't have time to test it extensively (more then to make sure it was working) thus the defaults aren't set very well. Speed wise this filter is roughly equivalent to SmoothHiQ... though maybe a little faster?

TBilateral v0.9.11 (http://www.missouri.edu/~kes25c/TBilateralv0911.zip)

[tritical]

No replies... I love making useless filters :D. The defaults for TBilateral seemed to be not so bad though maybe a little on the conservative side. After looking over the code again I noticed there was a little problem with the calculations of boundary pixels near the edges of the image. Pixels in those windows were getting incorrect spatial weights from the lookup table. I posted a fixed version 0.9.1 that now has these defaults:

(7,5,2.0,7.0,2.0,7.0)

I could speed up the filter a little more by unrolling the xloops to avoid unneeded boundary conditions in the interior. Might try and do that later.

[MfA]

BTW there is a way of efficiently implementing the bilateral filter without a LUT, although it is a bit of a severe hack :)

You can do an approximation to the exponential function by interpreting the exponent as the exponent part of a floating point number and doing a float->int conversion. Dunno if it represents a speedup though, you can only do 2 conversions at a time with SIMD so that doesnt buy you much ... depends on the throughput of the lookups.

[Dali Lama]

Hi tritical,

I tried out both filters and I am very impressed with TBilateral. It was more than comendably fast for smoothing chroma abherations and luma blocking at radiuses as high as 13. It does indeed preserve edge detail in the process. I tested it on anime/cartoon content.

On the other hand, TTempSmooth was good, but not up to the level of Dust (faerydust). It was able to remove substantial noise and not ghost at the default settings, but even when I cranked up the settings, it could not remove as much noise as Dust, especially in movement. Perhaps you could try allowing more powerful smoothing? Its really not a bad filter, but in a short test on anime and regular footage it could not overcome Dust.

Thanks a lot for both filters. If you want some more objective results I can post pics for you.

Take Care,

Dali

[tritical]

@Dali Lama
Thanks for the feedback. I'm not too surprised by the results you got with TTempSmooth. It would never be able to compete with faerydust (especially on moving areas since it is designed not to touch them :D). faerydust uses ME to do temporal smoothing on moving areas (even though it is a temporal smoother it also does light spatial smoothing as well I think). TTempSmooth is a simple fixed position smoother like TemporalSmoother, TemporalSoften, etc... After I played around with it more it seems the averaging/smoothing didn't turn out exactly how I thought it would. Though the motion detection works well. I may have to go back to the drawing board on that one and experiment with some different methods. I might try to combine it with TBilateral and make a motion adaptive smoother.

@MfA
I looked into that alternative approach to a LUT. Actually, I searched doom9 for bilateral and it turns out that someone had already coded a bilateral filter, and used that method :o. After looking at it I have no idea whether it would be faster then the LUT method. I didn't/don't plan to do an asm version of TBilateral though, and the LUT is easier for me to get right without messing something up :p. I'll probably just stick with it.


P.S. Posted version 0.9.2 of TBilateral, I unrolled some of the inner loops to avoid boundary calculations and checking, giving a slight speed gain.

[DarkNite]

I might try to combine it with TBilateral and make a motion adaptive smoother.

We can never have too many of those. ;)

I too was impressed with TBilateral's ability to maintain edge detail while helping compression a fair bit more than I expected from looking at the effect in preview.


And now, every filter authors favorite things, questions!

Are their plans for further development of TBilateral, or is the featureset locked and you're just tweaking it now?

What papers did you find the most useful when implementing a bilateral filtering algorithm? I've never read into this method seriously, but now my curiosity is piqued. :)

[tritical]

Well, the reason TTempSmooth was so bad was there was a more then major bug that I have no idea how I missed. It was keeping it from doing anything useful at all. I'll post a fixed version here in a second with just the needed change. I still can't believe I was that dumb. Anyways, I also experimented more with different and faster weighting/blending schemes that seem better, but I don't have a fully working version of any of them yet.

@DarkNite

This paper:

http://www.cse.ucsc.edu/~manduchi/Papers/ICCV98.pdf

And here is a paper suggesting some improvements such as using an alternate kernel and replacing the mean with a weighted median. Also, the second section of this paper shows the formula for the regular bilateral filter in a little bit easier to see notation (at least for me).

http://dsp7.ee.uct.ac.za/~jfrancis/publicationsDir/PRASA2003.pdf

As for further development... as a straight bilateral filter I would consider it pretty much finished except for a little tweaking, though I might try implementing some of the suggested improvements.

[Boulder]

Regarding quality and compression, how would TTempSmooth differ from TemporalSoften or ye olde TemporalSmoother (YUY2 only)? I'm interested in playing with your filter on my TV caps (as soon as you get the fixed version out;) )

[MfA]

Computing a mean of 25+ values per pixel is already a lot of work though.

Making Bilateral filtering suitable for impulsive noise is nice ... but IMO one of the biggest downfalls of Bilateral filtering is that its noise removal ability takes a nosedive on gradients. Michael Elad says an efficient variation which works well on piecewise smooth images exists, unfortunately he never describes the actual algorithm ... and deriving it is beyond my skills.

http://www.cs.technion.ac.il/~elad/Journals/08_Bilateral_Filter_IP.pdf

[You Know]

very good filter it work great on noise old Anime (Asterix).

On standard settings it work better than eDeen soft settings
eDeen(2,9,11,3,4) and it don't destruct backgroud detail.

Only a disadvantage.....it's twice slow than eDeen (2.2fps vs 5fps) :°(

@MfA
interesting pdf

[tritical]

@MfA
Thanks very much for that link. I had read something very much like that, but it was only bits and pieces of it as part of a powerpoint file. After reading that paper the improvement for handling piecewise linear signals makes sense. As I understand it, when you calculate the intensity difference you use (assuming (0,0) is the upper left of the current filtering window):

cP = center pixel
tP = current position pixel
abs(cP - average(tP,inv-tP)) instead of simply
abs(cP - tP)

where inv-tP is the inverse position inside the filtering window. Say current position is 0,0 then inv-tP would be n,n. Anyways, I could be far off. This approach would definitely improve filtering for gradients and the like that fit the piecewise linear model. However, it would tend to hurt filtering of actual sharp edges. Whether the improvement would be worth the trade off in "normal" video I don't really know. The nice thing is that the spatial weights stay the same. The down side is that it means more calculations will have to go inside the inner most loops. I'm gonna try it in a bit.

[MfA]

I kind of doubt that would be the result of actually performing what Michael Elad suggests (using the new penalty function, applying the jacobi iteration, choosing the weights etc). Not that Im gonna do that.

What you suggest wouldnt really be slower though, since you can skip the weight determination for half the pixels (the weights become pointwise symmetric due to the averaging).

BTW to increase the performance on impulsive noise you can also include an extra weight for the center pixel (the smaller the weight for the center pixel the more resistant against impulsive noise the filtering becomes). SUSAN denoising didnt include the center pixel at all for instance, ie. a weight of 0 with the above scheme, of which Bilateral filtering is really only trivial variation (the inventor of bilateral filtering was apparently not aware of how close it was to SUSAN denoising though, he never mentioned it at any rate).

[tritical]

Hm, the new penalty function for the piecewise linear handling that he proposes is simply one that uses the second derivative instead of the first. As he says in the paper that is the only thing that changes, and by looking at the formulas he gives for the new filter coefficients that average is how he calculates it. Also, even though the diffs inside the filtering windows would then become symmetric it wouldn't be possible for me to calc them once and reuse them unless I store them. That would probably be slower, or at least not much faster, then just calcing them a second time since it's just an add and shift. The other part about speeding up the filter seems only to deal with the case of speeding up multiple iterations, which I'm not even considering doing multiple iterations.

Adding an extra weight for the center pixel sounds interesting. I didn't know it was so close to SUSAN denoising either, probably because I've never heard of SUSAN denoising :D .

[MfA]

It is the lookup which hurts you, not the averaging ... anyway there is nothing to store, you can just multiply the final weight with (tP + inv-tP) and only work on half the pixels. It should be faster in the end.

Dunno if dropping the LSB on the difference is a problem, might want to use abs(2*cP - (tP + inv-tP)) as an index instead and change the LUT accordingly.

[tritical]

Dunno if dropping the LSB on the difference is a problem, might want to use abs(2*cP - (tP + inv-tP)) as an index instead and change the LUT accordingly.

Actually, the abs(2*cP - (tP + inv-tP)) is exactly what I was thinking to use as the reference for the diff LUT, since that would fit with how it is currently set up.

[tritical]

Posted version 0.9.3, it now has the option of using the second derivative instead of the first. It is definitely better at filtering smooth gradients. Interestingly, it doesn't effect large gradients as much as I thought it might. It really only effects small gradients (actual edges that don't have a large difference) and tends to blend them more, though I guess that was too be expected. The effect was rather subtle on the video I tested it on, a couple rather new anime sources. I also added a center weight modifier. Probably not exactly what MfA had in mind, but it gets the job done. After the spatial weights LUT is made the centerScale/centerScaleC factors are multiplied to the center pixel weight, so giving a value of < 1 gives it less weight then normal, giving a value > 1 gives it more weight then normal, and a value of 0 makes the center pixel have no weight.

Also posted that fixed version of TTempSmooth. Now it actually works, though it still isn't quite what I had in mind. I can't figure out exactly how it should work, which is a rather big problem :D .

[tritical]

Posted version 0.9.4 of TBilateral. I was in too much of a hurry when adding the d2 option to 0.9.3 and forgot all about the rounding error from how I was calculating the average when d2=true. It could have ended up changing final pixel values by +-2. On the plus side, the fix also sped up d2=true processing by 10-15% on my computer. It is still slower then d2=false, but not nearly as much as it was.

[Malevolent]

@ tritical:

I tried TBilateral (0.9.4), and it looks good,
but when i started experimenting, i got an error msg that appears when i insert iDevC to the parameters list (with whatever value):
"Script error: The named argument "iDevC" to TBilateral had the wrong type"

Here's the line used:
TBilateral(Diameter=7,DiameterC=5,sDev=2.0,sDevC=2.0,iDev=7.0,iDevC=7.0,Chroma=True,D2=False)
If i remove iDevC, it works fine. Any ideas what's wrong?

[tritical]

The problem was that I accidently had an i instead of an f in the param's list for iDevC. So it was only accepting integers. Fixed that and posted v0.9.5.

[You Know]

tryed 0.9.4 no gain speed, i think produce only better result?

[tritical]

That was versus d2=true with v0.9.3? That's strange, I still get that v0.9.4 is 10-15% faster with d2=true then v0.9.3 with d2=true (on my computer with all the other settings at default). Also, v0.9.4 and up should give technically more accurate results when d2=true then v0.9.3. As for when d2=false, which is what it is on by default, there wouldn't be any difference at all between that in v0.9.3 and v0.9.4, and it would be exactly the same as normal operation in v0.9.2.

[You Know]

I have not use d2=true because i have not seen this new parameter...

Standard setting are best for my job...I work only on anime

I reading that "d2 set on false work better for uniformly colored areas with sharp edges", so i think I do not never test think parameter.

I have P4 HT 2.4GHz 800BUS

[DarkWave]

hi,

i´m encoding an old film atm using your bilateral-filter.
after doing lot's of test using different parameters i was wondering, which ones will be the best for non-animé film...

i already tried all params including default, 5/3, 3/1, with and without D2=true/false, but the final results all still had some kind of oil-painting effect...

tried this one on an old disney-movie - great :p

DW

[tritical]

Actually, I haven't tested it on anything but anime, and anime sources are about all I have. I'll see if I can find something else to test it on later tonight, though I wouldn't really have much to suggest that you haven't tried I don't think. First thing would probably be decreasing diameter/diameterC down to 3 and work from there adjusting the sDev/iDev settings. If you get the oil painting effect even with low sDev/iDev settings with a diameter of 3 there probably isn't a whole lot else to do. It may just not work that well on non-anime/cartoon sources.

[MfA]

Yeah, that was my problem with it too originally ... which is why I didnt pursue making it a little more practical.

Since you made a decently fast C version, Im just tinkering with my templated version making a REALLY slow version using gamma corrected luma (not really accurate, but if I go to RGB it will become as slow as a mf script) to see if that helps.

[tritical]

Gonna dig up this thread after almost a year :). Actually, I was trying to use TBilateral a few days ago, for the first time in about a year, and decided there needed to be an easier way to tweak the settings. Thus, I added a gui with preview. Also, there was a bug with the sDev and iDev settings being switched when calculating the weight tables. Anyways, v0.9.6 is linked in the first post.

The gui interface does have a few limitations, diameterL/diameterC are limited to a maximum of 21 when using the gui and the Dev settings also have maximum's but those should be plenty high unless you want a complete super blur. If anyone needs higher diameter settings in the gui I can increase them, but by 21 its going slow enough to be almost unusable... at least for me.

[Kagura]

In general, I've found that tbilateral maintains great edge structure and detail. However, it turns out that around the edges is where most of the noise is found! Thus, tbilateral misses some of those. =(

[tritical]

Thought I'd bump this thread for v0.9.8 of tbilateral (linked in the first post), since I missed v0.9.7. It implements quite a bit of new stuff mentioned in this thread: http://forum.doom9.org/showthread.php?t=94910 (ppClip; use a pre-processing step via an external filter), and from this thread: http://forum.doom9.org/showthread.php?t=96015 (kernS, kernI, resType; new selectable kernels and new selectable methods for obtaining the final value). The gui has also been redone slightly to accommodate the new options.

[tritical]

Another bump. After almost exactly one year since the last version, I've made a new version of TTempSmooth, v0.9.3. It adds scenechange detection (isse optimized, no speed cost compared to the normal speed of ttempsmooth), a visualize blur option, debug output, and a strength option to adjust spatial weighting in the same way as mdiff does for difference weighting. I switched from having it use a maximum diameter to a maximum radius which can now be set to anything from 1 to 7 (the previous limit via maxd was equivalent to a range of 2 to 4). Even with all the changes, the default values are mainly the same... except for lmdiff/cmdiff being 2/3 instead of 3/4. Thus, results with default values should be almost exactly the same as v0.9.2 except for some difference around scenechanges.

TBilateral also went up to v0.9.10 a couple weeks ago (the last version giving a 10-15% or so speed increase).

Both filters are linked to in the first post of this thread.

[E-Male]

i'm low on time, but i'll check ttempsmoth ASAP, liked it's results

[Fizick]

Tritical,
It seems you waited until Wilbert add ttempsmooth 0.92 documentation to avisynth manual to make it obsolete. :)

[tritical]

Nice timing huh? :p

Actually, I like the look/style of the html based help files enough that I am planning to replace the current .txt help files. I am in the process of updating/reorganizing/fixing those docs... I have most of it done except for this new version of ttempsmooth and the 3 bigger doc files (tdeint, tfm/tdecimate) which are taking some time. I told Wilbert that I would try to keep them up to date so using them as my actual help files should make that process much easier.

[Fizick]

I think, that it will be very useful, if somebody write documentation, how to write plugin html documentation (may be in SimpleSample thread, so SI may be ? :)

[mg262]

I think, that it will be very useful, if somebody write documentation, how to write plugin html documentation (may be in SimpleSample thread, so SI may be ? :)That sounds like a very good idea to me. Perhaps also a template HTML file so that the documentation for different filters would be organised similarly and/or have a similar look? (I'm not suggesting that anyone be forced to adopt it.) I think dgdecode.HTML that comes with version 1.4.0 looks very nice myself, the only caveat being that it's possibly a bit too much information for one file.

[Wilbert]

I will look at this when i'm back from holidays.

[tritical]

Heh, never did update any docs... I am still planning to do it eventually :D.

Anyways, I noticed a bug in v0.9.3 of ttempsmooth and previous versions... it doesn't handle interlaced yv12 input correctly. It works internally on point upsampled 4:4:4, and it was treating all input as progressive which would lead to chroma lines 0 and 1 being assigned to lines 0/1, 2/3 instead of 0/2, 1/3 of the 4:4:4 frames for interlaced yv12. That doesn't effect the temporal averaging, but screws up which pixels pass the motion checks because the luma and chroma motion thresholds are checked together when deciding what pixels to include in the average. Therefore, I made a new version (v0.9.4) (link in the first post) with an "interlaced" parameter and a couple other modifications... changes:
+ Added interlaced parameter (fix incorrect interlaced yv12 chroma handling)
+ Added pfclip parameter
+ Added MMX scenechange routines (for those that don't have an isse capable cpu)
- Changed default scthresh value to 12.0
The pfclip parameter is like ppClip in TBilateral... it allows you to specify a separate clip to use for calculating pixel differences (motion checks, scenechange detection, and inverse difference weighting). The weights calculated with the pfclip values are then applied to the original input clip's pixel values when calculating the output.

[hartford]

Thanks.

Thought that the "weird" settings that I used was some misunderstanding on my part.

Now I'll need to "disabuse" myself of that :)

[Didée]

The pfclip parameter ... allows you to specify a separate clip to use for calculating pixel differences
Yippieh! Thanks! (Gonna try LTbS outa R24 for that.)

[yaz]

vouw ... thx a lot ! best gets even better :D

thx
y

[tritical]

I am considering changing how pfclip works to be exactly like ppClip in TBilateral, but a little explanation is needed first...

In TBilateral each pixel in the filtering window gets assigned a weight based off two things 1.) distance from the center pixel 2.) difference between it and the center pixel... the filtered value is simply the sum of pixel*dis_weight*diff_weight for all pixels in window. Using this method, the center pixel itself always gets the same amount of weight (and the largest) because its difference is always 0 and it's distance is always 0 (though in my implementation its distance weight is the same as that of its four nearest neighbors). ppClip changes how the pixel difference weights are calculated. Instead of using the original center pixel value to compute differences, the corresponding (location wise) pixel value from ppClip is used instead. Now when the difference weights are computed, each pixel inside the filtering window on the original clip is tested to see how different it is to the ppClip pixel and not the center pixel. In this scheme it is possible for the center pixel to get almost no weight if its value is significantly different than the corresponding value in ppClip, and it is also possible for the other pixels in the window to get large weights even if they are significantly different than the center pixel.

TTempSmooth works pretty much the same way as TBilateral, but in the temporal domain, with different weighting functions, and it searches from the center out (stopping when it finds a pixel not passing the motion test) instead of always including every pixel in its filtering window. Currently, when pfclip is specified, all motion tests and pixel differences are computed on frames from the pfclip (no pixels from the input clip are used). That means that the pixel differences are between the neighbor frames and the center frame of the pfclip. The weights computed via using the differences and motion checks from the pfclip frames are then applied to the pixel values from the original input clip frames in order to compute the final filtered value.

In order to work the same way that ppClip in TBilateral does, the motion tests and pixel differences should not test between pfclip frames, but should test the difference between the original input frames and the center frame of the pfclip. A problem arises though from the center out search method... what if a center frame pixel no longer passes the motion test? In my mind it doesn't make sense to include the center frame pixels as part of the outwards search, thus the solution would be to always test the immediate neighbors regardless of whether the center pixel passes. Another problem is that it is possible for the pfclip pixel to not be within threshold of any of the input clip pixels (all pixels get zero weight)... in such cases the original input clip pixel would be used as is.

I am not sure which type of operation is more useful, but unless someone objects I'm gonna post a new version tommorrow that works as described in the last paragraph above.

[You Know]

i think you should modify IDC_IKERND Data->Type from DropDown to Drop List of the TBilateral GUI.

:D

[tritical]

Done. TBilateral v0.9.11 (http://bengal.missouri.edu/~kes25c/TBilateralv0911.zip), changes:
+ added resType 3, MLR (multiple linear regression)
+ some internal changes and code cleanup
- fixed a problem with the sse2 yuy2 packed to planar and planar to packed
conversions that could sometimes (very rarely) cause crashes with
yuy2 input
- fixed IDC_IKERND combobox being set to dropdown instead of dropdownlistresType = 3 takes the weights and pixel values from inside the filtering window and does a best plane fit to the data. It then gets the final value from the plane equation. A paper I read said that it should fix the stairstepping problem that neighborhood filters (using a plain weighted average) sometimes produce. However, I didn't see much if any difference and it is about 50x times slower than a weighted average. For stability reasons it uses singular value decomposition to find a matrix inverse which makes it even slower.

[flebber]

I was reading the documentation for Tbilateral and it refers to a paper for documentation here http://dsp7.ee.uct.ac.za/~jfrancis/publicationsDir/PRASA2003.pdf. Which was about this kernS/kernI - (domain (spatial) and range (intensity) kernels)

These specify what kernel is used for the domain (kernS) weights and range (kernI) weights. The
possible choices are:

0 - Andrews' wave
1 - El Fallah Ford
2 - Gaussian
3 - Huber’s mini-max
4 - Lorentzian
5 - Tukey bi-weight
6 - Linear descent
7 - Cosine
8 - Flat
9 - Inverse

See the following paper for a description of all the kernels and their properties:

http://dsp7.ee.uct.ac.za/~jfrancis/publicationsDir/PRASA2003.pdf

The link is dead perhaps long dead not sure, I know its a long shot but does anyone have these docs or have another link. Yeah I know its a long shot but I thought I should ask.

PS a belated thanks Tritical for Tbilateral, I really enjoy it works great.

[tritical]

Found it here:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.9.3815

[flebber]

Found it here:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.9.3815

Thank You

[bcn_246]

Trying to load TTempSmooth v0.9.4 with AviSynth+ v2508 (x86)... keeps throwing up the following error:

http://i.imgur.com/Bx4iy0y.png

Any ideas guys?

[Groucho2004]

Trying to load TTempSmooth v0.9.4 with AviSynth+ v2508 (x86)... keeps throwing up the following error:

http://i.imgur.com/Bx4iy0y.png

Any ideas guys?
Run "AVSMeter -avsinfo", see if that throws any error.

[GMJCZP]

Sorry if I'm interfering, Groucho, would not it be possible for you to do your magic with these plugins?

[bcn_246]

Just checked, seems to be some kind of issue with how many plugins I have... don't want to muddy this thread so I have started a new one (https://forum.doom9.org/showthread.php?p=1814887#post1814887)

[bruno321]

Has somebody made a 64-bit DLL of TTempSmooth? Thanks in advance.

EDIT: Yeah ok I found it here https://forum.doom9.org/showthread.php?p=1821762#post1821762 ; this is not a totally useless post, I guess it's useful to have it linked in the original TTempSmooth thread :)