digitalFAQ.com Forums [Archives] - SansGrip Filters: New fluxsmooth

digitalFAQ.com Forums [Archives] (http://www.digitalfaq.com/archives/)

- Avisynth Scripting (http://www.digitalfaq.com/archives/avisynth/)

- - SansGrip Filters: New fluxsmooth (http://www.digitalfaq.com/archives/avisynth/6684-sansgrip-filters-fluxsmooth.html)

Sh0dan modded sangrip's fluxsmooth to smooth out the bug's and a 15% speed up. For more info look here http://forum.doom9.org/showthread.ph...threadid=64831 . Also Cnr2.5 was modded by him.

Thanx Sh0dan,

Great ! I really like this filter. I will try to introduce it in my "optimal avi scripts".

Thanks for the news.

I was playing with FluxSmooth a bit yesterday and discovered that if I exclude the current pixel from the average it results in slightly better smoothing (this sort of makes sense, since the current pixel is considered "noise" at that point).

Still determining what effect this has on pixels (usually those in moving areas) that are mistaken for noise. Stay tuned ;).

Meanwhile, can you please work on that point :
" Optimize SSE code with regard to pairing, stalls, and so on."

Fluxsmooth is currently one the the slowest filter I use and... in fact I don't use it just for that 8) .

Pleeeeaaaassseeee... :lol:

Quote:

Originally Posted by Dialhot

Meanwhile, can you please work on that point:
"Optimize SSE code with regard to pairing, stalls, and so on."

There's really not much more optimization that can be done on Flux. Sh0dan added memory alignment and changed one mov instruction to a different, faster kind. I'm sure an SSE expert could find another 10% or so, but I'm no expert (in fact it took me an hour or so to figure out how the SSE code -- that I wrote -- works).

Quote:

Fluxsmooth is currently one the the slowest filter I use and... in fact I don't use it just for that 8).

I don't find it that slow. On my Athlon 2100+ XP this script:

Code:

LoadPlugin("..\debug25\fluxsmoothD-2.5.dll")

Mpeg2Source("test.d2v")

Telecide(order=1)

Decimate()

Trim(908, 994)

Tweak(bright=10)

Crop(0, 0, 240, 480)

old = FluxSmooth(temporal_threshold=3, spatial_threshold=-1)

new = FluxSmoothTest(temporal_threshold=3, spatial_threshold=-1)

StackHorizontal(last.Subtitle("Original"), old.Subtitle("1.0.1"), new.Subtitle("1.0.2"))

ConvertToYUY2()

runs at full speed in Media Player Classic...

To me the speed of a filter is not as important as the results gained from it, and I think Flux does pretty well in that regard. If I could find a 2.5 version of Dust I'd happily use it. I don't care if an encode takes eight hours, because I'll be sleeping anyway ;).

I used that script to produce a Huffyuv sample of the new Flux (without current pixel included in average) against the old. I've uploaded it here, but it's 40mb so don't download if you have a slow connection :).

Look in particular at the wall behind the cat. You'll see that the new version is slightly more effective at reducing the (considerable) noise in the original. I also included a closeup of a guy's face, which I find to be one of the better ways of spotting oversmoothing.

I'd appreciate input on whether people think the slight softening the guy's face in the new version is worth the extra noise reduction seen in the wall. It certainly increases compression a bit:

Old, CCE Q1 = 52,514 bytes per frame
New, CCE Q1 = 52,278 bytes per frame

But bear in mind the clip is only 87 frames long.

(Note: The clip is a little dark, so you might want to use the "superbright" feature, if your monitor has it.)

Quote:

Originally Posted by SansGrip

To me the speed of a filter is not as important as the results gained from it, and I think Flux does pretty well in that regard. If I could find a 2.5 version of Dust I'd happily use it. I don't care if an encode takes eight hours, because I'll be sleeping anyway ;).

For sure but the new deen for instance does a pretty good job in half time and this is why I dropped Fluxsmooth for it.
(note : be carreful if you want to test deen that there is a release called "beta 1" that is form 08/2003 and is newer than beta 2 from 2002 !).

Quote:

I've uploaded it

Currently dling.

@Dialhot:

When I use Flux I always use:

FluxSmooth(temporal_threshold=x, spatial_threshold=-1)

thus disabling spatial smoothing. I find spatial smoothing often too aggressive for normal video (it's better for anime). But because of how SSE works, the spatial smoothing is done anyway even when disabled, it's just not included in the final output (it's faster that way, believe it or not). So I decided to experiment with taking out the spatial stuff completely. I figured it would speed it up a bit.

In VDub preview, direct stream copy, Flux 1.01 gives me 55fps. The new version, without spatial smoothing, gives me 75fps. Is that enough of a speed-up for you? ;)

EDIT: By way of comparison, Deen and Undot together give me 45fps.

Quote:

Originally Posted by SansGrip

FluxSmooth(temporal_threshold=x, spatial_threshold=-1)

Okay. I never did that.

Quote:

In VDub preview, direct stream copy, Flux 1.01 gives me 55fps. The new version, without spatial smoothing, gives me 75fps. Is that enough of a speed-up for you? ;)

If you can't afford better :-D

Quote:

EDIT: By way of comparison, Deen and Undot together give me 45fps.

I always use Deen + Undot OR Fluxsmooth + TemporalCleaner so the time is the same.
And now I see that you find temporal in Fluxsmooth too heavy... and I have the habit to add an other temporal after this :x.
But for my 'defense' I will say that that was my VERY FIRST SCRIPT, 18 months ago, even before to register on kvcd.net :-)

Quote:

Originally Posted by Dialhot

And now I see that you find temporal in Fluxsmooth too heavy... and I have the habit to add an other temporal after this :x.

No, I find spatial too heavy in Flux. I always turn it off. But I leave temporal filtering on.