IMO DCTFilter should be the last item in the script, even after the borders. The author suggested this when he released the filter. I haven't done any filesize compares but I trust him

Thanks all I'll try the script right away. I see your not using Limiter() and scd_trigger What is the reason for that?

Ok, guys, check this script out By using Deen() + DCTFilter(1,1,1,1,1,1,0.5,0) file size goes way down while video quality goes up

nf=0
GripCrop(480,480,overscan=2,source_anamorphic=fals e)
GripSize(resizer="BiCubicResize")
Undot()
Deen()
Asharp(1,4)
STMedianFilter(8,32,0,0)
MergeChroma(blur(1.52))
MergeLuma(blur(0.2))
SwitchThreshold=(Width<=352)?4Width<=480)?3:2
ScriptClip("nf=round(YDifferenceToNext())"+chr(13) +"nf>=SwitchThreshold?unfilter(-(fmin(nf*2,100)),-(fmin(nf*2,100))):TemporalCleaner(6+nf,11+nf)")
GripBorders()
function fmin(int f1,int f2){return(f1<f2)?f1:f2}
DCTFilter(1,1,1,1,1,1,0.5,0)

Let me know how you like it

oh yes Holomatrix,

i did tests with deen and it's very cool.

but it don't make your encode too slow?

Found no speed decrease If any it would from DCTfilter but very small.

Deen is a convolution filter as is StMedianFilter. Using both is perhaps "too much". For sure file size goes down, but I fear details level also.

You're also using a fairly high Luma-Blur Value in your script (0.2), which will for sure lead to a much smaller filesize, however, as Phil said, details will not be preserved very well the way I see it.

__________________
j3llyG0053

I find that I still get tiny blocks in the video when I look close, is there anything in the script that I can modify to blend these blocks better? Blockbuster(dither) does not seem to help enough. Since I don't really know what all the commands in the script mean can I add scd_trigger or Limiter or up some values in the script? Thanks

Question for both Jorel and Holomatrix. I noticed that your Undot and Asharp lines were both after Gripfit, but I thought Jorel had already found that they are better placed *before* resizing (like in Kwag's MA script). Any reason why they're back down there now?

J-Wo my friend,
in the script that i posted i don't change the place of the filters.
and i'm using that script...asharp and undot are before Gripfit
giving better quality in the image and less size!

Okay Jorel, now I'm confused! In page 1 of this thread you posted the following code:So here you have Undot and Asharp AFTER Gripcrop and Gripsize. Is this an error then?

oh yes, you're not confused and you're right !
d&c(gentle giant) where are you?
change your username with me d&c!

i forgot,sorry J-Wo!
i update the script like Kwag's MA but using temporalcleaner,
like Phil recomendations,then....
take undot and asharp to before Gripcrop.....like this:

nf=0
Undot()
Asharp(1,4)
GripCrop(480,480,overscan=1,source_anamorphic=fals e,dest_anamorphic=false)
GripSize(resizer="BiCubicResize")
.....etc!

this is right!

I didn't think it really made a big difference but to each his own. What was the reason we took out Limiter() ?

Because I decide to and Jorel stuck to my advice .

I don't remember where I justified that choice but the idea is that TMPGEnc already does this limitation by defautl. So, why doing this twice ?

If you want to know where it's done in tmpgenc, it's there : settings, quantize matrix, output YUV as Basic YCbCr and not CCIR601. Unchecked (the defautl) = same effect than Limiter().

Ok, so I guess I'll leave it out then and keep that option unchecked. KWAG still has it in his optimal script that's why I was wondering.
Thanks

Holomatrix,

the Phil explanations about limiter are here in this same thread,page 2:

http://www.kvcd.net/forum/viewtopic....r=asc&start=16

I don't see what explanation you are referring to but "Limiter" is entirely different as "output YUV as Basic YCbCr and not CCIR601". The first one just round [0,16] to 16 and [236,255] to 236, while the latter _scales_ [16,236] to [0,255] when leaving it checked (and not scaled when leaving it unchecked).

I don't know where you find that TMPGEnc scales up and not just clip values (if you can tell me where it's writen ). Btw, beside this thin diff, and despite what you seem to tell (do I misunderstand it ?), the result is the same : you end with values ranged from [16,235]. It's clearly said in the balloon that pops up on the screen when you let the cursor on the checkbox for a while (actually, with tmpgenc the lower limit is 8 and not 16).

So the question is still the same : why doing this twice ?

The resulting range is the same, but the result itself not (the values are distributed differently).

example: suppose pixel 1 has luma 24. With limiter this value remains 24. With the TMPGEnc checkbox it is changed to

y = x/2 + 8 [just an approx., don't know the exact formula]

x = 24 gives y = 24/2 + 8 = 20

I don't have the manual. But you always can do some tests to check this.

I don't have the manual. But you always can do some tests to check this.[/quote]

So it's just a supposition ? But it's not that is said in the pop-up help (balloon). The balloon said exactly this : "Then Y Mpeg range is 8-235 (and the help talk about 16-235 !), not 0-255". I don't see there any evidence of rescaling. So ? Did you make yourself any check or do you just take this out of your brain ?

BTW the correct formula is :

if input is [0,255] and output is [8,235], the right formula is :

y=x/255 * ( 235-8 ) + 8 = 0.89 x + 8

So x=24 becomes y= 29. What was I called a thin diff, but you're right, it is not so thin.

The problem there is to know who is right.