AviSynth - geeignet für Bildbearbeitung?

    @ Archimedes1:

    Kannst du mal die jeweils aktuelle (bzw. empfohlene) Version irgendwo bei einem unkomplizierten Webhoster (also alles außer RapidShare), meinetwegen auch als Anhang, jeweils dauerhaft unterbringen und im ersten Beitrag dieses Themas verlinken? Nicht dass ich in dem Thema irgendwo einen Link übersehe. Ist die Version vom 17.7. noch die aktuellste zur Zeit?

    Ich würde sogar etwas Webspace sponsorn, wenn das mit dem Aktualisieren von Anhängen nicht so vorteilhaft ist (je nach Archivgröße) - evtl. Zusendung via Email, Adresse per PN.

    Ja, die Version 2007.07.17 ist immer noch aktuell. Leider sind als Anhang nur 2 MB erlaubt, so dass ich ich nicht die komplette Umgebung (inkl. der Vorlagen) in einem Archiv unterbringe.

    Habe die kompletten Vorlagen, das sind die Scripte und Plugins, in ein extra Archiv gepackt. Noch sind es weniger als 2 MB. Man braucht dann später nur noch das Template-Verzeichnis zu aktualisieren. Im Progamm-Archiv sind aber trotzdem schon mal die ersten Scripte enthalten.

    Habe die beiden Archive im 1. Beitrag verlinkt.


    siehe: http://forum.doom9.org/showthread.php?t=89941

    Cu Selur

    Zitat von Selur

    irgend eine Fehlermeldung oder sind deine Grafikkarten zu alt?


    In meinem Videoschnittrechner ist eine Nvidia Geforce 4 MX 460 enthalten – damit ist der schon mal aus dem Rennen. Es kommt zu folgender Fehlermeldung:

    [Blockierte Grafik: http://img514.imageshack.us/img514/9127/fft3dgpufehlermeldungov7.jpg]

    In meinem Notebook ist eine NVIDIA GeForce FX Go 5200 für die grafische Darstellung verantwortlich, aber auch da will FFT3dGPU nicht laufen:

    [Blockierte Grafik: http://img509.imageshack.us/img509/681/fft3dgpufehlermeldungwf2.jpg]

    Solange man nicht zu stark entrauschen muss, ist FFT3DFilter bzw. FFT3dGPU sicher eine gute Lösung. Beim nachfolgenden Bild hatte ich jedoch Probleme, den Hintergrund einigermaßen hinzubekommen. Als Einstellungen habe ich "sigma=6.0, bw=16, bh=16, strength=0.0" verwendet. Selbst ein Erhöhen der bw- und bh-Werte brachte nur minimale Besserung. Mit dem FrFun7-Script und den Einstellungen „Lambda=1.5, T=12.0, Tuv=0.0, strength=0.0“ sah das Ergebnis besser aus (weniger "Artefakte" im Hintergrund), aber immer noch nicht ideal. Vermutlich sind die Filter einfach "zu gut" - ich kann diese "Artefakte" nämlich auch im Original erkennen. :lol:

    Ich stelle mal alle Bilder (Original, FrFun7- und FFT3DFilter-Ergebnis) zur Verfügung.

    Eines habe ich jetzt schon herausgefunden, der Einsatz von FFT3DFilter bzw. FFT3dGPU macht nur bei weniger stark verrauschten Bildern Sinn. Aber auch da muss man aufpassen, dass an Kanten nicht diese eigenartigen „Artefakte“ bzw. „Ringe“ entstehen, was, wie wir ja gesehen haben, durch eine kleinere Blockgröße verhindert werden kann.

    Ich bin zu dem Entschluss gekommen, dass etwas stärker verrauschtes Bildmaterial generell einer dezenten Vorfilterung bedarf (z. B. RemoveGrain(mode=2)), bevor es mit FFT3DFilter bzw. FFT3dGPU behandelt wird.

    Da ich diese Vorfilterung aber nur sehr dezent einsetzen möchte, habe ich mir mal folgenden Script (mit der Funktion SPresso) gebastelt.

    Mit den Einstellungen „RGmode=4, sigma=6.0, bw=16, bh=16, strength=0“ habe ich dann das Blumenbild noch mal entrauschen lassen. Das letzte der oberen Bilder wurde übrigens mit den Einstellungen „sigma=6.0, bw=16, bh=16, strength=0“ gemacht (ohne Vorfilterung). Ich finde, dass das Ergebnis noch mal besser geworden ist (den Hintergrund betreffend). ;)

    Klar - FFT zerlegt das Bild in Summen von Frequenzfunktionen, und filtert durch Abschwächen der höheren Frequenz-Komponenten. Eigentlich ist es auch nur eine DCT, keine echte Fourier-Transformation; nur ist die DCT bei JPEG/MPEG & Co. eben auf 8x8 begrenzt, beim FFT-Filter dagegen auf die Größenordnung der Bilddimensionen.

    Welchen Effekt die Abschwächung hoher Frequenzen bei der DCT hat, kann man leicht veranschaulichen. Wozu haben wir denn Quantisierungs-Matrix-Editoren. Bei FFT kommt es dabei nur eben nicht zu vielen kleien Blöcken, sondern zu einem großen. Aber Ring-Artefakte gibt es in beiden Fällen.

    Ursache: Gibbssches Phänomen (ringing)

    Nanu!? Offensichtlich ist meine letzte Nachricht aufgrund der Umstellung ins Nirwana verschwunden. :motz:

    Große Unterschiede in den Pixelwerten verursachen offensichtlich diese Art von „Schwingungen“. Man muss also nur dafür Sorge tragen, dass diese Unterschiede nicht so groß werden. Eine limitierte Anwendung von FFT3DFilter könnte hier Milderung verschaffen.

    Ich habe in der Zwischenzeit festgestellt, dass die bisher verwendete Methode Probleme beim Entfernen von Farbrauschen hat. Das hat jetzt aber nichts mit dem verwendeten Filter (FFT3DFilter) zu tun, sondern mit der Tatsache, dass die Farbkanäle aufgedröselt und getrennt – unter dem Etikett „Y-Kanal“ - verarbeitet werden. Das kann auch Nachteile mit sich bringen.

    Es muss doch eine Möglichkeit geben, den RGB-Farbraum so in einen YUV-Farbraum umzuwandeln, und sei es in einer anderen Struktur, ohne dass man einen Verlust von Chrominanzinformationen hinnehmen muss. Ein ConvertToYV24() wäre hilfreich, steht aber erst in der Version 2.6 zur Verfügung.

    Nach einiger Überlegung habe ich dann eine recht einfache Lösung gefunden. Im planaren YV12-Farbraum teilen sich doch 4 Pixel (Y-Pixel) die Farbinformationen. Diese Farbinformationen bestehen aus zwei Pixeln für die Werte U und V. Auf Bitmap-Ebene sind diese 4 Helligkeitspixel quadratisch, in einem 2x2 großen Fenster angeordnet.

    Normalerweise verliert man 75 % der Chrominanzinformationen, wenn man vom RGB-Farbraum in den YV12-Farbraum wandelt – normalerweise. ;) Was aber, wenn ich das Bild mit den RGB-Informationen vorher auf die doppelte Größe bringe, so dass ein und derselbe Pixel 4 mal vorkommt und ich anschließend erst die Farbraumkonvertierung nach YV12 vornehme? Mit PointResize() als „Pixelvervielfältiger“ dürfte das kein Problem sein. Nach der Farbraumumwandlung stehen alle Chrominanzinformationen des ursprünglichen Bildes zur Verfügung. Einzig der Luminanzkanal liegt in vierfacher Größe vor (das Bild ist doppelt so groß). Bei der Filterung des Luminanzkanals muss man nur dafür Sorge tragen, dass das Bild wieder in seiner ursprünglichen Größe vorliegt.

    Aussehen würde das in etwa so:

    Code
    ImageSource("$FileName", end=0, use_DevIL=False, pixel_type="RGB32")PointResize(last.Width * 2, last.Height * 2)ConvertToYV12(matrix="pc.601")# Filterlsf(strength_luma, strength_chroma)ConvertToRGB32(matrix="pc.601")PointResize(last.Width / 2, last.Height / 2)

    Ein Script zum Nachschärfen würde dann wie folgt aussehen:

    Code
    LoadPlugin("plugins\MaskTools 1.5.8\MaskTools.dll")LoadPlugin("plugins\MaskTools 2\mt_masktools.dll")LoadPlugin("plugins\RemoveGrain 1.0\RemoveGrain.dll")LoadPlugin("plugins\WarpSharp\warpsharp.dll")Import("lib\LimitedSharpen\LimitedSharpenFaster.avs")# ------------------strength_luma   = 0strength_chroma = 0# ------------------ImageSource("$FileName", end=0, use_DevIL=False, pixel_type="RGB32")PointResize(last.Width * 2, last.Height * 2)ConvertToYV12(matrix="pc.601")lsf(strength_luma, strength_chroma)ConvertToRGB32(matrix="pc.601")PointResize(last.Width / 2, last.Height / 2)$Clip = lastReturn $Clipfunction lsf(clip input, int strength_luma, int strength_chroma) {  luma = strength_luma == 0 ? input.YV12LUT(Y=2, U=0, V=0) : input.YV12LUT(Y=2, U=0, V=0).PointResize(input.Width / 2, input.Height / 2).\    LimitedSharpenFaster(      \ ss_x       = 1.0,      \ ss_y       = 1.0,      \ Smode      = 3,      \ strength   = strength_luma,      \ radius     = 2,      \ Lmode      = 1,      \ wide       = false,      \ overshoot  = 0,      \ undershoot = 0,      \ soft       = 0,      \ edgemode   = 0,      \ special    = false,      \ exborder   = 0    \ ).\    PointResize(input.Width, input.Height)  chroma = strength_chroma == 0 ? input.YV12LUT(Y=0, U=2, V=2) : input.YV12LUT(Y=0, U=2, V=2).\    LimitedSharpenFaster(      \ ss_x       = 1.0,      \ ss_y       = 1.0,      \ Smode      = 3,      \ strength   = strength_chroma,      \ radius     = 2,      \ Lmode      = 1,      \ wide       = false,      \ overshoot  = 0,      \ undershoot = 0,      \ soft       = 0,      \ edgemode   = 0,      \ special    = false,      \ exborder   = 0    \ )    MergeChroma(luma, chroma, 1)}

    Die einzigen Verluste, die man hinnehmen muss, sind Rundungsfehler bei den Farbraumumwandlungen.

    Und hier, das noch nicht ausgiebig getestete Script zum Entrauschen. Die wichtigsten Parameter habe ich der Übersichtlichkeit halber in einem Block zusammengefasst. Y-, U- und V-Kanal können einzeln entrauscht werden. Mit den Parametern limit_y, limit_u und limit_v kann bestimmt werden, um wieviel sich ein Pixel ändern darf. In den Standardeinstellungen wird nur der Y-Kanal entrauscht, eine Limitierung und Nachschärfung findet nicht statt.

    Das funktioniert wohl, hat aber einen gravierenden Nachteil: wenn Du es also so machst: (Kurzform)

    PointResize(x*2,y*2)
    lsf()
    PointResize(x,y)

    dann arbeitet die Schärfungsoperation nicht mehr korrekt. Der Schärfungseffekt-pro-Pixel wird dadurch asymmetrisch, weil pro Pixel nicht mehr alle originalen Nachbar-Pixel zur Verfügung stehen.

    original: 10-20-50

    => '20' wird geschärft gegen 30 [ (10+50)/2 ]

    => Pixel wird dunkler


    gedoppelt: 10-20-50 => 10-10-20-20-50-50

    => '20' wird geschärft gegen 15 [ (10+20)/2 ]

    => Pixel wird heller


    Ist nicht mehr das gleiche wie zuvor, oder? ;)

    Das dürfte sich insbesondere bei sanften Farbverläufen (Gradients) bemerkbar machen - Gefahr der Bildung von Ripples.


    Besser wäre:

    - LSF() auf originaler Auflösung, dann PointResize(x2), Chroma von Original.pointresize(x2) 'reinkopieren, zurück nach RGB, und wieder 'runterskalieren.

    Aus diesem Grunde lasse ich den Luminanz- und Chrominanzkanal doch getrennt nachschärfen.

    Es sei gegeben:
    ImageSource("$FileName", end=0, use_DevIL=False, pixel_type="RGB32")
    PointResize(last.Width * 2, last.Height * 2)
    input = ConvertToYV12(matrix="pc.601")

    Mit input.YV12LUT(Y=2, U=0, V=0).PointResize(input.Width / 2, input.Height / 2).LimitedSharpenFaster() erhält LimitedSharpenFaster doch die originalen Helligkeitspixel. Ebenso wie mit input.YV12LUT(Y=0, U=2, V=2).LimitedSharpenFaster() die originalen Chromapixel übergeben werden.

    Oder habe ich da was übersehen?

    Ooops. Hast recht, ist OK. Mein Fehler.

    Hab' nur gesehen, dass input*2*2 in lsf() 'reingeht ... nicht aber das Downsizing in der Funktion für Luma.

    So ist das, wenn man von einem Script nur 1/3 der Breite sieht ...

    Übrigens: LimitedSharpen/Faster arbeitet ausschließlich auf der Y-Ebene.

    YV12clip.LimitedSharpenFaster()

    macht null komma garnix mit den U/V-Ebenen des YV12 clips. Die Chroma-Abteilung in Deinem letzten Script ist somit ohne Effekt.

    Danke dir für den Hinweis. Wobei man bei LimitedSharpen(Faster) diese Klimmzüge ja eigentlich nicht zu machen braucht, da das Script auch mit RGBHack funktioniert. Irgendwie ist mir aber wohler, wenn ich einer Funktion bzw. einem Script den „richtigen Farbraum“ übergebe. ;)

    Mit den Parametern Y, U und V bei der verwendeten Funktion YV12LUT() hatte ich zunächst etwas Verständnisschwierigkeiten. Offensichtlich werden die Kanäle bei Werten größer als 2 einfach durchgelassen. Von 0 bis 1 werden die Kanäle gesperrt. Und bei Werten unterhalb von 0, nehmen die Pixel die entsprechenden Werte an.

    Zitat von Archimedes1

    Mit den Parametern Y, U und V bei der verwendeten Funktion YV12LUT() hatte ich zunächst etwas Verständnisschwierigkeiten. Offensichtlich werden die Kanäle bei Werten größer als 2 einfach durchgelassen. Von 0 bis 1 werden die Kanäle gesperrt. Und bei Werten unterhalb von 0, nehmen die Pixel die entsprechenden Werte an.


    Y|U|V = 3 : Ebene wird tatsächlich von [MaskTools-Filter] bearbeitet.
    Y|U|V = 2 : Ebene wird unbearbeitet zum Output durchgeschleift (bei Filtern mit mehreren Input-Clips: vom 1. Clip).
    Y|U|V = 4 : (bei Filtern mit mehreren Input-Clips) Ebene wird vom 2. Clip zum Output durchgeschleift.
    Y|U|V = 1 : Ebene wird garnicht verarbeitet, ihr Inhalt ist danach undefiniert. (Schnellste mögliche Methode.)
    Y|U|V = 0 ... -255 : alle Pixel der Ebene bekommen eben diesen Wert (abs()) zugewiesen.

    Zitat von Archimedes1


    Ich habe in der Zwischenzeit festgestellt, dass die bisher verwendete Methode Probleme beim Entfernen von Farbrauschen hat. Das hat jetzt aber nichts mit dem verwendeten Filter (FFT3DFilter) zu tun, sondern mit der Tatsache, dass die Farbkanäle aufgedröselt und getrennt – unter dem Etikett „Y-Kanal“ - verarbeitet werden. Das kann auch Nachteile mit sich bringen...


    Interessant! Also behandelt FFTDFilter die U/V Kanäle anders als den Y Kanal? Aber warum? Oder ist es nur die Tatsache dass die U/V Kanäle in YV12 eine geringere Auflösung haben und man dadurch die gleiche Denoising-Stärke auf eine kleine Fläche anwendet und somit ungewollt stärker filtert? Allerdings würde das mit dem 2x Upsize dann die gleichen Ergebnisse wie die RGB -> 3x YV12 Wandlung ergeben... Hmm, ich glaub ich schreib mal ne PM an Fizick!

    MfG~Soulhunter

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden