digitalFAQ.com Forums [Archives]

digitalFAQ.com Forums [Archives] (http://www.digitalfaq.com/archives/)
-   Avisynth Scripting (http://www.digitalfaq.com/archives/avisynth/)
-   -   SansGrip Filters: FluxSmooth 1.1a released (http://www.digitalfaq.com/archives/avisynth/11140-sansgrip-filters-fluxsmooth.html)

SansGrip 07-26-2004 04:37 PM

FluxSmooth 1.1a released
 
You can get it here. Source code also available, as usual.

Summary of changes:

Quote:

Changed the averaging code so that the current pixel is excluded, which produces better noise reduction. Also split the code into two different filters, FluxSmoothT and FluxSmoothST. The former does temporal-only smoothing (equivalent to setting "spatial_threshold=-1" in FluxSmoothST) and is about 50% faster. Removed Avisynth 2.0x version to tidy up the code base. Does anyone actually use it any more? My thanks to fabrice and sh0dan for the 1.01 release during my extended absence :).

Dialhot 07-26-2004 04:56 PM

:ole:

rds_correia 07-26-2004 05:09 PM

:ole:
:dunce: Great news SansGrip :!: :dunce:
First we didn't hear from you for a long while and suddenly you come back and you even give us an upgraded toy to play :)
Great having you back buddy :!:
:ole:

SansGrip 07-26-2004 05:12 PM

Quote:

Originally Posted by rds_correia
First we didn't hear from you for a long while and suddenly you come back and you even give us an upgraded toy to play :)

Well, now I have a DVD burner...

:mrgreen:

rds_correia 07-26-2004 05:15 PM

Quote:

Originally Posted by SansGrip
Well, now I have a DVD burner...

:mrgreen:

I just wish you could have bought it sooner :mnkypile: :D

kwag 07-26-2004 06:02 PM

PM received. Thanks Ross ;)
Mirror updated: http://www.kvcd.net/sansgrip/avisynth

-kwag

SansGrip 07-30-2004 01:22 AM

1.1a released today. Changes:

Quote:

Yet another "oops" release. Current pixel is once again considered in the averaging code -- I found the lack of it too aggressive, especially during fast motion. Also fixed stupid "3am bug" involving a couple of variables I'd declared static that shouldn't've been. Thanks to krieger2005 for spotting that one, and ARDA for diagnosing it.

SansGrip 07-30-2004 01:25 AM

By the way, I'm about to conduct a fairly thorough comparison between Flux and other smoothers to test compressibility, retention of detail, speed, etc. I intend to test Deen.Undot (or whichever way round it goes ;)), TemporalCleaner, TemporalSoften, and RemoveDirt.RemoveGrain. Does anyone have any suggestions for other filters I should compare against? (Must run in YV12.)

Also suggestions for methodology are welcome. At the moment I plan on using the same source material (obviously), and for compressibility this script:

Code:

Mpeg2Source("blah.d2v")
Telecide(order=1, guide=1)
Decimate()
<smoother>
ConvertToYUY2()

which I'll encode to XViD, quant 1 and note the resulting file size. To test speed I'll use this script:

Code:

Mpeg2Source("blah.d2v")
<smoother>

and run through VDub, direct video stream copy, no audio, in preview mode, to note the FPS. This should give me a pretty good idea of the speed of the filter. Retention of detail is an inherently subjective thing, so any judgements I make I'll try to back up with framegrabs. There's nothing stopping me picking frames that cast Flux in the best light and ignoring frames that show its weaknesses, of course, but I'll try real hard to be scientific about it.

Anyway, I think it should be interesting to see how the various filters perform. I have a gut feeling that Flux will be faster than most, but what will be most revealing is the compressibility and detail retention tests...

incredible 07-30-2004 02:03 AM

Hi Ross,

nice idea, ... but one question.

Why do you convert to YUY2 at the end of your script as you deal with YV12 input and YV12 output?
Would mean too much quality loss due Chromainterpolation and shure a loss of speed ;-)

EDIT:
Uops!, I do see you also intend to test compressibility and so in CCE it anyway will be converted to YUY2 or in TmpgEnc to RGB24.

Dialhot 07-30-2004 07:36 AM

Quote:

Originally Posted by SansGrip
I intend to test Deen.Undot (or whichever way round it goes ;)), TemporalCleaner, and TemporalSoften. Does anyone have any suggestions for other filters I should compare against? (Must run in YV12.)

I already testes :

1/ Undot.Deen
2/ FluxsmoothST.Undot
3/ FluxsmoothS.TemporalSoften

Speed is near the same (except for 4 that is bigger than others). Compressibility is in the related order but quality is in the reverse order !
Finalyl I encoded my jobs with 1, as always.
Note than 3 is too smooth in the end.

I didn't try Removedirt yet (works in YV12 ?)

Also suggestions for methodology are welcome. At the moment I plan on using the same source material (obviously), and for compressibility this script:

Quote:

Anyway, I think it should be interesting to see how the various filters perform. I have a gut feeling that Flux will be faster than most, but what will be most revealing is the compressibility and detail retention tests...
Deen is still faster than FluxST on my PC.

kwag 07-30-2004 09:13 AM

