Bewegungskompensiertes Deinterlacing - mvbob()

  • Huhuh. Nach dem Ding darfst Du auch müde und faul sein. Sieht richtig g.e.i.l aus! :wow:

    Fällt mir ein - Lord of the Dance wartet auch schon seit langem, mal dranzukommen :) - Hat viel niedrigen Kontrast und Cross-Motion. Wird das was?

    Und an den MV-Experten: Lassen sich inzwischen eigentlich brauchbare Vollkompensationen mit den MVTools machen, für handgemachte temporale Denoising-/Stabilisierungs-Zwecke, oder so ... ?

  • Ich würde auch gern mvBob ausprobieren. Ich hab auch alle benötigten DLL´s gefunden bis auf eine nämlich MVtools0991.dll ! Hat jemand nen Download-Link für mich ?

    Wenn ich das ganze dann getestet habe schreib ich meine Ergebnisse natürlich hier rein :)

    edit: Hab die DLL gefunden. Jets werd ich mal versuchen das ganze zum laufen zu kriegen :)

    edit2: Habs jets mal angetestet aber wieder abgebrochen. Bei meinem HDTV-Streifen von 45 Sek war er nach 30 min grade mal bei 3% im 1Pass. Da bräuchte ich für nen ganzen Film mindestens eine Woche das ist ein bißchen zu lange :)

  • wenn ich mich richtig erinnere hat Scharfis_brain in o.a. Link ein Package zum Download bereitgestellt in welchem sämtliche benötige Dateien inkl. aller DLLs bereits inkludiert sind.

  • Habe mal ein wenig an mvbob() herumoptimiert, soweit einfache Optimierung noch möglich war.

    Speedup: ein wenig, ca. 6% schneller

    Speicherbedarf: deutlich weniger, um ca. 25% reduziert. (z.B. 460MB -> 340 MB virtual memory.)

    Reduzierung des Speicherbedarfes ist wichtig. Bisher war mvbob mit 256MB praktisch unbenutzbar, auf 512MB-Rechnern ein Grenzfall, und nur mit 1GB RAM wirklich sorgenfrei zu genießen. Jetzt geht's auch mit 512 MB, und die Leute mit 256MB ... schauen immer noch in die Röhre ;)

    Funktionell sollte sich nichts geändert haben. Ausser, dass ich irgendwo in der Interpoliererei ein ReduceBy2() durch einen Bicubischen DS ersetzt habe ( bei ReduceBy2() besteht der Verdacht, dass ein Offset um ein halbes Pixel produziert wird ;) ).

    Zusätzliche bzw. geänderte Plugins:

    - LeakKernelDeint (letzte (?) Version, mit entfernter CacheLimit - Bremse)
    - RemoveGrain v0.9+
    - TDeint (v1b4, mit AP)
    - Undot braucht's nimmer - RemoveGrain kann's auch (aber ohne Fehler, wie bei Undot :) )

    Bitte mal testen, und Scharfi bitte gegebenfalls absegnen und verwalten.

  • Zitat von scharfis_brain

    wenn Du schon TDeint mit AP einbringst musst Du natuerlich auch den AP-Parameter mit nach aussen fuehren, sonst bringt das nix...


    Oops, stimmt. Per Default ist ja AP=-1, also deaktiviert :redface: - Müsste man noch nach draußen durchreichen.

    Viel verbockt haben kann ich eigentlich nicht. Im wesentlichen wurden nur

    - diverse blur(1) durch RemoveGrain(11) ersetzt (schneller & genauer)
    - dito für undot() --> RemoveGrain(1)
    - Overlay([mask]) durch MaskedMerge(), soweit YV12
    - Overlay([blend]) durch Merge() --> braucht aktuelle Avisynth Version
    - in den verschiedenen MVAnalyse()/MVCompensate() den (kleinen, unscheinbaren, und hier so wichtigen) IDX Parameter manuell gesetzt, damit die MVTools nicht bei jedem Aufruf einen neuen Arbeits-Stream interpolieren und puffern(!), sondern nur da, wo's wirklich nötig ist.

    Übrigens: Bei Problemen mit zu wenig Speicher empfiehlt es sich, SetMemoryMax() NICHT "so hoch wie möglich", sondern im Gegenteil so "niedrig wie möglich" zu setzen. Die MVTools arbeiten mit ihren eigenen, von Avisynth's Cache unabhängigen Puffern. Und diese können u.U. ziemlich groß werden ... wenn man also z.B. auf 'ner 512MB-Maschine, in dem Glauben Gutes zu tun, ein SetMemoryMax(384) verwendet, dann haben die MVTools womöglich nicht mehr genügend RAM für ihre eigenen Puffer ...
    Wild geschätzt, würde ich mal sagen: SetMemoryMax(xxx) mit xxx = 1/3 vom vorhandenen RAM (vielleicht 2/5 bei 256MB RAM, probieren), und nicht mehr.


    Hab' mich übrigens auch gefragt, ob man das TDeint-Bobbing nicht etwas beschleunigen könnte:

    - muss es der teure mtnmode=1 sein, oder tut's nicht auch mtnmode=0 (Static-o-matic kommt ja am Ende auch noch) ... bzw, wären nicht auch mtnmode=2|3 angezeigt?
    - muss es die langsame ELA-interpolation sein, oder täte es nicht auch Kernel-Interpolation

    ... oder der Benutzer zumindest die Auswahl haben sollte.


    Für's pre-Denoising bei sehr rauschigen Clips hab ich inzwischen beste Erfahrungen mit limitiertem Clense() gemacht, speziell in Hinsicht auf die Qualität von nachfolgender ME. Hab's nicht eingebaut, weil ich mvbob() funktionell unverändert lassen wollte. Wer's probieren will:

    Code
    calm = yv12lutxy(noisy, noisy.clense(), "x 3 + y < x 3 + x 3 - y > x 3 - y ? ?",
     \                                      "x 2 + y < x 2 + x 2 - y > x 2 - y ? ?",
     \                                      "x 2 + y < x 2 + x 2 - y > x 2 - y ? ?", U=3,V=3)

    (Schneller: LimitChange() aus den SSETools, statt yv12lutxy(). Noch schneller: ReduceFluctuations() ... aber da bastelt kassandro gerade so höchst merkwürdige und undurchsichtige Sachen mit interner Rekursion und ner zusätzlichen externen System-DLL ...)

    Beruhigt Rauschen sehr stark, bei nur minimalem Ghosting. Der Witz ist, dass dieses sehr leichte Ghosting der ME oftmals sogar hilft, Bewegungen besser folgen zu können ;) Ist also absolut Null Problem, wenn die "scharfe" Kompensation sowieso auf einem anderen Clip basiert, und nur die Vektoren der rauschreduzierten Version benutzt.
    Im gegebenen Fall könnte sich die hierdurch auch noch die "mismatch detection" etwas genauer gestalten lassen. Müsste man sich mal *ganz genau* anschauen ... ich hab' halt den "Gesamtablauf" nicht so richtig vor'm inneren Auge. (Das hat wohl nur einer ;) )

  • hui, Du hast da schoene Ideen eingebracht!

    Zitat

    Hab' mich übrigens auch gefragt, ob man das TDeint-Bobbing nicht etwas beschleunigen könnte:

    - muss es der teure mtnmode=1 sein, oder tut's nicht auch mtnmode=0 (Static-o-matic kommt ja am Ende auch noch) ... bzw, wären nicht auch mtnmode=2|3 angezeigt?
    - muss es die langsame ELA-interpolation sein, oder täte es nicht auch Kernel-Interpolation

    Folgendes Problem:
    Ich brauchte moeglichst ruhiges Material fuer die Bewegungsanneliese
    (statische bereiche MUESSEN statisch sein)
    das geht nur, wenn man einen VT-Kernel verwendet, denn dieser bringt in 0 bis 1 zeile/field bewegungen eine sehr gute interpolation (besseres PSNR) als lineare oder ELA interpolation.
    aber sobal die Bewegung groeszer als 1 zeile/field wird, ist die PSNR SCHLECHTER als linear oder ELA. Dieses stoert die mv-suche aber nicht. Das Auge schon.

    Deswegen musste dann auch der zweite Bobber mit ELA her (TDEINT; tomsmocomp gefiel mir nicht!), der dann fuer
    1) subpixelgenauigkeit sorgt, die ihresgleichen sucht, da ELA basiert interpoliert wurde
    2) mismatches damit aufgefuellt werden (jene sind eh bewegt!)

    und quasi-statiscche bereiche des kernelbobs, die noch ein wenig bobbelig sind, werden noch statischer, wenn man nach der MV-suche, welche leichtes Bobbing ja verschluckt, no die static-o-matic dranpappt und pures weave reinschmeisst.

    zu den interpolationsmethoden und deren PSNR folgendes PDF:
    http://neuron2.net/library/1996-09.pdf
    (die Diagramme ab seite 8)

    deswegen mag ich kernel ja auch nicht!
    der macht bewegungen mehr stairstepping als lineare interpolation.
    und dann noch dieses Kernel-ghosting...
    Das einzige was gut ist, ist dass es sehr gut im statischen bereich arbeitet.

    Wenn man bedenkt, dass selbst mocomp-standars converter mit kernel arbeiten wird mir grauselig :(

  • A propos ELA: da möchte ich nochmal den alten Bekannten Sangnom (MarcFD) ins Spiel bringen:

    Schlag(t) mich, aber ... was interpoliertes Upsizing angeht, gefällt mir der oftmals besser als die ELAs in TDeint ...

  • Code
    tritical = TDeint( settings=tralala, map=2 )
    
    
    myinterpolation = someinterpolation()
    
    
    yv12lutxy( tritical, myinterpolation , "x 255 = y x ?",x 255 = y x ?",x 255 = y x ?",U=3,V=3)
  • Der entsprechende "SangnomBob" sieht in etwa so aus:

    Sollte man mit getparity() & Co. einrichten ... aber da mach' ich dann bestimmt wieder alles falsch.
    Rest geht dann wie in obiger Post angedeutet.

    Auf originaler Horizontalauflösung ist Sangnombob um 50% - 100% schneller als TDeint(mode=1,type=3, mthreshL=mthreshC = 0 (!!) ). Mit horizontalem SS auf 150% sind beide fast gleich (TDeint minimal langsamer).

    Fehler bei der Interpolation machen beide. Trotzdem gefällt mir Sangnom eigentlich besser, wie gesagt. Nicht immer, aber überwiegend.

    Hab' hier gerade nix Schönes zum Zeigen da ... trotzdem, ein Auschnitt aus zwei aufeinanderfolgenden gebobbten Frames:

  • LigH: welchen Sinn hatte Dein Beittrag?

    @Didee: ich wusste doch, dass da was mit Sangnom im Argen war: keine Artifactprotection!

    dicht beisasmmen liegende senkrechte Linien manscht der einfach zu einem Klotz zusammen. Wenn ich dann den paramter runtersetze, gibts eine weniger starke ELA.

    Ausserdem macht die Sangnom-interpolation fuer meinen Geschmack ein viel zu Krasses Oel-Bild.

    Da gefaellt mir TDeints ELA besser, auch wenn die ein-pixel-loecher hinterlaesst.

    Tritical hat ja versprochen, dass sich mit Tdeint 2 auch dies bessert.

  • Entschuldigung, wenn sich hier noch ein Dritter mit einmischt. Aber was hat das jetzt alles bitte mit unseren Deinterlacing zu tun. Schließlich sprechen wir hier von Frames. Das heißt die Fehler sind vergleichsweise regelmäßig (manchmal auch etwas mehr) über das Video und das Bild verteilt. Hier gibt es keinen Totalausfall wie bei unser Schraubenkonstruktion, da die Videoobjekte nicht direkt miteinander verknüpft sind (zumindest nicht in dem Ausmaße).
    Entweder kann man damit leben oder halt nicht.
    Ich schlage vor, dass wir uns jetzt wieder etwas mehr am Thema orientieren.:ja:

Jetzt mitmachen!

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