How can use filter in sequence?

[YY1020]

There are many filter in http://www.avisynth.org/warpenterprises/.But so far,i haven't known how to use filter in sequence.
For example,i use deen,temporalcleaner,undot.I ought to use deen,temporalcleaner or undot first??
Script :

Deen()
Temporalcleaner()
undot

or

undot
Temporalcleaner()
Deen()
.
.
.
.
.
.
Have Doom9's Forum had such thread on that??
That's all for my questions.
Thank you very much.

[Mug Funky]

Have Doom9's Forum had such thread on that??

just yesterday... still on page 1 actually...

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

basically, the filters are so various that it's impossible to give a general answer to this question.

there's some guidelines though (others might have different ones)

1. spatial before temporal filters
2. avoid colourspace conversions where possible (converttoyuy2 and it's ilk)
3. the more filters, the slower the script and the less detail. use only what you need.

hope this helps... (there might be something in the avisynth faq to this effect, but it's so long since i've read it)

[YY1020]

1. spatial before temporal filters
2. avoid colourspace conversions where possible (converttoyuy2 and it's ilk)
1.Use spatial filters first,after that use temporal filters, then use 3D filters at last, is it right?
2.I sometimes use converttoyuy2 if i need.But i've read one thread that the first conversion back and forth does not hurt source, but if you use three or more, it may.Is it right?

[Mug Funky]

well, conversions slow things down, but the blurring effect is very small when going between different YUV spaces. when going to RGB there's a bit more blurring apparent, as the channels all mix together, so the lower sample rate of the chroma channels comes to play (and again when it's converted back to YUV).

as far as 3d filters go... they're spatio-temporal, and are designed to be the only filter run in the script (which is good for speed). if you find there's still noise after, then put a filter after these.

usually with the average DVD source you'll only need a light filter, but noisy/shaky/bad sources are fair game with filters - use what works, as you'll usually be experimenting a lot before your final encode. so feel free to break the above guidelines...

[YY1020]

Originally posted by Mug Funky
well, conversions slow things down, but the blurring effect is very small when going between different YUV spaces. when going to RGB there's a bit more blurring apparent, as the channels all mix together, so the lower sample rate of the chroma channels comes to play (and again when it's converted back to YUV).

as far as 3d filters go... they're spatio-temporal, and are designed to be the only filter run in the script (which is good for speed). if you find there's still noise after, then put a filter after these.

usually with the average DVD source you'll only need a light filter, but noisy/shaky/bad sources are fair game with filters - use what works, as you'll usually be experimenting a lot before your final encode. so feel free to break the above guidelines...
OH...IC.
Thank you very much.

[stickboy]

What's the rationale for spatial before temporal?

[Mug Funky]

hmm... i figure less noise before temporal smoothing will improve the performance of the temporal filter. also increase compressibility. this is important on grainy videos, but the difference isn't big at all.

i haven't done rigourous testing though - i just liked the result. "creamier".

that is why i said they were "guidelines", not rules.

[trevlac]

Originally posted by Mug Funky
well, conversions slow things down, but the blurring effect is very small when going between different YUV spaces. when going to RGB there's a bit more blurring apparent, as the channels all mix together, so the lower sample rate of the chroma channels comes to play (and again when it's converted back to YUV).


This type of comment does not make sense to me.

RGB and YUV (it's actually YCbCr) are simply math formula used to represent a color value. Converting from YCbCr to RGB does not make a more blurry picture. I don't think the AviSynth built in ConverToRGB interpolates the upsampled chroma. So I'm really not sure where you get this blurry comment.

This is what I think ... may be talkn out my ar$e ... :D

- 8 bit Conversions between normal range RGB and YUV should have zero effect on luma if you do not change the range. If you do change the range, the effect is minor (if it exists at all). BTW: the detail is in the luma.

- The biggest effect is if your YUV is out of 16-235 range and your conversion clamps.

- In 8 bit conversions, there are color shifts in U&V. These are also very minor.

- Color space conversion (like any filtering) slows things down. Also, because subsampled YUV has less bits, this means less processing, and this means it is faster.

- [sacrilege warning] RGB is mucho better than YUV for multiple filters because RGB can contain 4x as many colors as YUV for intermediate results. (PS: I don't know if there is a noticable effect, so I'd go with yuv for speed.)

[Mug Funky]

hmm... converttoRGB() actually does interpolate chroma..


blankclip()

subtitle("I can't believe how much i rock",text_color=$ff0000)

converttoyv12()
converttorgb()


this should make it clear by commenting out the converttorgb line when appropriate.

the luma equation is a sum of red, green and blue (with some fancies thrown in of course), so therefore if chroma (full red) is blurred, the luma will be blurred.

of course, with multiple filters like you suggested, there will be detail loss at each stage. this will most likely make the slight smearing unnoticable. but still, RGB takes twice as long to process and not many avs filters support it (there's so much that uses masktools now, and that's YV12 only).

[stickboy]

Originally posted by Mug Funky
hmm... i figure less noise before temporal smoothing will improve the performance of the temporal filter. also increase compressibility.Hmm... but less noise before spatial smoothing will improve the performance of the spatial filter, which also increases compressibility. :)

