FluxSmooth

[lamer_de]

I tried it on The Simpsons TV Caps, and the results were very promising. I have those SVCD Rips and re-encode them to XVID, but the original MPGs have dot crawl all over which is ultra-annoying. I can't use GuaveComb cause of the source format, so i used wnr till now. Thing is, that it smoothed the whole image, cause i had to use rather agressive settings an still couldn't get rid of all the craling. So warpsharp was applied afterwards, which has the drawback of "sharpening away" fine, small lines. Your description of the filter looked like something which could be usefull in this issue, so i used the "insane" settings of

FluxSmooth(7,80)

which gave pretty good resluts. I haven't done a full encode yet, only small clips, but the crawling was nearly gone and the rest of the picture wasn't altered as much as with wnr.

So, pretty usefull filter for me :)

http://members.tripod.co.uk/forumpic/homer.jpg

It's not that visible, cause it's not moving, but it should be visible at the Telephone letters, especially the P,L,O. The unsharpness comes from convolution3d and PP settings of 5 (fast motion scenes were rather blocky plus mosquito noise at edges).

Thank you,
lamer_de

[SansGrip]

So, pretty usefull filter for me :)

Well, you certainly found a use for it I didn't intend :).

i used the "insane" settings of

FluxSmooth(7,80)

which gave pretty good resluts.

Is a spatial_threshold of 80 really necessary? Theoretically, since the dots are close in brightness to the surrounding pixels, you shouldn't need such a high setting.

I'm glad you find it useful. I'm working on 0.4 at the moment, which also does chroma smoothing. I'll be interested to hear if that helps reduce the dot crawl too :).

[SansGrip]

Just to let you all know that I've not been idle over the past week or so, but have been attempting to reimplement Flux with multimedia extensions. It was hard going for a while, but then something seemed to click and this morning I fixed the last bug in the new iSSE version of Flux-for-YUY2 (I'm going to start the YV12 version this afternoon, and it should go quicker because I won't have to monkey around with pixel order like I do in the YUY2 version).

While the code is not optimized wrt pairing and stalls and all that good stuff, it still runs at twice the speed of the old C++ version on my system :D. I'm predicting the YV12 version will see an even bigger increase because of the lack of aforementioned monkeying around.

I'm hoping to finish it and release today, but I'm not promising anything. This is my first real C-to-MMX port and I'm still pretty slow at the moment.

[iago]

@SansGrip

I'm impatiently waiting for your new optimized YV12 version of FluxSmooth. I have just finished a 1CD encode which came out really good with a combination of "FluxSmooth(7,25).LanczosResize(576,240).UnDot()" and I haven't noticed any artifacts introduced by the filter.

Btw, I want to mention two more points:

Some terrible blockiness in the source itself which was really annoying especially in some scenes were eliminated totally with strong BlockBuster noise! ;)

Also, the encoded movie contained both real-life and anime scenes, and the anime parts were encoded with FluxSmooth(7,25).BilinearResize(576,240).Convolution3D(preset="animeHQ"), which came out without any problems but only a lovely smoothness, just as I exactly aimed to get for those scenes ;).

And finally, FluxSmooth is already fast enough imho, but even more speed keeping the quality intact, why not, is of course welcome! ;)

best regards,
iago


LOL! That must be exactly what they call "heavy filtering"! ;)

[SansGrip]

iago: FluxSmooth(7,25)

Wow, that's some serious spatial smoothing! There's no visible artifacts with a threshold that high?

Some terrible blockiness in the source itself which was really annoying especially in some scenes were eliminated totally with strong BlockBuster noise! ;)

Interesting that it can fix existing blockiness as well as prevent it occurring in the encode... I'm going to have to try that on one of the 90-minute 400mb screeners I downloaded ;).

And finally, FluxSmooth is already fast enough imho

It's pretty speedy with YV12, but 0.4 did slow down a little when I added chroma smoothing. However, I'm getting about 100fps in YV12 with the optimized code :D.

The code's all there but I need to do some more testing as I'm seeing some corruption on frames 0 and 1. This is particularly weird since frame 0 is just passed straight back in GetFrame. I'm wondering if it's not a 2.5 bug, so I need to get the latest build and do some more tests.

I'm expecting to release it today.

LOL! That must be exactly what they call "heavy filtering"! ;)

You're not kidding!

[FuPP]

@SansGrip



Using Fluxsmooth 0.3 in the following script causes a crash (access violation at 0x08ccb826 attempting to read from 0x0f0b9000 (This last address can change)

rem : When fluxsmooth is placed before cropping, then everything is right.

LoadPlugin("C:\video\avsfilters\MPEG2Dec3.dll")
LoadPlugin("C:\video\avsfilters\Fluxsmooth.dll")
mpeg2source("C:\video\tests\vts_01.d2v",cpu=0,idct=2)
LumaFilter(-2, 1.02)
Crop(30,80,660,416)
Fluxsmooth(15,8)
BicubicResize(448,320,0,0.5)
AddBorders(16,128,16,128)
YV12toYUY2(interlaced=false)

[MaTTeR]

Originally posted by SansGrip
While the code is not optimized wrt pairing and stalls and all that good stuff, it still runs at twice the speed of the old C++ version on my system :D. I'm predicting the YV12 version will see an even bigger increase because of the lack of aforementioned monkeying around. Wow, that's certainly something for me to get anxious about. I'm sold on this filter now:D It has now replaced TemporalSoften(x,x) in all my movies, very impressive. Keep up the great work SansGrip!

[SansGrip]

Using Fluxsmooth 0.3 in the following script causes a crash (access violation at 0x08ccb826 attempting to read from 0x0f0b9000 (This last address can change)

rem : When fluxsmooth is placed before cropping, then everything is right.

Thanks for the info -- hopefully this bug has been fixed in 0.4, which is almost a rewrite. I'll double-check before releasing.

[SansGrip]

Originally posted by MaTTeR
Wow, that's certainly something for me to get anxious about. I'm sold on this filter now:D It has now replaced TemporalSoften(x,x) in all my movies, very impressive. Keep up the great work SansGrip!

Glad to hear it's useful for you :).

Sorry for the delay in releasing 0.4, I've had some important things come up that, if you can believe it, don't involve Avisynth ;). I'm hoping to get done with what I'm working on now in a few days (or at least get enough of it done so I can return to 0.4, which is nearly ready to go).

[rocker60]

For at least 24h. Can you please see what's appening?
Thx.

[morsa]

Hi, I suppose many of you know about Restoreinpaint project.

Sourceforge.net/projects/restoreinpaint

It has many, many advanced filtering techniques.I would be nice to have some portings of them.They also can be an inspiration.

[morsa]

Is going to be someday a Vdub version of this filter?

[iago]

@SansGrip

Long time no see, man! ;) I'm looking forward to FluxSmooth 0.4 and I hope the package will come with both YV12 and YUY2 versions together again! ;)

regards,
iago

[Bulletproof]

Originally posted by SansGrip
I'm working on 0.4 at the moment, which also does chroma smoothing. I'll be interested to hear if that helps reduce the dot crawl too :).

That's going to be optional right? :)

[gigah72]

hi,

I read here someone had an accessviolation if fluxsmooth is placed before resize. i have sometimes the opposit problem, but it depends on the crop command:

LoadPlugin("C:\PROGRA~1\DVD2SVCD\MPEG2Dec\mpeg2dec.dll")
mpeg2source("H:\dvd2svcd\VAIACO~1\DVD2AV~1.D2V")
LoadPlugin("C:\Programme\DVD2SVCD\avs-dll\FluxSmooth.dll")
Crop(0, 10, 720, 554) <------ ok
Crop(8, 11, 704, 552) <------ crash
FluxSmooth()
AutoResize()
AutoAddBorders()
#SVCD
function AutoAddBorders(Clip c) {
aab_top = (Floor(((576 - c.height) / 2) / 16))*16
aab_bottom = (576 - aab_top) - c.height
return addBorders(c, 0, aab_top, 0, aab_bottom)
}
function AutoResize(Clip c) {
factor = (72 == 72) ? 0.75 : 1.0
height = Round((720.0 / c.width) * c.height * factor)
return BilinearResize(c, 480, height)
}

both after the resize is ok. any idea ?

greets,
g.