Quote:

Originally Posted by SansGrip
1.1a released today. Changes:

Mirror updated ;)

-kwag

SansGrip 07-30-2004 11:27 AM

Quote:

Originally Posted by incredible
Uops!, I do see you also intend to test compressibility and so in CCE it anyway will be converted to YUY2 or in TmpgEnc to RGB24.

Yup. In this instance I'm loading it into VDub to go to XViD (though I might end up using CCE). I think in either case it needs to be YUY2 and I'd rather Avisynth do it, because I trust Avisynth over whichever random filter ends up doing the conversion somewhere deep in Windows ;).

SansGrip 07-30-2004 11:31 AM

Quote:

Originally Posted by Dialhot
1/ Undot.Deen
2/ FluxsmoothST.Undot
3/ FluxsmoothS.TemporalSoften

You mean FluxSmoothT for number 3? There is no FluxSmoothS :). If so, why use TemporalSoften too? I'd say that if you want heavier temporal smoothing, use just TemporalSoften. It should smooth the pixels that Flux affects as part of that. Flux is by definition less aggressive than TemporalSoften, so using them together probably won't gain anything.

Quote:

Speed is near the same (except for 4 that is bigger than others).
Try FluxSmoothT. It's over 50% faster than FluxSmoothST.

Quote:

Deen is still faster than FluxST on my PC.
It's not on my Athlon XP 2100+ (FluxST runs about 55fps, Deen.Undot about 47fps), but I'm sure you'll find FluxSmoothT a lot faster...

SansGrip 07-30-2004 11:31 AM

Quote:

Originally Posted by kwag
Mirror updated ;)

Mucho gracias 8) .

Dialhot 07-30-2004 06:49 PM

Quote:

Originally Posted by SansGrip
You mean FluxSmoothT for number 3? There is no FluxSmoothS :). If so, why use TemporalSoften too?

Because I did it a 4am and obviously it was too late in the night : i REALLY did it thinking it was a spacial filter (that is why I added temporal after that) :o That explain a lot why it was too soft :lol:

Quote:

Try FluxSmoothT. It's over 50% faster than FluxSmoothST.
For sure but that does not do all whta I want !

My "best choice" is for the moment Deen.Undot. So I need something to compensate the temporal (and not spacial ;-)) only work of FlouxsmoothT.
The question is : what ?

Quote:

Deen is still faster than FluxST on my PC.
It's not on my Athlon XP 2100+ (FluxST runs about 55fps, Deen.Undot about 47fps), but I'm sure you'll find FluxSmoothT a lot faster...[/quote]
For sure, and no filter at all is even faster :-)

SansGrip 07-30-2004 09:14 PM

Quote:

Originally Posted by Dialhot
My "best choice" is for the moment Deen.Undot. So I need something to compensate the temporal (and not spacial ;-)) only work of FlouxsmoothT.
The question is : what ?

I don't like doing spatial smoothing on natural video (as opposed to anime, which definitely benefits from spatial smoothing). I find, to my eyes, the result too smooth. TBH I'd rather put one movie on one disc with really good quality than several movies on one disc and be forced to use a spatial smoother...

J-Wo 07-30-2004 10:13 PM

dialhot: I think you should give RemoveGrain a try as a possible replacement for Undot. Even at it's lightest setting (mode=1) it has better compression that Undot but does the same job. The default setting is mode=2. I've been using your Deen().Undot() combo in both my DVD and AVI source scripts, but recently I came across a series on DVD (Babylon 5) that had a lot of film grain and dirt artifacts. A combination of RemoveDirt and RemoveGrain did the job fantasticly. Check out my thread in the Avisynth forum please.

BTW I don't think RemoveGrain has any problem with YV12 input, despite the documentation. I loaded a DVD source no problem without any colorspace conversions (DVD is YV12, right?).

Dialhot 07-31-2004 08:46 AM

Quote:

Originally Posted by J-Wo
BTW I don't think RemoveGrain has any problem with YV12 input, despite the documentation. I loaded a DVD source no problem without any colorspace conversions (DVD is YV12, right?).

You're right.
I will try removeGrain. I already saw your post on this and that made me discovered the filter (I only knew removedirt before it).

@Sansgrip
Did you try Undot.Deen without any parameters or other filters and a lanczos resize in the script ? That's how I do my DVD to DVD jobs. I add a temporalsofter + DCTfilter in case of DVD to KVCD.

But use Lanczos, not bicubic !

SansGrip 07-31-2004 10:36 AM

Quote:

Originally Posted by Dialhot
Did you try Undot.Deen without any parameters or other filters and a lanczos resize in the script ? That's how I do my DVD to DVD jobs. I add a temporalsofter + DCTfilter in case of DVD to KVCD.

But use Lanczos, not bicubic !

Yup, just Undot().Deen(). But I don't resize when I do DVD -> DVD.

J-Wo 08-01-2004 06:43 PM

Sansgrip: you don't do an overscan/overlap to save some space?

Dialhot: I look forward to any findings you come across. I always appreciate your input on scripts -- so far they've always worked wonders!


All times are GMT -5. The time now is 12:55 PM  —  vBulletin © Jelsoft Enterprises Ltd

Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.