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 :wink:

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)?4:(Width<=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. :wink:

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

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!

:wink:

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!
:wink:

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

:wink:

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.