FluxSmooth

[bond]

Originally posted by Boulder
IIRC, if the source clip is noisy, FluxSmooth will run slower..so there's a noise <-> speed -relation. thanks for your answer!

my source was the matrix dvd which shouldnt have much noise i think (i always use the same sample as doom9 in his codec comparison for testing) :(

[Boulder]

Actually, Flux is not *that* fast compared to C3D:

http://forum.doom9.org/showthread.php?s=&threadid=51181

Just remembered this good old thread. Forget what I said earlier, I'm not nearly 100% sure it was Flux that slowed down with more noise:scared:

[bond]

:(
as c3d is really slow i thought about a speed increase of 33% or so :D

as i am in filter testing mood at the moment any more filters which can be recommended for increasing compressibility whereas retaining as much quality as possible (yes i hate such questions too ;) )?

[Boulder]

TemporalCleaner (by Vlad59) is a must. The defaults give a huge compression increase and it's very fast too. It's a regular one in my scripts:)

Edit: UnDot is a good one too. Doesn't increase encoding time almost at all and yet gives more compression without losing details. I don't see why TemporalCleaner didn't score better in the tests in that thread. I often get more than 10% off the size of the sample clip encode (analog captures).

[bond]

will give it a try (i already tested undot, seems to be very nice)

thanks a lot for your help!

[JohnMK]

Boulder,

Which UnDot() parameters do you use with recent, clean hollywood DVDs such as say, Matrix?

[Boulder]

Originally posted by JohnMK
Boulder,

Which UnDot() parameters do you use with recent, clean hollywood DVDs such as say, Matrix?

The nice thing about UnDot is that it doesn't have any parameters! ;)

[bilu]

About FluxSmooth and C3D: Flux is faster on AVS 2.0x and C3D is faster on AVS 2.5x on my system. Haven't tried AVS 2.5x with YUY2 though.

I only use Deen("a3d",1,10,12) now.

Bilu

[bond]

Originally posted by bilu
I only use Deen("a3d",1,10,12) now.
hm these settings seem to blur too much...

i think i will stay with TemporalCleaner(3,6) and UnDot (before TC and used only once, doesnt seem to make a difference if used twice)

hm pretty much the same as boulder suggested :)

[JReiginsei]

In the C3d Readme it says this for the Avisynth 2.5 version:

Know problem :
- works only with YV12
- Temporal influence currently disabled.

Since the temporal influence is disabled, thats why its faster than the C3d for Avisynth 2.0x, right?

[Boulder]

Originally posted by bond
i think i will stay with TemporalCleaner(3,6) and UnDot (before TC and used only once, doesnt seem to make a difference if used twice)


Lately I've used FluxSmooth with temporal processing disabled and then TC after that for my analog TV caps. I haven't tested how much difference it would make to use TemporalCleaner alone but I believe that slight spatial processing won't hurt, especially when SansGrip told that the filter keeps the details quite well with low thresholds.

This is the filtering I do:


UnDot()
FluxSmooth(-1,7)
TemporalCleaner()


I compared the compressibility a while ago and found out that a spatial Flux with TemporalCleaner compress *a lot* better than FluxSmooth with high temporal thresholds and with no TemporalCleaner. FluxSmooth(15,7) resulted in ~5% larger filesize than that filtering I wrote above. I'm also sure that a temporal threshold of 15 could cause some ghosting easily.

[bond]

Originally posted by Boulder
Lately I've used FluxSmooth with temporal processing disabled and then TC after that for my analog TV caps. I haven't tested how much difference it would make to use TemporalCleaner alone but I believe that slight spatial processing won't hurt, especially when SansGrip told that the filter keeps the details quite well with low thresholds.that would cause a drop in speed again, i think?
can it cause problems if i dont do spatial filtering (on clean dvd sources) only temporalcleaner?
is it possible to say which one compresses better, spatial or temporal? and which one is better to keep details? (of course that also depends on the settings)

