Bewegungskompensiertes Deinterlacing - mvbob()

  • Ich habe mal das mvbob() ein wenig modifiziert. Es ist jetzt schneller (danke, Didee) und hat ein paar kleinere Modifikationen und Zusatzfunktionen bekommen.

    Parameter
    weggefallen ist: Predenoise
    hinzugekommen sind:
    bool quick
    - laesst mvbob() schneller laufen. Grund: TDeint als Predeinterlacer durch Leakkernelbob ersetzt. Static-o-matic abgeschalten.
    - durch Benutzung von 'quick=true' werden statische Bereiche nichtmehr sorgfaeltig beruhigt. Nur sinnvoll bei Handkameravideos OHNE statische Logos oder Einblendungen.

    bool convfps
    bei true wird 50 fps zu 59.94 fps konvertiert und 59.94 fps werden zu 50 fps konvertiert. Bewegungskompensiert natuerlich. Bei anderen Eingangsframeraten als 50 fps oder 59.94 fps wird nichts gewandelt.

    Ausserdem ist eine neue Funktion hinzugekommen: reinterlace()
    Eigenschaften: jeglicher Input wird brachial auf YUY2 konvertiert.
    Es wird die Eingangsfieldorder benutzt. Bei Bedarf vorher mit assume?ff() umbiegen.

    mvbob() schreibt nun auch selbsttaetig das Fieldorder Flag des Outputs um, sodass es zur Source passt!

    wer nun z.B. ein PAL-TV-Capture nach NTSC wandeln moechte, kann dies so tun:

    Code
    import("mvbob~.avs")
    avisource("capture.avi").assumetff()
    mvbob(convfps=true)
    bicubicresize(width, 480)
    reinterlace()

    meiner Meinung nach ein sehr uebersichtliches Script :)

  • Danke für die Arbeit. Ich bin sowieso gerade am Experimentieren mit Bobbern, da kann ich das Morgen gleich mal testen.

    Zitat


    meiner Meinung nach ein sehr uebersichtliches Script



    *grins* Bei soviel Komfort hättest' ja auch gleich noch convnorm=true mit einbauen können, spart dann noch 'ne Zeile. ;)

  • Zitat von Kika

    *grins* Bei soviel Komfort hättest' ja auch gleich noch convnorm=true mit einbauen können, spart dann noch 'ne Zeile. ;)

    ah nee. ich habs nicht so mit automatischen Resizern.
    Dies ueberlasse ich lieber dem (miss)geschick des Users, denn welches resizig soll das script denn machen, wenn ichs mit ner cropped source fuettere?
    Neenee. das bleibt so, wie es ist.

    btw.: hier mal eine PAL -> NTSC wandlung.
    http://home.arcor.de/scharfis_brain/mvbob/halfD1-mocomp.m2p

  • Und wieder mal steht die Welt Kopf. In der Vergangenheit hast Du so oft über TMCBob gewettert (à la "um Himmels Willen *nicht* mehr verwenden!"), und jetzt ist er, klammheimlich, wieder das Mittel der Wahl, um die Basis für die zu kompensierenden Bildinformationen zu liefern? /*verzweifel'*/

    Bei Gelegenheit schau' ich mir noch mal die Corrector() Geschichte an. Für die nächste Runde von LTSMC hab ich was gefunden, das wirklich superbe Arbeit leistet. Ist aber nicht ganz sicher, ob sich das auch auf diesen Bob-Kontext transportieren lässt ... das muss erst probiert werden.

  • Nana, TMC(kernel)bob war doch vor zwei Jahren sonne blend-matsch-sharpen Ausgeburt vonmir. Der ist da natuerlich nicht drin.

    Und tomsbob() - ich haette ihn wohl tomsbobstupid() nennen sollen - ist ja auch nicht fuer den alltaeglichen Bedarf gedacht. Es hat halt kein Motionmasking. Das Search-effort ist auch deaktiviert, da es nur zu unschoenen Treppcheneffekten im Output von mvbob()gefuehrt hat. Braucht es - wie ich festgestellt habe - fuer die Kompensation auch ueberhaupt nicht. Denn in statischen Bereichen sind die Vektoren ja sowieso schon statisch.

    Und da war mir halt der TDeint geschwindigkeitsmaeszig an dieser Stelle ein wenig zu teuer. Und die Interpolation von TMC und TDeint unterscheiden sich bei natuelichem Material nicht so sehr. Daher bin ich wieder zu ihm zurueckgekehrt. (anfangs war tomsbob() schon einmal an genau dieser Stelle)
    Bei Sangnom stoert mich wie eingangs schon erwaehnt der Oel-Effekt. Ausserdem kann er kein YUY2.

    Oh ja, die Corrector-Sache muss auf jeden fall noch ueberarbeitet werden, denn es gibt sackweise residual Combing. (mach mal nen Limitedsharpen mit SD->HD Skalierung nach mvbob!)

  • >> mach mal nen Limitedsharpen

    Weiß schon, weiß schon ... ;)

    Ist 'n generelles Problem zum graue-Haare-kriegen ... wenn interlactes Material wegen allgemeiner Matschigkeit nach dem Deinterlacen noch geschärft werden soll, dann gibt's Probleme. Bisweilen ist dann sogar ein einfacher Deinterlacer (ohne residual Combing im Output) einem "Komplizierten" (mit Residuals) vorzuziehen ...


    a propos "einfacher" Deinterlacer: schon mal kassandros ReduceFlicker (ältere Version, hat Gründe) geschnappt, und sowas wie

    bob(-.34,.67).ReduceFlicker(strength=1)

    probiert? Ein einfacher DummBob, der aber in statischen Bereichen absolut ruhig ist ... und eben kein residual Combing. Als Analyse-Bobber auch keine schlechte Alternative ;)

  • reduceflicker hat die gleichen probleme, nur viel staerker, als ein simpler deinterlacer wie Kerneldeint oder Tdeint (ohne AP). Naemlich das Loh-Problem bei linearen bewegungen gemusterter objekte.

    bob(..).reduceflicker(...)

    ist gleichzusetzen mit:

    irgendeinbob(mit hohem threshold).blur(0,1)

    das Loch-Problem irritert leider die motion estimation.
    bei TDeint ist dies - wegen der 5 field motionmask - nicht so sehr ausgepraegt.


    hmm. mit faellt grad was ein:
    da war doch dieser Smoothdeinterlacer fuer AVS 2.0
    der hatte das LOCH- Problem nicht, hatte dafuer aber andere optische macken, die aber die motion estimation nicht stoeren duerften.
    naja; spaeter mal gucken....

  • Zitat von scharfis_brain

    reduceflicker hat die gleichen probleme, nur viel staerker, als ein simpler deinterlacer wie Kerneldeint oder Tdeint (ohne AP). Naemlich das Loh-Problem bei linearen bewegungen gemusterter objekte.


    Jo, da ist was dran. Kann man aber recht einfach umgehen: nach Reduceflicker checkt man:
    pixel(N) - pixel(N-1) < [wenig] ? Use_Reduceflicker : No_Reduceflicker


    Zitat

    bob(..).reduceflicker(...)

    ist gleichzusetzen mit:

    irgendeinbob(mit hohem threshold).blur(0,1)


    Nein, also das nun wirklich nicht ...

  • aaaaaa, was hat denn das sample hier verloren?

    Fieldblends haben kein Loch-problem.
    nur echtes interlaced video kann sowas erzeugen.

    und wenn der deinterlacer loecher macht, dann sehen die aus wie residual combs. und wenn man diese vertikal blurrt sind die nur noch halb so hell.

    und genauso sieht reduceflicker auch aus.

    fuer Loecher guckst Du hier: http://forum.doom9.org/showthread.php…othdeinterlacer

    und bitte, bitte: kein Fieldblend in diesem Thread....

  • btw.: ich habe eben mal einen Deinterlacer mit langer temporaler maske zusammengeschustert (von null auf jetzt in 20 minuten)

    der haelt statische bereiche 100% statisch (keine marching ants mehr!), bobbt aber auch zuviel.
    Die Temporale Maske ist derzeitig 4 Frames (8Fields) lang, was fuer die meisten Zwecke okay sein sollte.
    Wenn 8 Frames (16 Fields) gewuenscht sind, dann in der staticmask einfach ec anstatt von eb0 zurueck geben.

  • Ich versteh' Dich schon, aber Du mich nicht ...

    Was mein Sample zeigt, ist nur, dass IrgendeinDeint.blur(0,1) *alles* vertikal verschmiert. bob.reduceflicker macht *nur* statische Bereiche unscharf, aber eben wiederum stabil. Und ohne residual Combing per se. Was in Hinsicht auf oben angesprochenes Schärfen-nach-Deinterlacen seine Vorteile hat. (Und um das zu zeigen, dafür tut's auch ein fieldblend-Sample. Das hatte ich halt gerade geladen. ;) )

    Das Loch- bzw. Artefakt-Problem kann man (sollte man) mit einfacher maskierung umgehen können, wie oben angedeutet. Ohne Temporale Analyse über 7 Frames. ;)

    Bin ich jetzt aber definitiv zu müde für. Gut's Nächtle.

  • Zitat

    Das Loch- bzw. Artefakt-Problem kann man (sollte man) mit einfacher maskierung umgehen können, wie oben angedeutet.


    Geht eben nicht. Weil Du Dir sonst wieder statisches Detail versaust.

    eine lange temporale maske. das ist genau der dreh und angelpunkt von TDeint2. anders kommt man dem IMHO nicht bei

    (so nun wirklich ins Bett)

  • Uuaaagääähhnnn .... mir träumte gerade, es ginge noch einfacher.

    Code
    dummbob = bob(-.34,.67)
    calmbob = dummbob.reduceflicker(strength=2)
    HEdge=dummbob.DedgeMask(0,255,0,255,"8 16 8 0 0 0 -8 -16 -8",divisor=2,U=3,V=3)
    calmbob2=maskedmerge(dummbob,calmbob,HEdge.expand(U=3,V=3),U=3,V=3)

    Kein Residual Combing, und statische Bereiche sind stabil. :zunge:

    Es geht ja nur darum, einem Dummbob das bobbing in statischen Bereichen abzugewöhnen. Reduceflicker macht das, aber es macht auch - Hilfe - in bewegten Bereichen Löcher ins Video. Also wenden wir ReduceFlicker nur dort an, wo bobbing sichtbar ist: auf horizontale Kanten.

    Probier das mal beim Sports-girl, hab den Clip leider nicht auf dem Rechner hier. Logo sollte stabil sein ... viel mehr statische Bereiche hat der Clip wohl nicht.

    Wenn man fleissig sucht, lassen sich vermutlich immer noch ein paar seltene Artefakte finden. Dafür müsste man die HEdgeMask nochmal temporal verlinken. Aber das muss jetzt echt nicht mehr sein.

  • Und wenn wir eh' schon dabei sind, könnten wir doch gleich noch in statischen Bereichen die volle Schärfe behalten, indem wir dort DoubleWeave() hineinpflanzen.

    *Nach* Reduceflicker auf den horizontalen Kanten:

    WENN: die maximale Differenz zum Vorgängerframe und Nachfolgerframe kleiner ist als die durch ReduceFlicker() verursachte Änderung
    DANN: ist der Bereich statisch, und wir können DoubleWeave() hineinkopieren.


    Ob diese Variante *wirklich* Artefaktfrei ist, muss noch probiert werden.

    Herrjemineh, ich wollt' doch schlafen ...

  • calmbob2 schaut sehr gut aus ist aber blurry!
    calmbob3 ist wieder voller artefakte.

    aber zur bloszen Bewegungsanneliese sollte calmbob2 aber sehr gut taugen, wenn man dann evtl noch tomsbob() anstelle von bob(-.33,.67) nutzt.

    ich werde das demnaechst mal testen.

    sollte ich dann doch noch kernel- und TDeint kommplett rausschmeisen koennen? Cool!

  • Ja, die Methode für calmbob3 war noch etwas zu einfach, bzw. zu optimistisch. Das geht schon noch besser, lass' mich nur ans Basteln kommen.

    BTW kann man für die bewegten Bereiche natürlich auch ELA-Interpolation verwenden ... geht dann auch schneller als sonst, weil TDeint ohne Bewegungskompensation aufgerufen werden kann - statische Bereiche sind ja schon versorgt. Einfach am Anfang

    >> elabob = tdeint(mode=1,type=3,mthreshl=0,mthreshc=0) #,AP=24) ## AP trotzdem probieren?

    definieren, und die MaskedMerge-Zeile lautet dann entsprechend

    >> calmbob2a=maskedmerge(elabob,calmbob,HEdge.expand(U=3,V=3),U=3,V=3)


    Und (fast) volle Auflösung in statischen Bereichen kriegen wir auch noch hin. Wenn's steht, darf's tritical in ne DLL packen ;)

  • hah, hab doch noch ne macke von calmbob2 gefunden:
    vertikal bewegte patterns haben immernoch das Loch-problem.

    ap brauchst Du bei 0-thresholds garnicht versuchen. denn es gibt ja keine Weaving artefakte, da ja nur gebobbt wird.

    und wie gesagt. tomsbob() reicht vollkommen, da dessen ELA sehr aehnlich zu der von TDeint type=3 ist.

Jetzt mitmachen!

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