Benutzt jemand die x264-built-in denoiser-funktion --nr? Bin positiv überrascht...

  • Ich hab das grade mal gemacht, und mit VirtualDub Standbilder mit diversen anderen Rauschfiltern verglichen, und ich muss sagen... mir gefällt das sehr gut!

    Hat damit schonmal jemand erfahrungen gesammelt?

    Besonders das Verhältnis von Datenreduktion zu Detailvernichtung ist bei meinem Beispiel ausgezeichnet gewesen. Deutlich kleiner als deen() aber wesentlich weniger Matschepampe. Den Geschwindigkeitsaspekt hab ich mal rausgelassen, weil ich parallel am Rechner noch was anderes gemacht hab.

    Ansonsten habe ich versucht:

    - Die bei staxrip mitgelieferten Rauschfilter, aber die waren sehr enttäuschend. Kaum sichtbarer und messbarer Effekt (Dateigröße), außer die "extreme"-Einstellung (deen), die aber schon deutlich vermatscht.
    - fft3dgpu (viele Einstellungen, weils durch die sharpen-funktion mein bisheriger Lieblingsfilter ist, die war aber hier ausgeschaltet, da bei denoiser-vergleich wenig sinnvoll)
    - DeGrainMedian (nur standardwerte)
    - Removegrain(22) 22 soll recht schnell sein, mittelstark denoisen und wenig artefakte liefern... hab ich so aus einer beschreibung entnommen, ohne große Vergleichstests

    Welche Denoiser verwendet ihr sonst so?

    Grüße...

    Einmal editiert, zuletzt von Dispatcher7007 (8. August 2011 um 20:49)

  • "Nehmen wir doch mal, zum Beispiel, ein Beispiel." (Harald Lesch)


    Sample: (altes) TV-cap von "Aliens"

    ohne Filter: x264 --preset veryslow --tune film --nr 0 / 500 / 1000
    MDegrain3: x264 --preset veryslow --tune film

    http://www.mediafire.com/?pq8caalcdzjfr9w (19 MB)

    nr=0: =====> 4702 kbps ( +-0%)
    nr=500: ===> 4315 kbps ( -8.2%)
    nr=1000: ==> 4046 kbps (-13.9%)
    mdegrain3: => 2282 kbps (-51.5%)


    Ziemlich extremes Beispiel, aber bei einfacheren Verhältnissen ist die Tendenz meistens die gleiche:

    NR=x ist schnell, MDegrain ist gut. ;)


    Falls es ausdrücklich um Anime/Cartoon gehen sollte: das ist 'ne Welt für sich, die normalen Naturgesetze gelten dort oftmals nicht.

  • Yeah, Lesch-Zitate: "Also mit Ausserirdischen die nicht weiter sind als Microsoft und Apple will ich persönlich nix zu tun haben. (@Independence Day) "

    neenee, ich habs nicht mit animé...

    Zitat

    MDegrain ist gut.


    ist das das allgemeine Credo?
    Den hab ich noch nicht versucht, kommt heute abend.

    Was mir nur aufgefallen ist, ist das nr=1000 immer noch RELATIV sanft vorgeht. 2000 macht bei HD Quellen gar nix. Ich weiß jetzt noch nicht, wie das optische ergebnis im vergleich zum mdegrain aussieht.

    Grüße

  • Ich will es nicht als "Authoritätsbeweis" bezeichnen, aber Didée zählt sicherlich zu den erfahrensten AviSynth-Nutzern unseres Boards. Insbesondere was so aufwändige Filter wie MaskTools und MVTools angeht.

    Was die Rauschfilterung in x264 angeht, so kann ich zwar nicht wirklich fundierte Grundlagen vorweisen, aber ich würde mal vermuten, dass deren Funktion wohl überwiegend auf Eigenschaften der H.264-Komprimierung basiert. Das heißt, die Entscheidung, was im Bild unterdrückt wird, dürfte wohl vor allem darauf basieren, wodurch die Komprimierbarkeit verbessert wird. Nicht zwangsläufig aber darauf, was besonders wenig auffällige Verluste nach sich zieht. Vom Bauchgefühl her würde ich also MDegrain eventuell ein etwas intelligenteres Vorgehen zutrauen...

    Natürlich ist das alles subjektiv, also "Geschmackssache". Nicht jeder empfindet die gleichen Verluste als gleich störend.

  • Hi!

    Die Subjektivität macht natürlich die Entscheidung komplizierter...
    Ja, das Didée (aber auch du, und Selur, und noch ein paar Leute) richtig Ahnung von der Materie haben, hab ich in meinen gelegentlichen Ausflügen hier bereits festgestellt.

    Nun mal zu MDegrain: Ich hab das eben mal in der Mittagspause mit dem "Referenz-Code" (aus der Dokumentation) zusammengebastelt. Sieht so aus:

    Code
    super = MSuper(pel=2, sharp=1)
    backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
    backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
    forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
    forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
    MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)

    Das ist aber grottenlangsam. 0,8fps bei 40% Prozessorlast. Ist das normal? Ich benutze kein AvisynthMT. Die geringe Prozessorauslastung ist ziemlich gleichmäßig über meine 4 Kerne verteilt... Das spricht gegen den Nutzen von MT... Hat das mal wer versucht.

    Kann man durch cleverere Einstellungen bei vergleichbarem Ergebnis noch was an Tempo rauskitzeln? Es gibt ja noch (gefühlt) ein paarhundert Schalter, zum dran drehen...

    Die qualität ist bei vergleichbarer Dateigröße vllt (kann auch eingebildet sein) einen Tick besser als fft3dgpu(beta=1, sigma=2, plane=4, bt=4, mode=1, sharpen=0, precision=1, bw=32, bh=32), aber halt 10x so langsam...

  • Kann man durch cleverere Einstellungen bei vergleichbarem Ergebnis noch was an Tempo rauskitzeln?

    Versuch' mal das hier:

    Code
    sc = MSuper()
    backward_vector = MAnalyse(sc, isb =  true, delta = 1, blksize = 16, overlap = 4, truemotion = false)
    forward_vector =  MAnalyse(sc, isb = false, delta = 1, blksize = 16, overlap = 4, truemotion = false)
    MDegrain1(sc, backward_vector, forward_vector, thSAD = 400)
  • Selur - hab's vorhin mal mit nr 9900 durchlaufen lassen - probiere gerade es hochzuladen, aber "auf Arbeit" ist es Glückssache obs klappt oder nicht. Verbale Beschreibung: bei ansonsten identischen Einstellungen resultiert eine Bitrate von 2494 kbps, und es sieht wirklich nicht gut aus.
    Ah, es ist durchgelaufen: http://www.mediafire.com/?x678k6gxzydho5a


    @Dispatcher2007:
    Also, ohne MT, mit normalem single-threaded Avisynth, ist MDegrain kein große Freude. Multithreading macht da schon Sinn. (Wenn ich auf meinem 4C8T x264 mit --threads 1 laufen lassen würde, wäre die Freude am Speed ja auch nimmer so prall ...)

    Dann muss man auch noch unterscheiden, ob man mit SD arbeitet, oder mit 720p oder gar 1080p HD-Quellen. Gerade bei 1080er HD sollte man die Einstellungen anpassen. z.b. ist blksize=16 nicht nur deutlich schneller als der Default (blksize=8), sondern bei HD meistens sogar aus filtertechnischer Sicht empfehlenswert. (Bei zu kleiner Blockgröße besteht Gefahr, dass "Rauschen" sozusagen als "Detail" interpretiert wird, und die Motion-Engine versucht die Fluktuationen des Rauschens als "Bewegung" zu kompensieren. Und genau das will man gerade nicht haben.)

    Der Vergleich zur "Universalwaffe" FFT3dFilter muss natürlich sein. Die Wertung hängt von vielen Faktoren ab - nicht zuletzt auch ziemlich stark vom persönlichen Geschmack. Dem einen gefällt dieses, dem anderen jenes besser ...
    Meine persönliche Meinung ist, dass FFT3D dann eine gute Alternative ist, wenn nur "kleines" Rauschen vorhanden ist und ein wenig gemildert werden soll. Je stärker das Rauschen, um so mehr neigt FFT3D zum übertriebenen Glatt-bügeln, vorausgesetzt die Sigma's werden entsprechend weit aufgedreht.
    Bei stärkerem Rauschen neige ich eher dazu, FFT3D als reinen Hilfsfilter für die Bewegungssuche der MVTools zu verwenden. (;

    Jedenfalls, es ist immer so eine Sache, "allgemeine" Beurteilungen zu treffen ...
    Meine allgemeingültige Beurteilung ist eigentlich meistens die:

    "Bevor ich das Quellmaterial nicht in Augenschein genommen habe, empfehle ich gar nichts." :D

  • OK, just for you nochmal mit nr=100000. Sooo sehr viel tut sich da aber nicht mehr --

    CRF 18 NR 4000 ----> 3071 kbps
    CRF 18 NR 8000 ----> 2573 kbps
    CRF 18 NR 9900 ----> 2494 kbps
    CRF 18 NR 100000 --> 2377 kbps

    -- außer natürlich, dass es immer noch besch..eiden aussieht.

    Zum Vergleich,

    CRF 24 NR 0 ------> 2409 kbps

    sieht viel, viel besser aus, als dieses rumgemurkse mit extremen NR-Werten.

    Stellt sich natürlich die Frage: wann bringt NR=xxx überhaupt Vorteile, gegenüber einer einfachen Erhöhung des CRF-Wertes (oder allgemeiner, einer Absenkung der Bitrate) ?

    Fragen über Fragen ... "ein Teufelskreis!" :D


    @Dispatcher2007

    Wollte noch sagen: seit Einstein weiß man, "Geschwindigkeit ist relativ". :)

    Schnapp' Dir doch z.B. mal tritical's "TNLMeans" (->LINK), dann probier' mal

    Code
    TNLMeans(Ax=6,Ay=6,Az=1,Sx=2,Sy=2,a=4,h=6)

    und schon bekommt das Wörtchen "Geschwindigkeit" eine völlig andere Bedeutung!

    Achtung: Vor dem Ausprobieren unbedingt anschnallen!! *)


    *) wichtig wg. Unfallverhütung. Wenn man einschläft und vom Stuhl 'runterfällt, kann man sich ziemlich weh tun.

  • @ --nr:
    Die Parameter-Grenze ab der es hässlich wird, liegt für meinen Geschmack bei 2000-3000. Danach wird gematscht, und bringt auch nicht mehr so viel Datenreduktion. Bei FullHD-Quelle. Bei SD Auflösung liegt das wahrscheinlich früher. Aber stimmt schon: Qualitätsmäßig kanns beim genauen hinsehen nicht ganz mithalten... ob man da mit cfr-variation nicht besser dran wäre, ist natürlich eine gute Frage...

    @fft3d:
    Klar, bei hohem Sigma matscht das auch. Mehr als 3 hab ich noch nicht verwendet, und das auch nur selten. Wenn man solches Rauschen hat, das sigma 3 benötigt wird, dann geht das kaum ohne Matscherei, oder?

    Das die "perfekten" Einstellungen immer von der Quelle abhängen, und es den "besten" Denoiser sowieso nicht gibt, sondern nur unterschiedlich schlechte, ist ohnehin klar.
    Quellmaterial kann ich leider nicht posten, da copyrights und so... Dazu zählen doch auch Standbilder, oder? ich hab jetzt schon 20 Vergleichstest mit immer dem gleichen Frame gemacht, und dabei sind (imho) ein paar interessante Ergebnisse... und ich würde die euch auch zur verfügung stellen, wenns legal und erwünscht ist...

    Zitat

    Bei stärkerem Rauschen neige ich eher dazu, FFT3D als reinen Hilfsfilter für die Bewegungssuche der MVTools zu verwenden.


    Du machst ja Dinge, deren Existenzen für mich unbekannt sind^^ sieht das ungefähr so aus:

    Wenn nicht, kannst du mal ein codebeispiel dafür geben?

    @Groucho:
    Ja, damit bekomme ich meinen Rechner ausgelastet bei ca 4fps (x264 preset slow) Ist zwar immer noch etwas langsamer als fft3dgpu. Vom Ergebnis her ists auch seeehr ähnlich zu sigma=2.
    MDegrain ist in jedem Fall ein Sehr guter denoiser...

    /edit: Was wären denn alternativen für den Schärfefilter von fft3d?

    Einmal editiert, zuletzt von Dispatcher7007 (9. August 2011 um 16:40)

  • sieht das ungefähr so aus:


    Kann man machen, aber das war nicht gemeint. Gemeint war, dass man erst mal eine "Dummy"-Entrauschung durchführt, und darauf die Bewegungssuche durchführt. Mit den gefundenen Vektoren wird dann das noch-nicht-entrauschte Originalvideo per MDegrain gefiltert.
    Das sieht dann in etwa so aus:

    Es ist aber nicht so, dass dieses Verfahren unter allen Umständen besser wäre. Bevorzugt macht man das so, wenn das Rauschen im Quellvideo so stark ist, dass es die Bewegungssuche stört, und/oder ein zu großes "thSAD" in MDegrain erforderlich machen würde.

    Für Pippifax-Rauschen braucht man sowas natürlich nicht.

    Existierende Funktionen, die dieses Verfahren (unter anderem) umsetzen, wären z.B. "TemporalDegrain" oder "MCTemporalDenoise".


    Zitat von Dispatcher2007

    Was wären denn alternativen für den Schärfefilter von fft3d?


    Jeder Schärfefilter kann eine brauchbare Alternative sein.

    Welcher sich am ehesten anbietet - siehe:

    Zitat

    "Bevor ich das Quellmaterial nicht in Augenschein genommen habe, empfehle ich gar nichts."

  • Clever... gefällt mir! Ich werde das bei gelegenheit mal verwenden, wenn du gestattest...

    Das mit dem Schärfefilter verschieb ich mal auf später in einem dafür gemachte Thread im richtigen Themenbereich. Darf man denn hier Quellmaterial veröffentlichen?

    Da die Bewegungsanalyse ja ein zentraler Bestandteil x264 ist, und die dort in jedem Falle durchgeführt wird, wäre das dann nicht auch eine sinnvolle Stelle, um einen guten Rauschfilter-Algorithmus zu integrieren? Dann verbrät man diese Rechenleistung nur einmal, kann deshalb auch höheren Aufwand betreiben, etc... Auf diese Idee werden ja schon viele Leute vor mir gekommen sein, was spricht dagegen?

  • ... ALERT... ALERT ... WALL-OF-TEXT AHEAD ... ALERT ... ALERT ...


    Ja, in der Theorie klingt das erstmal gut. Die Idee wurde schon früher vorgeschlagen. Leider gibt es ein paar Argumente die dagegen sprechen, und vermutlich deswegen wurde es nie umgesetzt. Ich beschränke mich mal auf ein Hauptargument:

    Die Bewegungssuche vom x264-encoder ist sehr stark darauf optimiert, genau die Bewegungsvektoren zu finden, die optimal für das Encoding sind. Es geht x264 hauptsächlich darum, jeden 8x8 Block (oder 16x16, 4x4, 8x4/4x8) so "billig" wie möglich zu komprimieren. Für den Encoder ist das das A+O, und nichts anderes. Und weil x264 das sehr erfolgreich macht, ist er einer der besten Encoder die's überhaupt nur gibt.

    Dieses Verhalten ist für "Entrauschungs"-Filter aber oft kontraproduktiv, oder zumindest suboptimal. Nehmen wir mal das Beispiel einer unbewegten glatten Wand mit Filmgrain. Das Rauschen ist ja hochgradig unregelmäßig. Deswegen führt ein "einfaches" zeitliches Filtern (einfach = ohne Bewegungskompensation) dazu, dass sich die Fluktuationen im Durchschnitt alle gegenseitig neutralisieren. Der Filter ist erfolgreich.
    Wenn nun aber eine "zu gute" Bewegungskompensation ins Spiel kommt, dann passiert folgendes: Obwohl sich eigentlich nichts bewegt, findet die Bewegungssuche "Mini-Bewegungen", so dass das Rauschen in den 8x8-Blöcke in aufeinanderfolgenden Frames besser zusammenpasst. Für einen Encoder ist das sehr vorteilhaft, aber für einen Rauschfilter ist das ziemlich nachteilig. Der Rauschfilter will, dass sich die Fluktuationen gegenseitig auslöschen. Aber wenn die Blöcke durch die Bewegungssuche so gut wie möglich auf "gegenseitige Ähnlichkeit" abgestimmt werden, dann funktioniert diese Auslöschung nicht mehr richtig, und die ganze Entrauschungsgeschichte verliert an Wirksamkeit.
    Man kann den Stiefel auch nicht einfach umdrehen: Wenn man die Bewegungssuche so abstimmen würde wie es für das Entrauschen am besten ist, dann wären die Vektoren nicht mehr gut für's Encoding geeignet, d.h. x264 würde zu einem schlechten Encoder werden. Also erst recht kein guter Deal.

    Brrr, viel Text. Hier ein Beispiel: (auch schon älter, aber passt hier ganz gut)

    http://www.mediafire.com/?oi0njgsgvduokw4 (~10 MB)

    Das ist ein kurzer Clip mit sehr starkem Filmgrain. Gezeigt werden soll, dass bei MVTools kleine Blockgrößen (hier: blk=4) stark dazu neigen können, dem Rauschen in der Quelle per Bewegungsvektoren "zu folgen", womit das Entrauschen deutlich an Wirksamkeit verliert. Wohingegen große Blockgrößen (hier: blk=16) einigermaßen unempfindlich gegen diesen Effekt sind.

    Vergleich:
    Ein See, etwas Wind, ein recht großes Boot, und ein ziemlich kleines Boot. Der Wind verursacht kleine Dünung im Wasser. Dem großen Boot ist das egal, es liegt völlig ruhig. Das kleine Boot (Modellbauschiff) aber schaukelt und schaukelt und schaukelt.


    Kurz und gut - würde man die Vektoren von x264 zum Entrauschen verwenden, dann wäre das Ergebnis wohl ziemlich ähnlich zum Fall "blk=4". Das wäre aber nicht besonders gut, und deswegen wurde diese Idee auch nicht umgesetzt.


    Dazu kommen dann noch andere Kleinigkeiten, die das ganze technisch verkomplizieren:
    a) x264 sucht gar nicht alle möglichen Vektoren zwischen allen Zielframes, sondern nur die erfolgversprechendsten. Zum (wirksamen) Entrauschen bräuchte man aber alle. --> es würde ebenfalls deutlich langsamer werden
    b) die adaptiven Partitionen von x264 (16x16, 8x8, 8x4, 4x8, 4x4) machen das Unterfangen dabei nicht einfacher.
    c) Es gibt bei x264 nicht die Möglichkeit zu Block-Überlappung. Für MVTools/MDegrain ist das aber ein wichtiges Qualitäts-Instrument
    d) von Problemen wegen der unterschiedlichen Frametypen (I/P/B) ganz zu schweigen. Insbesondere I-Frames, weil für die ja gar keine Interframe-Vektoren gesucht werden...


    Es gibt also auch so einige rein technische Hürden. Und wenn man diese irgendwie meistern würde, dann hätte man ein Verfahren, das längst nicht so wirksam und flexibel wäre wie die separate Avisynth-Methode, die bereits verfügbar ist.


    ==> viel Arbeit, die am Ende nur mäßigen Erfolg bringen würde.

    Und den Stiefel will sich eben keiner anziehen. :)

  • Ich reaktivere mal diesen Thread...

    Zum encodieren benutze ich x264 64bit eigentlich nur unter Linux, da ich unter diesem OS den besten Zugriff auf Rechenpower habe.... (12 Kerne aufwärts.. ) Jetzt habe ich zZt. einige Quellen mit viel Rauschen und würde das gerne etwas reduzieren.
    Unter Windows würde ich da zu avisynth greifen und RemoveGrainHD oder ähnliches durchtesten. Allerdings keine Option.

    Weiss einer einen Weg, wie ich per ffmpeg oder x264 entrauschen kann? Per x264 wird ja schon die nr - Option hier angesprochen, nur welche Möglichkeiten gibt es noch? Jemand in der Richtung eine Idee?

    Der Weg zur Dunklen Seite... Schneller er ist, verführerischer, leichter.

  • Der x264-Parameter -nr ist weniger ein "Entrauscher", eher ein "Rauschignorierer", also ein Unterdrücken höherer Frequenzanteile (leider auch wenn diese nützliche Struktur enthalten).

    Laut Eigendokumentation (ffmpeg -filters) enthält ffmpeg – zumindest die Version, die aktuell bei MeGUI dabei ist – auch "hqdn3d — V->V — Apply a High Quality 3D Denoiser." Aber wie man den anzuwenden hat und wie der zu konfigurieren wäre, weiß ich noch nicht genau; es beginnt vermutlich mit:

    ffmpeg -i input -filter hqdn3d -vcodec libx264 ...

Jetzt mitmachen!

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