[bilu]

I used TemporalCleaner before Deen("a3d") but not anymore, on quick panning scenes TemporalCleaner did ghosting even with settings like

TemporalCleaner (ythresh=5, cthresh=5)

which are lower than defaults.

The movie that made me stop using it was The Abyss. I was making tests over the second chapter, when a sub gets on fire after hitting a rock.
It has some scenes with fire plus a earth-quake like panning. And some parts of the scene had very few colors, like a guy screaming something in the dark behind a sort of shower device during the fire. Those parts got a lot damaged even using TC alone.

Deen("a3d",1,10,12) is the default of Deen("a3d"), with the same spatial and temporal settings as Deen("c3d"). But it seems a lot more cleaned, but not blurred, almost like being seen through some sort of mask.

The main reason I stopped using Flux in 2.5 was the speed, it was slower than C3D or Deen, while in 2.07 was faster.


Bilu

[Boulder]

Originally posted by bond
that would cause a drop in speed again, i think?
can it cause problems if i dont do spatial filtering (on clean dvd sources) only temporalcleaner?
is it possible to say which one compresses better, spatial or temporal? and which one is better to keep details? (of course that also depends on the settings)

The speed decrease is small but noticable. However, I like the extra compression so I don't mind;)

Usually temporal filtering compresses better IMO and keeps details better too. Excessive spatial filtering will kill details and excessive temporal filtering causes ghosting. FluxSmooth's default parameters should keep the details intact, I think SansGrip had that in mind when he decided them.

@bilu: I don't mind slight ghosting as I do MPEG-1 encodes and view them on my TV. I can't notice any ghosting with the default TC parameters myself.:)

[bond]

hm i searched the forum for a defintion of "ghosting" but didnt find a good one (seems that everyone who suffers ghosting knows that it is ghosting when he sees it)
how does ghosting look like? can i find a screenshot somewhere?

[Boulder]

You can usually notice ghosting when there's a dark background and someone's moving in front of it. Encode such a scene with a high temporal threshold and see if any ghosting appears.

[High Speed Dubb]

“Ghosting” (as used on this forum) means that part of an earlier or later frame shows up in the current frame. It’s usually caused by a temporal smoother with overly permissive parameters.

You do need to be careful using the term, though. “Ghosting” also has a different meaning with broadcast video -- It refers to a spatially displaced image superimposed on the main signal.

[SansGrip]

I just threw together a new version of FluxSmooth, in case anyone other than me is still using it ;).

You can get it here (http://www.indeus.com/sansgrip/avisynth/). The source code is available, as usual.

Major changes:

* Improved noise reduction.
* Split into two different filters, FluxSmoothST and FluxSmoothT. The former, as with previous versions, does (by default) both temporal and spatial filtering. The latter does only temporal filtering, and is about 50% faster.
* Removed Avisynth 2.0x version.

I would be grateful for feedback on the (slightly) improved noise reduction and the (greatly) enhanced speed of FluxSmoothT.

Here's a snippet from the readme:

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 :).

[Wilbert]

Sorry for the OT post, but great to see you back!

[SansGrip]

Thanks :).

I have a couple of ideas for filters, hopefully I'll have the time to implement them. I'm very intrigued by the motion estimation toolkit. Need to read more about it, though.

[yaz]

heya sansgrip ! welcome back !! :-)))

Originally posted by SansGrip
I just threw together a new version of FluxSmooth, in case anyone other than me is still using it ;)i wouldn't take even a single step without :-))Originally posted by SansGrip
... FluxSmoothST and FluxSmoothT ... The latter does only temporal filtering, and is about 50% faster.whoops ... it'd never been so slow in 'temp-only' mode. btw, are you aware of sh0dan's improvements made on 'flux' in the meantime ? are that changes kept or left ?Originally posted by SansGrip
I would be grateful for feedback on the (slightly) improved noise reduction and the (greatly) enhanced speed of FluxSmoothT. i'm about it :-)
thx
y