[SansGrip]

Attached is 0.4. Sorry about the delay -- darn real life ;).

The biggest change in this version is that I implemented ISSE-optimized algorithms for both the YUY2 and YV12 versions. From my quick benchmarks it seems to run about twice the speed of the C++ version. I also added chroma smoothing.

As usual you can get the latest version (and the source) from the web site in my sig. (By the way, I apologise for the downtime: the web server it's on is located in North Carolina, and they had a killer storm which took power down for days. It should be back up now.)

Many thanks to trbarry, sh0dan, dividee, and everyone else who helped me figure out assembler and MMX by putting up with and patiently answering my stupid questions :).

Edit: Removed links to old version.

[SansGrip]

Originally posted by Bulletproof
[Chroma smoothing]'s going to be optional right? :)

It would be simple to make optional for the YV12 version, but quite hard for the YUY2 version. Which do you use? :D

[SansGrip]

Originally posted by gigah72
I read here someone had an accessviolation if fluxsmooth is placed before resize. i have sometimes the opposit problem, but it depends on the crop command

Sorry to hear you're having problems.

I'd be grateful if you could try the same thing on 0.4, since I made significant changes from 0.3 and could have eliminated the bug accidentally.

[onesoul]

Hi. First of all humbly I must say I admire all the work you and all programmers been doing with avisynth filters.
I would like to have your opinion about the usage of fluxsmooth.

I've seen people in this thread using both fluxsmooth and convolution3d at the same time, is it wise to do that?

I've read the "readme.txt" of both nomosmooth and fluxsmooth but still not being confortable at this field, I apologize for the following question. Is nomosmooth made obsolet by fluxsmooth? If not when one should use it?

Could you recomend some settings, like convolution3d has, but including also for dv source.

I hope I am not asking too much... (oops)
Thanks

[Bulletproof]

Originally posted by SansGrip
It would be simple to make optional for the YV12 version, but quite hard for the YUY2 version. Which do you use? :D

YV12 ;) , Thanks.

[SansGrip]

Originally posted by onesoul
I've seen people in this thread using both fluxsmooth and convolution3d at the same time, is it wise to do that? I see no reason why not, if it produces superior results. If using both together, though, I would recommend using very light settings on each.

Originally posted by onesoul
Is nomosmooth made obsolet by fluxsmooth? If not when one should use it? While both NoMo and Flux are spatio-temporal smoothers, they are otherwise not very similiar.

NoMo tries to differentiate between static areas and those in motion, with the hope of reducing motion-related artifacts. It is reasonably successful, but can introduce other problems when similarly coloured objects are moving over each other.

Flux, on the other hand, specifically targets what I like to call "fluctuating" pixels. Since a video frame is really just a bunch of numbers, imagine that you are currently processing the pixel at x=50, y=50. If the previous frame's value at that location is 70, the current frame's 72, and the next frame's 71, then the pixel in the current frame is a fluctuating pixel because it's greater than the value of the corresponding pixel in both the previous and next frames. This makes it unlikely to be a product of motion -- therefore likely to be noise -- and it is smoothed. This seems to work very well, though theoretically fine textures in motion could be mistaken for a fluctuation.

So Flux hasn't really "superceded" NoMo in a theoretical sense. That said, I use Flux almost exclusively now (when I find time to actually encode some video, that is ;)).

Originally posted by onesoul
Could you recomend some settings, like convolution3d has, but including also for dv source. Once Flux has received more testing I'm hoping we can compile sets of settings for exactly this purpose. Personally I tend to use a temporal threshold of 5-10 (depending on how noisy the source is) and a spatial of 0-5.

But others have used this filter far more often than me, so can likely provide more valuable feedback on good settings :).

[SansGrip]

Originally posted by Bulletproof
YV12 ;) , Thanks. Ok, I shall implement enabling/disabling chroma smoothing for the YV12 version in the next release. TBH I don't think I'll ever implement it for the YUY2 version unless I see a compelling reason to do so...

[Boulder]

Hi SansGrip, good to see you again. Thanks for the optimized filter, I've been using FluxSmooth in all my (X)VCD conversions these days:)

[SansGrip]