I usually put temporal filters first; my thinking has been that that way, I can make the temporal filters a little stronger and the spatial filters a little weaker, and temporal artifacts are usually less noticeable to me than spatial ones. Of course, I haven't verified any of this.

[trevlac]

@Mug Funky

I can't believe how much you rock :D

ConvertToRGB() does indeed interpolate. I was wrong. I have no idea where in the code it does this (i actually looked at convert.cpp before i made that comment). The c code sure does not look like it. Maybe in the asm.

However, i did find your test to be a bit unclear. 1st you create an RGB clip. Turn it into YV12. This last step probably causes interpolation down to avoid aliasing. Then you convert to rgb (and I assume view in VDub). But if you comment out the ConvertToRGB(), something else on your machine converts to RGB so you can see it in VDub. AFAIK, if you see it, it's RGB. My NT machine, for example, will not actually open a YV12 output file.

So, I went a few steps further to see if I could seperated out the RGB->YV12 from the YV12->RGB. I made a dll that converts from YUY2 to RGB32 with the option of not interpolating, and/or not changing the 219/255 range. Unfortuantely, I did not have time to add YV12 support and YUV->RGB code that does not change the range (so I could not fully test).

But ... I did run a bunch of tests I believe show the subsampling effect of conversions. The script is below. You can remove the dll use by commenting the Load out and changing the types to 10.



LoadPlugin("YUY2toRGB219.dll")

global LINES = 20
global TYPES = 14 #<== Change to 10 to not use dll
global cMsg = blankclip(length=1,height=20,width=480)


firstFrame = blankclip(length=1,height=cMsg.Height * LINES,width=cMsg.Width)

addFrame(firstFrame,0)

# ---------------
function getType(int type) {
Select(type, \
"c.PointResize(cMsg.width/2,cMsg.height/2).PointResize(cMsg.width,cMsg.height)", \
"c.BilinearResize(cMsg.width/2,cMsg.height/2).BilinearResize(cMsg.width,cMsg.height)", \
"c.BicubicResize(cMsg.width/2,cMsg.height/2).BicubicResize(cMsg.width,cMsg.height)", \
"c.LanczosResize(cMsg.width/2,cMsg.height/2).LanczosResize(cMsg.width,cMsg.height)", \
\
"c.converttoyv12().converttoYUY2()", \
"c.converttoyv12().converttoRGB()", \
"c.convertbacktoyuy2().converttoyv12().converttoRGB()", \
"c.convertbacktoyuy2().converttoyv12().converttoyuy2().converttoRGB()", \
\
"c.convertbacktoyuy2().converttoRGB()", \
"c.converttoyuy2().converttoRGB()", \
\
"c.converttoyv12().converttoyuy2().YUY2toRGB219(TVtoPC=true)", \
"c.convertbacktoyuy2().YUY2toRGB219(TVtoPC=true)", \
"c.converttoyuy2().YUY2toRGB219(TVtoPC=true)", \
"c.converttoyuy2().YUY2toRGB219(interpolate=true,TVtoPC=true)" \
)
}


# ---------------
function _convert(clip c, int type) { return Eval(getType(type) )}

# ---------------
function addFrame(clip cHoldFrames, int num) {

cType = cMsg.subtitle(getType(num),text_color=$ff0000)

#--- Make New Frame by adding lines --
c = addLine(_convert(cType,num),_convert(cType,num),1, num)

#--- Add Plain old RGB to Top --
c = stackVertical(cType,c.converttoRGB())

#--- Keep adding frames to num of types
return(num==TYPES-1) ? cHoldFrames + c : addFrame(cHoldFrames + c, num+1)
}


# ---------------
function addLine(clip c, clip c2, int num, int type) {
c2 = _convert(c2,type)
return (num > LINES - 2) ? c \
: addLine(stackVertical(c,c2),c2,num+1, type)
}


Plugin here: http://trevlac.us/Mug.ace

cheers,

Trev


PS: I still think it is unclear that 'mixing' channels is the issue. The conversion calcs (without the subsampling) are simply:
R = V + Y = R-Y + Y. Without interpolation, I would expect this to be a completely linear transform.

:)