Convolution3d(preset="vhsBQ") Problem

  • "Komplett" ist das Beispiel aber noch längst nicht, wenn im Plugins-Verzeichnis keine DLLs mehr liegen: Da müssten noch jede Menge "LoadPlugin"- oder "Import"-Einträge zu finden sein - für alle Funktionen, die nicht vom AviSynth-Kern angeboten werden: Clense, Repair, RemoveGrain, TemporalRepair, LimitChange ...

  • Didée

    Laden von SSETools.dll bringt auf meinem Athlon Thunderbird (hat meines Wissens nur SSE Integer, aber kein SSE Float) den Fehler "unrecognized exception!" (s. Anhang) bei folgendem Script:

    Somit steht mir LimitChange nicht zur Verfügung. Angeblich gibts ja auch eine Version von LRemoveDust ohne LimitChange. Ist die genauso gut und kannst du diese evtl. posten?

    Danke dir!

  • Zitat von Didée

    Haaalt, langsam.

    Letzteres ist der Funktions-Aufruf. Ersteres ist die Funktion selbst.

    Sprich, in "LRemoveDust(4,limit)" ist clense, repair & alles andere schon drin ...


    Sehr vewrirrend das ganze..das hatte ich ja gefragt ,ob ich erst oben die "Funktionskette" ins Script gebe ,und nacher LRemoveDust(4,2) eingeben muss.

    Diese Antwort oben hatte ich so verstanden ,das in LRemoveDust(4,2) das alles schon drinne ist und damit quasi automa verwendet wird mit dem jeweiligen Wert wie zb (4,2) ....

    Gut nun also so ::

    funktioniert jetzt auch ohne die Fehlermeldung "there is no funktion named LRemoveDust" scheint also zu gehen...und sogar mit der RemoveGrainSSE2.dll

    Ok. Also Vor der AviSource die Funktionen ,und danach mit LRemoveDust(4,x) den Threshhold dafür....

    Glaube ich habe da die ganze Zeit etwas grundlegen falsch verstanden...

    gruss

  • Warum ist das verwirrend? Überleg doch mal:

    a) Du läßt die Deklaration weg: Wie soll AviSynth dann die Funktion ausführen, wenn es nicht weiß, was darin ablaufen soll?

    b) Du läßt den Aufruf weg: Dann wird die Funktion ja nie angewendet.

    Nein, es muss schon beides vorhanden sein: Erst muss AviSynth die Funktion kennenlernen, und dann auch noch anwenden.
    __

    Wenn ich jetzt auch noch davon anfange, dass AviSynth ein Skript eigentlich "von hinten" liest, also im Skript eigentlich erst die Anwendung und dann erst die Deklaration verwendet werden könnte... -- Nee, lass mal so, wie's funktioniert.

  • jup...wie gesagt, hatte grundlegend was falsches im Kopf...konnte ja nix werden.

    Die Funktion lässt sich ja auch leicht automatisieren mit einer .avsi datei ....

    Danke für die Hilfe :)

  • Didée

    Die Version ohne SSETools bzw. LimitChange müsste dann diese hier sein, richtig?

    Zumindest läuft diese hier auch auf meinem Athlon T-Bird einwandfrei!

    Gehe ich recht in der Annahme, dass der Wechsel von YV12lutxy (MaskTools) auf LimitChange (SSETools) keinen qualitativen, sondern nur einen Geschwindigkeitsvorteil bringt?

  • verdammt ist der RemoveGrain schnell..... :D

    Habe ein XVID 2pass encoding gemacht auf eine 4:3 Source mit 1900Bitrate
    Gesamtes encoding dauerte mit LRemoveDust(4,2) knappe 5 std ..
    Mit Convolution3d über 9std !!!

    Die Qualität ist sehr gut! Gut zu vergleichen Mit PixieDust(5)..nur der hätte bei der Qulle fast 20std gebraucht :)

    Hat jemand Erfahrungen mit der ModerateSharpen Funktion des Plugins ?
    Die Funktion aus der Readme schärft doch etwas zu viel...

    Oder zb welcher Unfilter Wert würde gut zur Filterroutine des RemoveGrain passen ? Oft nehme ich Lanczos ,aber nur bei sauberer Quelle mit hoher Auflösung und viel bpf Verhältniss.

    Gruss

  • @ acrowley:

    Jo, ist ein recht flottes Filterchen, nicht wahr?

    kassandro hat sogar von Extremfällen berichtet, in denen das XviD-Encoding mit RemoveDust() um 20%-25% schneller war als direktes Encoding ganz ohne Filterung!

    Wie kann das sein? Im gegebenen Fall hatte die Quelle *sehr* starke Körnung -- durch die [sehr schnelle] Verminderung des Rauschens wurde für XviD die Bewegungssuche während des Encodings viel einfacher, und deswegen lief der Prozess mit Filterung schneller als ohne. Allerdings war das RemoveDust, nicht LRemoveDust.

    Betreffs ModerateSharpen: Da sollte man schwächere Werte für den Sharpen()-Befehl verwenden, je nach Quelle 0.2 bis 0.6. Sharpen(1) ist vieeel zu viel, ohne Supersampling.

    Wenn's richtig gut werden soll, geht meine Empfehlung natürlich zu LimitedSharpen. Zwar deutlich langsamer, aber auch deutlich "besser".


    @ grua

    Antwort auf alle Fragen: Ja. :)

    Das ist die Version, und die Quali ist genau die gleiche, nur einen Tick langsamer. Hab' noch nie verglichen, wie groß der Unterschied LimitChange()<--> yv12lutxy() in der Praxis wirklich ist. Aber so sehr viel kann das eigentlich nicht ausmachen.

    Allerdings ist das die "Limiting-nur-für-Luma"-Version. Der Vollständigkeit halber kommt nachfolgend eine "vollständige" Version, mit mehr Möglichkeiten für's Chroma-Processing (mit yv12lutxy statt LimitChange):

    LRemoveDust( _mode, [limit], [limitC] )

    "_mode" und "limit" machen das gleiche wie bisher auch (logisch)

    limitC = ...

    ... [1,255] - beschränkt Chroma-Änderungen auf maximal diesen Wert.

    ... [0] -- kein Limiting für Chroma (schneller)

    ... [-1] -- Chroma? Was ist das? (Noch schneller, für B/W-Clips. Hinterher manuell Greyscale() anwenden!)

    ... [-255,-2] - die U/V-Ebenen werden mit diesem Wert gefüllt.

  • Habe die Funktion limitedSharpen mit den Defaults mal angetestet !!! Hammer,aber dauer sehr sehr lange zu encoden...bald mehr wie doppelt so lange .
    Aber das Ergebniss ist phantastisch..kein Vergleich zu Lanczos oder auch ASharp.
    Bei der Quelle hätte es mit Lanczos schnell Artefakte gegeben.
    Das Ergebniss mit LimitedSharpen ist gestochen Scharf, ohne noch vorhandenes Rauschen zu verstärken bei dreckigen Sources...

    Nochmal danke für die guten Tipps

    Gruss

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!