Originally posted by Boulder
Hi SansGrip, good to see you again. Thanks for the optimized filter, I've been using FluxSmooth in all my (X)VCD conversions these days:) Glad to hear that :). Do you have any observations regarding good settings for various sources? I'm considering implementing something similar to C3D's "preset" in the next release.

[SansGrip]

Originally posted by morsa
Is going to be someday a Vdub version of this filter? I have no current plans to port any of my filters to VDub (mainly because I never use it for filtering ;)).

[hakko504]

I can give you one more reason not to convert the temporal smoothers to VD. VD cannot access frames randomly like AviSynth, so you need to build and maintain a cache of the frames you want to use later. This results in a delayed picture, usually by one frame.
Virtual Dub is supposed to be a completely linear solution, a one frame input will result in one frame output (encoded). There is one large exception to this, and that concerns b-frames in DivX5.02 and XviD.

[FuPP]

hi SanSgrip

Thx again for your great filter! I still have though a problem when putting it after crop function, except using some filters after yours
(don't know if I am clear :D)

ie :

LoadPlugin("C:\video\avsfilters\MPEG2Dec3yv12.dll")
LoadPlugin("C:\video\avsfilters\asharpyv12.dll")
LoadPlugin("C:\video\avsfilters\fluxsmoothyv12.dll")
LoadPlugin("C:\video\avsfilters\undotyv12.dll")
mpeg2source("F:\test\vts_01.d2v",cpu=0,idct=2)
Crop(32,80,656,416)
colorYUV(levels="PC->TV")
fluxsmooth(15,8)
BicubicResize(448,320,0,0.5).AddBorders(16,128,16,128)
converttoyuy2()

DOES NOT WORK -> weird image



LoadPlugin("C:\video\avsfilters\MPEG2Dec3yv12.dll")
LoadPlugin("C:\video\avsfilters\asharpyv12.dll")
LoadPlugin("C:\video\avsfilters\fluxsmoothyv12.dll")
LoadPlugin("C:\video\avsfilters\undotyv12.dll")
mpeg2source("F:\test\vts_01.d2v",cpu=0,idct=2)
Crop(32,80,656,416)
colorYUV(levels="PC->TV")
fluxsmooth(15,8).asharp(1,4.5).undot()
BicubicResize(448,320,0,0.5).AddBorders(16,128,16,128)
converttoyuy2()

WORKS !

[SansGrip]

@FuPP

Could you try:


LoadPlugin("C:\video\avsfilters\MPEG2Dec3yv12.dll")
LoadPlugin("C:\video\avsfilters\fluxsmoothyv12.dll")
mpeg2source("F:\test\vts_01.d2v",cpu=0,idct=2)
Crop(32,80,656,416)
fluxsmooth(15,8)
and so on, to eliminate some of the other filters from the equation?

[SansGrip]

Originally posted by hakko504
VD cannot access frames randomly like AviSynth, so you need to build and maintain a cache of the frames you want to use later. If I wasn't sure before, I am now ;).

[onesoul]

Originally posted by SansGrip
So Flux hasn't really "superceded" NoMo in a theoretical sense. That said, I use Flux almost exclusively now (when I find time to actually encode some video, that is ;)).


:) I've been learning so I've encoded only to test (a few cds thrown away), I can say this forum has taught me everything I know about encoding, everyday is a lesson learned.

Thank you for your enlightened explanation, really apreciated :)

I'll stay tuned for any recomended presets. Maybe one day I can contribute too with valuable info such as settings.

[SansGrip]

Originally posted by onesoul
I'll stay tuned for any recomended presets. Maybe one day I can contribute too with valuable info such as settings. Read, read, read, test, test, test. Then read and test some more. That's how everyone here learned, unless there are Avisynth classes that I'm unaware of ;).

The very best way to learn Avisynth thoroughly is a) read the source and b) write your own filter. Even if it does something very simple such as invert the image you'll learn a lot about how filters operate which you can then apply to actually using them to their fullest.

[Guest]