[SansGrip]

Originally posted by yaz
heya sansgrip ! welcome back !! :-)))

Thanks :).

it'd never been so slow in 'temp-only' mode.
I'm not sure what you mean here. Flux was never really slow (I get about 55fps on my 2100+ XP), but since I always disable spatial smoothing anyway I thought I'd try commenting it out of the code. It ran at over 75fps, so I figured it was worth keeping a temporal-only version :).

btw, are you aware of sh0dan's improvements made on 'flux' in the meantime ? are that changes kept or left ?
fabrice's memory leak fix and sh0dan's speed improvements are still in this new version.

[krieger2005]

Hi

can FluxSmooth only one time used in a script? I used this Script:

a=FluxSmoothST(7,22)
b=FluxSmoothST(7,7)
return subtract(a,b).colorYUV(autogain=true)


and get a grey screen. When i use a or b in the script the look different.

greets
krieger

[SansGrip]

Um... I see no reason why it couldn't be used twice. What does that script meant to do, out of interest?

And are you running it in YUY2 mode? If so, that's definitely suboptimal. Flux is twice the speed in YV12.

[krieger2005]

I used the Script in YV12. First i used the Filter twice in the script to see the Difference of spatial smoothing:
Interleave(FluxSmoothST,FluxSmoothST(7,22))

But i does not see any differences. I tured 22 to 53 and there were still no diferences (with the script above). Then i used FluxSmoothST only one time: with parameter (7,7) and (7,22) and i could notice differences. The i tried to use the both again and had the Result of one of them (the first of them).

Then i posted this problem here...

When no one has this problem, that maybe i does something wrong and must search...

krieger

[SansGrip]

That's odd. I have no idea what could be causing that problem. I'll try to duplicate it.

[ARDA]

First of all welcome back.
quote:
----------------------------------------------------------------------------------------
That's odd. I have no idea what could be causing that problem. I'll try to duplicate it.
-----------------------------------------------------------------------------------------
I must confess I did't do any test; but I think the following static variables
are the problem .You should change them for just constant. But you won't be able use ebx
register (at least with c++ 6.0 )in your DoFilter_MMX assembler code.

__declspec(align(16)) static const __int64
#ifdef DO_SPATIAL
spat_thresh = ((__int64)spatial_threshold << 48) |
((__int64)spatial_threshold << 32) |
((__int64)spatial_threshold << 16) |
(__int64)spatial_threshold,
#endif
temp_thresh = ((__int64)temporal_threshold << 48) |
((__int64)temporal_threshold << 32) |
((__int64)temporal_threshold << 16) |
(__int64)temporal_threshold,

I hope that can be usefull .ARDA

[Leak]

Originally posted by ARDA
But you won't be able use ebx register (at least with c++ 6.0 ) in your DoFilter_MMX assembler code.

That's strange - the VC++ 6.0 docs state:

When using __asm to write assembly language in C/C++ functions, you don't need to preserve the EAX, EBX, ECX, EDX, ESI, or EDI registers.

so why wouldn't you be able to use ebx?

Works for me...

np: T.Raumschmiere - Substrom (Anti)

[ARDA]

Maybe my visual c++ has a problem; but if I declare a non static variable in a void function (as DoFilter_MMX of fluxsmooth is)I always get a warning when ebx is used in assembler code inside this function; and in all cases I get a crash.
Forgive in advance if that is not a general rule; but it always happens to me.

Thanks ARDA.

[Leak]

Originally posted by ARDA
Maybe my visual c++ has a problem; but if I declare a non static variable in a void function (as DoFilter_MMX of fluxsmooth is)I always get a warning when ebx is used in assembler code inside this function; and in all cases I get a crash.

