digitalFAQ.com Forums [Archives]

digitalFAQ.com Forums [Archives] (http://www.digitalfaq.com/archives/)
-   Avisynth Scripting (http://www.digitalfaq.com/archives/avisynth/)
-   -   Avisynth: MA Script, MergeLuma line is not needed? (http://www.digitalfaq.com/archives/avisynth/8628-avisynth-ma-script.html)

e1miran 03-16-2004 10:39 AM

Avisynth: MA Script, MergeLuma line is not needed?
 
KWAG, Incredible or Dialhot (or whoever can help)

Just a question about the most recent "Optimal Script" posted 21/10/2003. It seems in another rather lengthy post regarding the MA portion of the script, that the MergeLuma line is not needed, and would produce further blurring since the MA included UnFilter on all the time.

Also there was some discussion as to the parameters for TemporalSoften.

What was the outcome of that post? I was a little lost reading it. Should the MA script be used as it appears in the sticky thread or should MergeLuma be deleted and TemporalSoften settings changed?

kwag 03-16-2004 10:47 AM

Re: Question about MA Script
 
Quote:

Originally Posted by e1miran
Should the MA script be used as it appears in the sticky thread or should MergeLuma be deleted and TemporalSoften settings changed?

Try it as it is posted, and check the result. If it's too blurred, remove the MergeLuma line.

-kwag

Dialhot 03-16-2004 10:49 AM

Re: Question about MA Script
 
Quote:

Originally Posted by e1miran
What was the outcome of that post? I was a little lost reading it. Should the MA script be used as it appears in the sticky thread or should MergeLuma be deleted and TemporalSoften settings changed?

For MergeLuma, the actual value is so light that the impact (visually and on the filesize) of the line is not really big. You can remove it if you are more happy without it, that's not really important.

For temporalsoften, I do not remember the discussion you mention but it's the kind of subject Incredible surely introduced. So I let him answer :-)

Dialhot 03-16-2004 10:54 AM

Quote:

Originally Posted by e1miran
Thanks. Do I just leave the TemporalSoften "as is", as well?

You can trust the MA. I do not say that there is no way to improve the present script in the temporalsoften line, but , the current script gives awesome results.

Edit: you remove your posts faster than I answer to them ;-)

e1miran 03-16-2004 10:55 AM

Thanks guys. You are video kings.

KWAG- OT...żEn que parte de P.R. vives?

kwag 03-16-2004 10:56 AM

Phil,

I think you edited e1miran post :lol:
I was going to reply, but the post is no longer here :!:

@e1miran,
I'm in San Juan :)

-kwag

e1miran 03-16-2004 10:58 AM

I deleted it because Dialhot had answered the question before I posted. :wink:

Dialhot 03-16-2004 11:04 AM

Quote:

Originally Posted by kwag
Phil,

I think you edited e1miran post :lol:
I was going to reply, but the post is no longer here :!:

Not this time :-). He erased it while I was answeriing :-D
Quote:

Originally Posted by e1miran
I deleted it because Dialhot had answered the question before I posted. :wink:

Tht's what we call an efficient forum :hihi:

e1miran 03-16-2004 11:29 AM

Quote:

Originally Posted by Dialhot
Tht's what we call an efficient forum :hihi:

No complaints here. :lol:

incredible 03-16-2004 01:25 PM

Including the hope, not to be erased ... I do give my opinion on Temporalsoften :)

Change the last two values of temporalsoften to ...,1,2) or ...15,2) instead of ...1,1) . Its reported that the mode2 (last value in the line) bug is solved and does give an advantage "they say" :wink:

According to MergeLuma(Blur(...)) I can only say that this version will shurely MORE blur at even very lowmo scenes compared to the threshold based version of MA before. Cause if NF already becomes 1 the blur of unfilter gets (-2,-2) means already a visible effect like the mergeluma(blur(...)) ... because the blurring process now processes continously! And thats the sense of the new MA: to avoid "oszillating" on Threshold value "edges" like it could happend at the threshold based version of MA before.

Thats why I deleted the MergeLuma(Blur(..)) line .... as blurring already starts that early, but thats only my personal IMHO :wink:

cweb 03-30-2004 01:20 PM

Just to add my own one cent to this thread... I noticed the optimal scripts don't bother to deinterlace. I on the other hand, always deinterlace. Perhaps that was why when I tried the MA script it was too slow... interesting..

incredible 03-30-2004 02:51 PM

@cweb

as in here in effective 90% of the encodings are progressive that MA wasnt purposed "in that state" to treat interlaced sources.
So be aware "what" you do interlace as here MANY users think they do need this as its very often really NOT needed (I only point to that NTSC DVD2AVI statistics window issue!).

Even telecined sources do get "restored easely" by adding a telecine().decimate() right after the importline of the MA script.
In case of Hybrid sources do take notice what the decimate() documentation says.

If you got a real interlaced soucre like documentations/concerts etc. you can watch out for Boulders "interlaced MA" version in here where the MA part does work correct on each "field" separately and will be "interleaved" after.

Do look here where you also find a way where you can convert 29.97i to 23.976p
http://www.kvcd.net/forum/viewtopic.php?t=9808

:wink:
Inc.

cweb 03-30-2004 03:04 PM

Thanks for the tips, incredible..

Yes I do use the fixed (non-MA) script for both interlaced sources (dvb-s pal) and non-interlaced sources (progressive dvd).

What I'm trying tonight with the MA script is a 90's tv show with lots of dancing and singing.. it has lots of movement. I took a small clip and found that it encoded very fast.. it surprised me actually (CQ 89) (also results with deinterlacing and without seemed quite similar, but the deinterlaced sample was smaller), so I was trying on the whole recording but that gave me a terribly low CQ (34).

I'll try the interlaced ma script on this one, thanks...

incredible 03-30-2004 03:22 PM

Look in the interlacing guide I posted above.

Interlaced encodings do need horrible much more bitrate to end up in the same quallity compared to progressive ones. :(
Thats also why on NTSC 29.97 "real" interlaced sources Sharfis_Brains function makes really sense, maybe the 60 fields per second smoothness wont be anymore but veeeeeery less risk of resulting blocks on movements. I think the relation speaks for itself :)


All times are GMT -5. The time now is 09:50 AM  —  vBulletin © Jelsoft Enterprises Ltd

Site design, images and content © 2002-2022 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2022 Jelsoft Enterprises Ltd.