Originally posted by hakko504
I can give you one more reason not to convert the temporal smoothers to VD. VD cannot access frames randomly like AviSynth, so you need to build and maintain a cache of the frames you want to use later. This results in a delayed picture, usually by one frame.
Virtual Dub is supposed to be a completely linear solution, a one frame input will result in one frame output (encoded). There is one large exception to this, and that concerns b-frames in DivX5.02 and XviD. You can implement a frame cache in VirtualDub that does not delay the stream. You just save your own copy of the previous frame(s) in your filter data. This requires special handling for the first frame(s) but that is usually not a problem.

As proof, SmartDeinterlacer (among others) does this. :)

[SansGrip]

Originally posted by neuron2
You can implement a frame cache in VirtualDub that does not delay the stream. You just save your own copy of the previous frame(s) in your filter data. This requires special handling for the first frame(s) but that is usually not a problem. It might be worth trying once as a programming exercise, but what with maintaining two different (YUY2 and YV12) versions of my filters already I think I'll stick with the one API ;).

Edit: Correction! Four versions -- YUY2 C++, YUY2 MMX, YV12 C++ and YV12 MMX :scared:

[Boulder]

I can't say that there are settings that are the best in certain situations, I just try them out and compare the filtered output to the original one (with two VDubMods running).

For example, Hitchcock's The Birds lost a lot of noise but kept the details with the default settings. Without the filter the movie would have had a lot of noise in the background.

In my analog TV captures I've mainly used FluxSmooth(15,15). I know it could remove details as well but I think that the extra smoothing is worth that. The values depend on the captured source, of course. It seems that the Finnish Broadcasting Company has a slightly better signal than the commercial ones.

The thing about the settings is truly trial-and-error:devil:

[SansGrip]

Originally posted by Boulder
For example, Hitchcock's The Birds lost a lot of noise but kept the details with the default settings. Without the filter the movie would have had a lot of noise in the background. I found the defaults to be quite good -- that's why I picked them :D.

In my analog TV captures I've mainly used FluxSmooth(15,15). I know it could remove details as well but I think that the extra smoothing is worth that. Yes, I use pretty strong values for caps too (more for analog sources than digital of course).

By the sound of it we pick similar settings, except you use a lot more spatial smoothing than I...

The thing about the settings is truly trial-and-error :devil: Maybe having a "preset" parameter is a bad idea, then...? It would be great for lazy people such as myself, but might discourage someone from playing with the parameters and coming up with their own values :).

[MaTTeR]

Great to see you back in action here SansGrip. Thx for the new build, been testing it and indeed it's quite speedy and found no bugs:)

In regards to presets, for a high quality encode of a DVD source the defaults might be a little to strong. My settings have been lingering around 3,3 or at the most 5,5 for clean DVD sources. Something in this range seems to be a nice trade off when fine details need to be kept IMO. Perhaps I'm being a little conservative here but I do like sharpness and detail;)

[SansGrip]

Originally posted by MaTTeR
Thx for the new build, been testing it and indeed it's quite speedy and found no bugs:) Quite speedy? QUITE speedy?? :angry: ;) heheh :D

I'm sure there are a few optimizations I can squeeze out yet, wrt pairing and stalls and all that stuff I don't quite understand fully yet (though I did just get in the mail an Intel book on software optimization). Actually what would be great is if someone more experience with MMX were to take a look at the source and give me any suggestions... Hint, hint... :D

In regards to presets, for a high quality encode of a DVD source the defaults might be a little to strong. Yep, I agree. I found them good for "average" DVDs like American Pie, but for clean sources it's too much.

My settings have been lingering around 3,3 or at the most 5,5 for clean DVD sources. Something in this range seems to be a nice trade off when fine details need to be kept IMO. Perhaps I'm being a little conservative here but I do like sharpness and detail;) If so then I'm on the conservative side too. In fact, I often lower the spatial threshold or even turn it off completely unless I see a real need for it.

[iago]

@SansGrip

Welcome back man! Nice to see you around again ;). Now, it's time to give a shot to the speedy new release (with "Fight Club" as usual, as a personal preference for testing filters with a good DVD source ;)).

regards,
iago

[SansGrip]

Originally posted by iago
Welcome back man! Nice to see you around again ;). Now, it's time to give a shot to the speedy new release Thanks :). Let me know how you find it...

[calvore]

