Avisynth: Anime Filters?

[TemplateAVS]

I've been encoding anime for the past few months using fluxsmooth and sometimes with and without blockbuster. divx sources & gop 12

352*240 Plus KVCD
LoadPlugin("C:\WINDOWS\system32\fluxsmooth.dll")
LoadPlugin("C:\WINDOWS\system32\blockbuster.dll")
AviSource("D:\Share\Anime\witch.avi")
BicubicResize(336,224,0,0.6,0,0,480,360)
ConvertToYUY2()
FluxSmooth()
Blockbuster(method="noise", variance=0.7, seed=1)

Now, I just want to know which set of filters should I use now for my new template since we are using CQ. This is my new template that I'm using right now and testing. Should I take out blockbuster or use fluxsmooth instead of temporalcleaner? (I don't use 352*480 because it would take me 1hr45min for a 20min film)

352*240 Plus KVCD
LoadPlugin("C:\WINDOWS\system32\temporalcleanerold .dll")
LoadPlugin("C:\WINDOWS\system32\msharpen.dll")
LoadPlugin("C:\WINDOWS\system32\blockbuster.dll")

AviSource("D:\Share\Anime\witch.avi")
BicubicResize(336,224,0,0.6,0,0,480,360)
ConvertToYUY2()
MSharpen(15,100,true,false,false)
TemporalCleaner()
Blockbuster(method="noise", variance=0.7, seed=1)

[kwag]

Hi TemplateAVS,

I would add SpaceDust() right after ConvertToYUY2()

-kwag

[TemplateAVS]

Thanks, I'll try out SpaceDust().

[NyteSkyy]

I've also been working on anime KVCDs, and KDVDs over the past few months.

This is what I've used most recently, can't complain with the output either:

LoadPlugin("C:\avs\GripFit_preview.dll")
LoadPlugin("C:\avs\legalclip.dll")
LoadPlugin("C:\avs\TemporalCleanerOld.dll")
LoadPlugin("C:\avs\sampler.dll")
LoadPlugin("C:\avs\dustv5.dll")
LoadPlugin("C:\avs\Sampler.dll")

AviSource("D:\anime\Kiddy Grade\Kiddy Grade - 05 [Keep-ANBU][AE1F9ACE] (streamload).avi")
ConvertToYUY2()
LegalClip()
GripCrop(width=528, height=480, overscan=2)
GripSize()
SpaceDust()
TemporalCleaner() 
GripBorders()
LegalClip()

[alfredini]

Try also fluxsmooth(15,10). After testing with many smoothers i find this is the best you can use with Animes.

LoadPlugin("C:\AVSFilter\Plugins\MPEG2DEC.dll")
LoadPlugin("C:\AVSFilter\Plugins\legalclip.dll")
LoadPlugin("C:\AVSFilter\Plugins\MSharpen.dll")
LoadPlugin("C:\AVSFilter\Plugins\Convolution3D.dll")
LoadPlugin("C:\AVSFilter\Plugins\fluxsmooth.dll")
LoadPlugin("C:\AVSFilter\Plugins\sampler.dll")


AviSource("C:\Program Files\mIRC\download\[gfs]_rurouni_kenshin_-_reminisence_01_[ger.sub].avi") + AviSource("C:\Program Files\mIRC\download\[gfs]_rurouni_kenshin_-_reminisence_02_(ger.sub).avi") + AviSource("C:\Program Files\mIRC\download\[gfs]_rurouni_kenshin_-_reminisence_03_(ger.sub).avi") + AviSource("C:\Program Files\mIRC\download\[gfs]_rurouni_kenshin_-_reminisence_04_(ger.sub).avi")
EnsureVBRMP3Sync()
LegalClip()
BilinearResize(336,272,3,0,506,384)
MSharpen()
FluxSmooth(15,10)
AddBorders(8,8,8,8)
LegalClip()

Try also Peachsmoother in addition (after resize):

PeachSmoother(NoiseReduction = 60, Stability = 25, Spatial = 140)

[NyteSkyy]

Decided to try out MSharpen, but am not sure it's working. Default, "MSharpen()" opens fine in vdub, but if I change the strength to say 24, I get an error saying the data has to be in RGB format only.. so I add "ConvertToRGB", that takes care of that error. but then legalclip needs it to be YUY2..

So I wonder, can this filter and legalclip be used in conjunction?

[TemplateAVS]

MSharpen() is actually a good filter. It is suppose to work with YUY2 and RGB.

[NyteSkyy]

Quote:

Due to the extreme difficulty of writing this filter correctly and with acceptable performance, it operates in the RGB color space. Use ConvertToRGB() if required. Note that the HUFYUV filter can output RGB, so when using it to generate source material, configure it that way to avoid an unnecessary conversion. A future version may support YUY2.

I think this is the latest version (Version 1.0 beta 1). But I don't doubt it, it looks very useful.

[WOWIEGURL]

is it really necessary to use LEgalClip.dll? cause I put it in the plugin folder of AVisynth and it keeps saying it is not a Avisynth 2.5 plugin.. and I've looked everywhere and I can't find it.

[Dialhot]

Legalclip was a 2.0 filter. It is now replaced by the command "Limiter()" that is internal to avisynth 2.5.

But you are trying to use a too old script (look at the threa year : 2003 !). SpaceDust does not work with 2.5 either.

Use latest optimal script you can find on the "optimal script" section of the forum.

[incredible]

Also I would NEVER use Limiter() as Limiter just cuts the luma range where ColorYUV() in pctoTv mode scales the luma range and this results in visible more maintained "depth's" in very dark an white areas.

Do a avisynth script test using the Contrast Templates from THX Optimizer and you'll see

