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:
Code:
GripCrop(480,480,overscan=1,source_anamorphic=false,dest_anamorphic=false) |
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 |
Quote:
the Phil explanations about limiter are here in this same thread,page 2: http://www.kvcd.net/forum/viewtopic....r=asc&start=16 :wink: |
Quote:
|
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 ? |
Quote:
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 Quote:
|
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. |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.