I am planning to test out fluxsmooth over the Christmas break while I convert many of my home videos from VHS to CVDs. So, analog interlaced NTSC source. Does fluxsmooth work with an interlaced source or do I need to separate the fields, apply the filter, then join them again?

Thanks, it looks like these filters will work excellent for cleaning up the video.

While I am asking, how much of a border should I place around the CVD image to actually aid in compression without moving outside the overscan area? Chunks of 8x8 blocks, or is it 16x8 (or 8x16)?

[SansGrip]

Originally posted by calvore
Does fluxsmooth work with an interlaced source or do I need to separate the fields, apply the filter, then join them again? Flux doesn't specifically handle interlaced source (yet, anyway), so I think you'll need to separate and rejoin.

While I am asking, how much of a border should I place around the CVD image to actually aid in compression without moving outside the overscan area? Chunks of 8x8 blocks, or is it 16x8 (or 8x16)? It depends on your TV. For me I can add 8-pixel borders top and bototm without seeing them on the TV screen, but left and right I can't add any (well, up to 6 pixels, but that doesn't help compressibility any). Most TVs allow 8-16 pixels each side, and some even more, so the best thing to do is experiment.

[onesoul]

I've done some reading and some testing. I find fluxmooth to be running at more 50% of the speed of the convolution3d or nomosmooth (these 2 filters gave me similar speeds).

Fluxsmooth (at the default values) has made me sastified with the results it achieved so I will use it for now on.

I'm still not very confortable with changing values but I guess I will try some. I must say it is the spatial smoother setting which gives me more dificulties.

Keep up the good work SansGrip

[SansGrip]

Originally posted by onesoul
I've done some reading and some testing. I find fluxmooth to be running at more 50% of the speed of the convolution3d or nomosmooth (these 2 filters gave me similar speeds). NoMo is not yet MMX-optimized, but is fairly high on my todo list.

Fluxsmooth (at the default values) has made me sastified with the results it achieved so I will use it for now on. Glad it's working for you :).

I'm still not very confortable with changing values but I guess I will try some. I must say it is the spatial smoother setting which gives me more dificulties. For what it's worth, I tend either to use the default values (fast to type :D) or I'll set spatial lower than default, especially for very clean sources.

[MaTTeR]

SansGrip,

I forgot to post a shot of ringing artifacts for you. Have a look at the 2 PNG files I've attached. The 2nd pic of a sunset might demonstrate the problem a little better. You can adjust the color properties to exagerate the problem a little more if need be. Notice the rings around the sun?

This movie (US Navy Seals) is an absolute ringing nightmare due to the overall darkness and underwater scenes:devil:

[MaTTeR]

2nd ringing artifact shot...

[SansGrip]

Originally posted by MaTTeR
Notice the rings around the sun? Yep, though I've never seen Flux produce anything like this and really can't think what mechanism might be causing it. Flux only ever uses a spatial radius of 1, so shouldn't be able to cause artifacts beyond that range.

Unless I'm missing something...?

[MaTTeR]

Sorry, I should have been more clear earlier. The shots above aren't related to flux in anyway. These ringing artifacts will occur even without any filtering on the source, they just happen to be worse when encoding to YV12 IMHO. I doubt MPEG-2 has this problem though, I've never noticed it on any KVCDs.

[kilg0r3]

@matter

i always thought this was called blocking or color stepping and that ringing was the same as moskito noise.

are thes screen shots from encoded material or from avisynth output? if this is xvid encoded material, please post about this problem also in the xvid forum. might be an xvid issue.

my guess is that this problem is due to heavily compressed chroma information, because it mostly shows in color gradients. furthermore it always looks like that in some areas the codec or whatever, uses the wrong colors. i am just a n00b though.

anyway to get to it by using blockbuster?

[MaTTeR]

Originally posted by kilg0r3
anyway to get to it by using blockbuster? This is my next test actually, I'm hoping it might help.

Maybe I'm confusing the term a bit but I always assumed since I seen ringing(circle rings) artifacts around objects or on walls that "deringing" post processing would deminish them. I do like the color blocking term though, havent heard that one before:)

[SansGrip]

Originally posted by MaTTeR
The shots above aren't related to flux in anyway. Man... Don't DO that :D ;) heheh