That's strange... could you try compiling my BlendBob plugin (it's just one source file + 2 header files and the AviSynth.h) on your system? The function LumaDifferenceHistogram_MMX makes extensive use of ebx and works just fine. Also, if you push ebx at the beginning of your asm blocks and pop it at the end it really shouldn't be a problem; after all, the compiler can't make use of it inside your asm block... :confused:

It's probably a compile setting or something that causes your problems - I must confess that I've stolen the compiler settings I use from Donald's Decomb... :D

[ARDA]

You're right; no problem at all to compile you plugin.By the way it looks a good job at first impression,still didn't test.
There is no difference in settings,the problem is probably in the structure of some of my tests;in many cases I have all classes functions in same cpp without headers and extern definitions.
I'll study that more and post maybe in another moment not to be off topic.
Coming back to fluxsmooth still think the static variables (compilation time) are the problem for several calls.

Thanks.ARDA

[SansGrip]

Yes, I imagine that's the problem. I always forget only one instance is created. I made those static (at about 3am ;)) because of the compile problem you mentioned wrt ebx, but it didn't occur to me that it might screw something up.

I'll make a new release, probably tonight.

Thanks :).

[SansGrip]

New release, 1.1a:

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.

Available here (http://www.indeus.com/sansgrip/avisynth/).

[Dali Lama]

Hi SansGrip,

Nice to see you here again. Yes, I have been using FluxSmooth, and interestingly enough, I only use its temporal portion. Thanks for improving the noise reduction and making a fast temporal version (as if the original wasn't fast enough ;) )

In a quick comparison, I cannot see much difference in noise removal from v1 to v1.1a in anime material.

Oh and make sure you check out kurosu's MVDenoise. Its a very good and relatively fast motion-compensated temporal noise remover.

Thanks,

Dali

[SansGrip]

Originally posted by Dali Lama
In a quick comparison, I cannot see much difference in noise removal from v1 to v1.1a in anime material.
That's good -- there shouldn't be any ;). The "improved noise reduction" was flawed and I removed it from the most recent release. The only benefit of using 1.1a is that temporal-only smoothing is much faster with FluxSmoothT().

Oh and make sure you check out kurosu's MVDenoise. Its a very good and relatively fast motion-compensated temporal noise remover.
I will -- thanks.

[Fizick]

Kurosu is a great man,
but I think, Manao is the author of MVDenoise
Or there are a lot MVDenoises ? :)

[Dali Lama]

You're right Fizick. Sorry Manao.

Thanks for that clarification SansGrip

-Dali

[Boulder]

SansGrip,

FluxSmoothST seems to get very slow with CCE if the filter is placed before resizing. I've got a 720x480 AVI clip and I tried to make a compressibility test with QCCE, the script is like this:


AVISource("c:\temp\test.avi",false)
FluxSmoothST(temporal_threshold=-1,spatial_threshold=7)
BicubicResize(656,304,0,0.6)
AddBorders(24,136,24,136)
ConverttoYUY2()
AssumeFPS(25.000)
SelectRangeEvery(500,15)


1) When I try to encode this with CCE, it takes a very long time. If I load this in VDub, it's not at all that slow. If I then move FluxSmoothST right after resize, CCE is as fast as ever, no slowdowns whatsoever.

2) If I add the line Crop(2,2,636,268,align=true) or with align=false, right after the AVISource line, there is no slowdown.

3) If I encode the same script without the sampling line (SelectRangeEvery), encoding time is almost the same with Flux before or after the resizing part.

I also remember having this problem with the earlier versions as well. I also tested it on several AVI clips and they all give similar results.

[sapient]

Where can I download the latest version... The link a few posts above is dead...

[Wilbert]

http://www.avisynth.org/warpenterprises/

[nomonhan]

The link
http://www.avisynth.org/warpenterprises/
is dead

[Reel.Deel]

The link
http://www.avisynth.org/warpenterprises/
is dead

http://avisynth.nl/index.php/FluxSmooth

Also the first link in Google search.