[muaddib]

Quote:

Originally Posted by incredible

Do a avisynth script test using the Contrast Templates from THX Optimizer and you'll see

Hi inc!
Where can I find them?

[Dialhot]

Quote:

Originally Posted by muaddib

Quote:

Hi inc!
Where can I find them?

On almost all last THX labellized DVD released.

[incredible]

http://www.thx.com/mod/products/dvd/brightness.html

http://www.thx.com/mod/products/dvd/contrast.html

[kwag]

Quote:

Originally Posted by incredible

Also I would NEVER use Limiter() as Limiter just cuts the luma range where ColorYUV() in pctoTv mode scales the luma range and this results in visible more maintained "depth's" in very dark an white areas.

Where did you get this information Inc
Limiter is designed for "TV" purposes, and not for PC monitors.
I always use Limiter() before filters and after filters, as a safety factor, so the color space is always bracketed to TV colorspace.
Or, has technology changed since all the discussions we had with SansGrip and sh0dan, about this issue

-kwag

[Dialhot]

Quote:

Originally Posted by kwag

Or, has technology changed since all the discussions we had with SansGrip and sh0dan, about this issue

It has changed at least since the time I am on this forum, and I try to explain to anyone that this clipping is already done by the encoders so using it in the script is a nonsense.
And we (you and me) once concluded that it can be still used but only as any other filter used to reduce the filesize and for nothing else ! This day you removed the lines from the optimal scripts
(see the history log of the optimal script).

[incredible]

Take a full luma range 0-255 capture (just an example) and add to your AVS script at the very end a histogram("levels") .. stream btw has to be YV12.

Now do move to a frame where the levels right above show a clear 0-16 luma clipping, these clipping values in the graph will be colored as yellow.

IF you simply add limiter() these fine tones/details within the black will be cut. but if you add Coloryuv(Levels"PC->TV") these details will be still there as the luma range will be scaled. And for me these details are important as in relation the value 16 on TV is black.
I just had that issue a few days ago where my capture cards driver was not manually optimal set to a proper 16-235 Luma range.

Now as you can set the encoder to force a 16-235 Luma range we should figure out (or search for threads) IF the encoder scales or crops the luma range. AFAIK CCE only affects the stream by these settings IF the Input is RGB ... just AFAIK.

But even if you do a test using your ncoded mp2 afterwards, and check that with avisynth etc. it has been known that DVD2AVI or DGindex resulted d2v files do got wrong cooefficients from the mpeg (if I did understand that right) so an adding of colormatrix() to the script seems to solve that.

And even if not encoded at 16-235, many DVDplayers do got a luma "cropper" in their Hardware, means on my Cyberhome505 the shadow behind the "THX" isnt present and the bright Quadra will be shown as a full white. On my Mediencom DVD Player the visuals are correct and NOT "cutted".

IMHO the THX optimizer isnt that accurate or well produced as I for example found out if you use the AR Template to exactly "center" the image provided by the THX Optimizer, the result is an image generally too much left, proofed by a too much left positioned 4:3 image o my 16:9 and also a wrong image position at other Movies or even reference DVDs.

[incredible]

When using ColorYUV(Levels="PC->TV")





When using just limiter()



You can clearly see that a) the deep black quadras in the stripes are erased and also the shadow behind the THX Logo. For me the situation is clear and the Producers of the STARWARS Box did a mistake by encoding including super black areas (0-16). On TV thats a mess, on a Beamer not.

In the script finally at the very end I did made the black a touch brighter to simulate the TV as the TV in general is brighter but the levels modification was done on the orig untouched luma range directly after the mpeg2source line!

[kwag]

Quote:

Originally Posted by Dialhot

Quote:

It has changed at least since the time I am on this forum, and I try to explain to anyone that this clipping is already done by the encoders so using it in the script is a nonsense.

It's not nonsense at all
What about if I want to encode an MPEG for PC and NOT for TV
If the encoder clips the levels, the result is not acceptable on a PC monitor.

@Inc,
I'll have to make some tests to verify this.

-kwag

[incredible]

Karl, watch my THX examples.

also if doing this ...

mpeg2source("xxxxxxxxxxxxx.d2v")
Converttorgb32()
Converttoyv12()

... also here the Luma range will be cropped to 16-235 due to rgb and restore back to yv12 conversion .... Means a conversation out of a rgb source into a YUV source will be done incl. a luma cropping and not scaling or even still 0-255 kept. Thats why you should use the correct coefficent flag in the converttoXXX() command as explained in the avisynth manual.

Also when using TmpgEnc forced CCIR601 encoding the luma will be cropped! Means if luma cropping for you doesnt matter, then follow Phil's recommendation to kick out the limiter() at the very end of your scripts, as not needed.
So the best would be to fix the luma within the script to exact 16-235 (even on very well known mastered sources as you see above ) and finally doing a conversation at the very end of the script to the encoders native colorspace where in the encoder an untouched luma encoding (non!-CCIR601) will be done, To me that results in an encoding in a FULL luma/chroma detail encoding where still 16-235 CCIR601 Luma TV Specs are guaranteed.

AFAIK but still I not proofed that .... CCE only affects the Luma range IF the input is RGB, means at YUV inputs no affection will be done (even if set to 16-235) .... but as said I "heared" about that. So that has to be proofed also

A final encoder-native colorspace conversion in the script avoids the system to use a Dshow or vfw decoder where its not proofed HOW a conversion to RGB (like which is requested by TmpgEnc) by that decoder is done, means kept, cuttet or scaled

When using a Cyberhome player IMHO thats a MUST as the player itself does "crop" to 16-235, means on my Cyberhome no THX shadow is shown, but on my Mediencom its present.