Bildartefakte bei MDegrain2

  • Hallo zusammen,

    Das sollte mein erster großer Einsatz von MDegrainX (nochmal vielen Dank an Didée für diesen Tip!) werden, und ich war auch zunächst ziemlich begeistert, bis ich beim sichten des Materials folgende Artefakte fand:
    Link (1MB @Mediafire)
    Achtet auf die Lanzenspitze des Reiters in der Bildmitte.

    Bei der benutzung von MDegrain3 gibts halt 3 Echos in beide Richtungen, und bei MDegrain1 halt nur eins.

    Das erzeugende Script sieht so aus...

    Ist was an meinen Einstellungen falsch oder passiert sowas halt mit Mdegrain? (wäre schade, das denoisen ist phantastisch!)

    /edit: Der Fehler kommt nicht von der Quelle!
    Grüße,
    Dis

    /edit2 Link korrigiert

    3 Mal editiert, zuletzt von Dispatcher7007 (17. August 2011 um 16:21)

  • Ach ja, das ist so'n Ding ... probier's mal mit blksize=16,overlap=8. Die Bewegungen von Hintergrund und Lanze sind tendenziell gegenläufig, da braucht man "bessere" Bewegungssuche um's besser einfangen zu können. Und mit der großen Blockgröße von 32x32 ist der 'relative' Fehler von der nicht-gefundenen Lanze halt auch geringer als bei kleineren Blockgrößen. (Außerdem hab' ich manchmal den Verdacht, dass mit der ganzen SAD-Handhabung irgendwas nicht 100%ig stimmt, wenn man 32x32 verwendet. Aber das ist Spekulation.)

    Es ist natürlich ein Dilemma:

    - Erst wollen alle Full-HD mit MVTools machen.

    - Dann isses aber vieeel zu langsam -- "wie kann man das schneller machen?"

    - Antwort: weniger rechnen

    - "Jetzt ist das Ergebnis aber nicht mehr so gut!!"


    Tjaja ... Geschwindigkeit und Qualität verhalten sich reziprok proportional. Das ist nix neues. :)

  • jaja.. selbst der Tod kostet das Leben^^

    Also mit blksize=16 sind sowohl overlap=4 als auch overlap=8 ohne dieses Artefakt! Hier würde ich overlap4 wählen, aus Tempogründen, oder? /edit: overlap=0 macht auch keine Probleme. Der Unterschied ist selbst bei standbildern winzig!

    Bei blksize=32 bringt auch overlap=16 nix. bei Overlap=24 kommt totaler Käse raus. Dazu ist das laaaaaangsam und produziert enorm hohe bitraten... Okay, wenn jedes Pixel 3x bearbeitet wird, und sich die einzelnen Bearbeitungen intern vielleicht noch gegenseitig vors Knie treten, kann das wohl nix bringen. for educational purposes...

    Ebenso:

    Zitat

    da braucht man "bessere" Bewegungssuche um's besser einfangen zu können


    würde es etwas bringen, die Bewegungssuche auf (sagen wir mal) umh laufen zu lassen, statt der standardmäßigen Hex-suche? /edit: habs getestet: Nope! blksize=32 ist anscheinend verbugt.

    Würde vllt, die von dir in einem anderen Thread angesprochene Bewegungssuche mit einem vorgefilterten Bild etwas bringen?

    Übrigens:
    Dir und noch einigen Anderen möchte ich hier mal ganz laut DANKE! sagen... Ohne dich und euch wäre ich schon öfters aufgeschmissen gewesen, und hätte ganz viel nicht gelernt auf diesem Gebiet, auch wenn ich noch immer weit am Anfang stehe.

    3 Mal editiert, zuletzt von Dispatcher7007 (17. August 2011 um 19:01)

Jetzt mitmachen!

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