Beiträge von Archimedes1

    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?

    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.

    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). ;)

    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.

    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.

    Die Variante mit FFT3dGPU sähe dann wie folgt aus:


    Allerdings funktioniert FFT3dGPU auf keinem meiner Rechner. :motz:

    Auch die Kombination von FFT3DFilter und LimitedSharpenFaster (sofern benötigt) harmoniert recht gut. Die wichtigsten Parameter sind sigma und strength.

    Ich muss hier noch mal eine kleine Korrektur anbringen. ;)

    Die in der Dokumentation vorgeschlagenen Werte für bw und bh (bw=32, bh=32) sind beim FFT3DFilter dann doch zu viel des Guten – zu mindestens, wenn es um reine Bildbearbeitung geht. Sehr schön zu erkennen, an den Rändern der Blume im nachfolgenden Bild (100-%-Ausschnitt aus einer ISO-800-Aufnahme). Bessere (eigene) Motive liegen mir derzeit nicht vor. ;)

    FFT3DFilter: bw=32, bh=32, ow=16, oh=16
    [Blockierte Grafik: http://img510.imageshack.us/img510/2696/200707270002bwhb32owoh1ce2.jpg%20]

    Die ganz kleinen Werte für bw und bh, wie ich sie z. B. im obigen Script verwendet habe, sind allerdings auch nicht so der Bringer. Großflächige Bereiche werden dadurch nicht mehr so sauber entrauscht. Man richte sein Augenmerk einfach auf nur auf den Hintergrund im nachfolgenden Bild.

    FFT3DFilter: bw=4, bh=4, ow=2, oh=2
    [Blockierte Grafik: http://img341.imageshack.us/img341/3281/200707270002bwbh4owoh2pd9.jpg]

    Mit etwas höheren Werten sieht’s dann aber schon wieder besser aus, wie ich nun an mehreren Motiven herausgefunden habe. Bei bw=12, bh=12, ow=6, ow=6 wird’s dann aber auch schon wieder schlechter (im Vergleich zu FrFun7).

    FFT3DFilter: bw=8, bh=8, ow=4, ow=4
    [Blockierte Grafik: http://img518.imageshack.us/img518/5191/200707270002bwbh8owoh4kv6.jpg]

    Um so erstaunlicher, dass FrFun7 mit im Prinzip nur zwei einstellbaren Parametern – Tuv wird ja nicht benötigt – ein vergleichbares Ergebnis zustande bringt.

    Der Original-Ausschnitt der Blume sieht übrigens wie folgt aus.

    [Blockierte Grafik: http://img262.imageshack.us/img262/4708/200707270002vv5.jpg]

    Zur Demonstration wäre eine ISO-400-Aufnahme wohl besser gewesen. Ich bin da wohl etwas über das Ziel hinausgeschossen - so stark verrauscht sollte die Aufnahme dann doch nicht werden.

    Schließlich habe ich auch noch die zweidimensionalen Fähigkeiten des FFT3DFilter getestet, was zunächst gar nicht von Erfolg gekrönt war. Erst durch Abänderung einiger Parameter gelang es mir, ähnliche Resultate wie bei FrFun7 zu erzielen.

    Code
    LoadPlugin("plugins\FFT3DFilter\FFT3DFilter.dll")LoadPlugin("plugins\RGBHack\rgbhack.dll")Source = ImageSource("$FileName", end=0, use_DevIL=False, pixel_type="RGB24")R = Source.RGBtoY(0).fft3df()G = Source.RGBtoY(1).fft3df()B = Source.RGBtoY(2).fft3df()$Clip = YYYToRGB(B, G, R)Return $Clipfunction fft3df(clip input) {  input.FFT3DFilter(          \ sigma=7.0,          \ beta=1.0,          \ plane=0,          \ bw=4,          \ bh=4,          \ bt=1,          \ ow=2,          \ oh=2,          \ kratio=2.0,          \ sharpen=0.0,          \ scutoff=0.3,          \ svr=1.0,          \ smin=4.0,          \ smax=20.0,          \ measure=true,          \ interlaced=false,          \ wintype=2,          \ pframe=1,          \ px=0,          \ py=0,          \ pshow=false,          \ pcutoff=0.1,          \ pfactor=0,          \ sigma2=7.0,          \ sigma3=7.0,          \ sigma4=7.0,          \ degrid=1.0,          \ dehalo=0.0,          \ hr=2.0,          \ ht=50.0,          \ ncpu=1        \ )}

    Nachteil der Geschichte ist allerdings die langsame Verarbeitungsgeschwindigkeit. Größere bw- und bh-Werte erzeugten an Kanten (z. B. Handumrisse) Artefakte. Den sharpen-Parameter habe ich bewusst auf Null gesetzt (ein Nachschärfen hielt ich nicht für sinnvoll).

    Zitat

    I recommend to use the weighting window compensation with degrid=1 (since version 1.8), it improves the denoise quality and decreases the grid artifactes, especially for 2D.


    Die Variante mit wintype=0 erzeugt ebenfalls gute Resultate.

    Mit

    scheint auch eine brauchbare Entrauschlösung in Sicht zu sein.

    Original
    [Blockierte Grafik: http://img528.imageshack.us/img528/7509/img2116originaldl0.jpg]

    FrFun7 (siehe obiges Script)
    [Blockierte Grafik: http://img177.imageshack.us/img177/4421/img2116frfun7dx3.jpg]

    Ob zwischen

    Code
    ImageSource("$FileName", end=0, use_DevIL=False, pixel_type="RGB24")ConvertToYV12()$Clip = lsf().ConvertToRGB24()Return $Clip

    und

    ein Unterschied besteht, habe ich mir anhand eines Beispiels jetzt mal näher angeschaut. Habe hierzu ein 800x600 großes Bild mit beiden Varianten nachschärfen lassen. Mich interessierte also, ob die getrennte Verarbeitung der Farbkanäle (das getrennte Schärfen mit LimitedSharpenFaster) evtl. auch Nachteile mit sich bringt. Ich hatte da zunächst so meine Zweifel. ;)

    Nun, meine Zweifel sind ausgeräumt. Beide Bilder sehen selbst in der 200-%-Ansicht absolut identisch aus. Erst bei etwa 400 % kann man mikroskopische Unterschiede feststellen.

    Im Anhang zwei 100-%-Ausschnitte aus den erstellten Bildern. Beide Bilder im „unverfälschtem TIF-Format" - das Umwandeln in das JPG-Format mit maximaler Qualität brachte einfach zu viele Verluste mit sich. ;)

    Stimmt, aber dafür kommen im zweiten meiner Meinung nach die feinen Details besser raus!

    Kann natürlich mit veränderten LSF Einstellungen schon wieder anders aussehen...


    Die Unterschiede hier haben ihre Ursache vor allem in den unterschiedlich verwendeten Resize-Strategien. IrfanView geht hier anders zu Werke als AviSynth. Zugegeben, an dieser Stelle sieht das AviSynth-Ergebnis nicht so berauschend aus. An vielen anderen Stellen (z. B. Dachrinne, senkrechte Linien etc.) sehe ich dann wieder Vorteile für die AviSynth-Lösung.

    Sehe gerade, dass LimitedSharpenFaster die neueren MaskTools benötigt („mt_masktools.dll“). Habe die Vorlagen entsprechend abgeändert. Auch habe ich die benötigten Plugins gleich ins Template-Verzeichnis kopiert (Unterverzeichnis „plugins“). Es genügt nun eine einfache Standardinstallation von AviSynth.

    Beim Abspeichern in die Formate BMP, PNG, PPM, TGA und TIF bediene ich mich der AviSynth-Funktion ImageWriter. Der Farbraum kann dabei im RGB24- oder im RGB32-Format vorliegen.

    Nun habe ich festgestellt, dass beim TIF-Format der RGB32-Farbraum Probleme macht. Liegt ein Bild im RGB24-Farbraum vor, funktioniert alles einwandfrei. Aus diesem Grund lasse ich nun generell in den RGB24-Farbraum konvertieren, wenn TIF als Zielformat ausgewählt ist (einen vorhandenen Alphakanal mal außen vor lassend).

    Ebenso lasse ich beim JPG-Format nun generell in den RGB32-Farbraum konvertieren.

    Somit können die Bilder nun sowohl im RGB24- als auch im RGB32-Farbraum vorliegen. ;)

    Ob sich die Vorzüge von LimitedSharpen auch in einem „moderaten Schärfebereich“ zeigen? Dieser Frage bin ich jetzt mal nachgegangen.

    Dazu habe ich ein identisches Ausgangsbild, welches lediglich verkleinert worden ist, einmal mit IrfanView und einmal mit LimitedSharpenFaster nachschärfen lassen. Unter IrfanView kam wieder „High Pass Sharpening“ mit den moderaten Einstellungen „Range=3“, „Strength=192“ und „Overlay“ zum Einsatz.

    LimitedSharpenFaster erhielt die Parameter „strength=30“, „strength=40“ und „strength=50“. Selbst mit der Einstellung „strength=50“ waren im IrfanView-Bild noch mehr Artefakte zu erkennen. Zuerst dachte ich mir noch, dass die Unterschiede erst viel später, also bei höheren Schärfegraden, zutage treten.

    IrfanView - High Pass Sharpening (Range=3, Strength=192, Overlay)
    [Blockierte Grafik: http://img507.imageshack.us/img507/961/montblanc0640x0360irfanqc2.jpg]

    LimitedSharpenFaster (siehe obiges Script, aber mit strength=40)
    [Blockierte Grafik: http://img523.imageshack.us/img523/1648/montblanc0640x0360fritzvk8.jpg]

    Die Bilder wurden übrigens in der max. möglichen JPG-Qualität abgespeichert. Zugegeben, man muss schon etwas genauer hinsehen, um Unterschiede erkennen zu können. In der vergrößerten Darstellung sind die Vorzüge von LimitedSharpen aber gut zu erkennen.

    Keine Ahnung welches welches ist, aber mir gefällt das zweite besser...


    Das wäre dann das IrfanView-Bild. Gut, es gibt durchaus Stellen, die sehen damit besser aus, es gibt aber auch Stellen, wo die Script-Lösung eindeutig bessere Resultate liefert. Die Unterschiede resultieren aber vor allem aus den unterschiedlichen Verkleinerungsstrategien der verwendeten Programme. In beiden Fällen kam ja der Lanczos-Filter zum Einsatz. Womöglich gibt es auch Versionsunterschiede. Ein Vergleich der Schärfemethoden ist auf diese Weise sicher nicht möglich (darum ging es mir aber auch nicht). Man müsste ein bereits verkleinertes Bild mit beiden Programmen nachschärfen.

    Hab mich nur gefragt wozu es bei JPEG Quellen den überflüssigen 8bit Kanal braucht [Da ich noch nie JPEGs mit Alphakanal gesehen hab...]. Oder unterstützt Fritz Photo auch PNGs/BMPs usw. mit Transparenzkanal? =]


    Viele Grafikroutinen arbeiten intern - schon alleine aus Performancegründen - ausschließlich im 32-Bit-Modus. Ganz gleich, ob der zusätzliche Kanal benötigt wird oder nicht. Ich habe mich einfach auf den größten gemeinsamen Nenner geeinigt. Wobei im Programm selbst bis jetzt ja noch nicht sonderlich viel passiert: Das von AviSynth erzeugte Bild wird nur noch abgespeichert. Einzige Ausnahme: Das Finden der max. möglichen JPG-Qualität bei feststehender Dateigröße. Selbst wenn ich den RGB24-Support integrieren würde, würde ich intern doch wieder nach RGB32 wandeln (je nach Anwendungsfall).

    Das Schärfen ist ja sowieso ein Thema für sich, und eigentlich auch eine sehr individuelle Angelegenheit. Ich schärfe z. B. nur soweit nach, wie durch das Verkleinern an „Unschärfe“ hinzugekommen ist.

    Ich habe jetzt mal einen Vergleich gemacht. Und zwar habe ich ein Bild einmal mit IrfanView und einmal mit dem obigen Script von 3648x2736 auf 800x600 verkleinern und nachschärfen lassen.

    Zunächst habe ich das Bild mit IrfanView (unter Verwendung des Lanczos-Filters) verkleinern und anschließend mit dem Adobe-Plugin „High Pass Sharpening“ nachschärfen lassen. Als Einstellungen habe ich gewählt: „Range = 3“, „Strength = 220“ und „Overlay“. Das Bild habe ich anschließend mit 90-%-Qualität als JPG abgespeichert. Das entspricht in etwa meiner bisherigen Vorgehensweise.

    Nun galt es, mit obigen Script, eine gleich große Datei zu erzeugen. Dies habe ich dadurch erreicht, dass ich den Wert von „strength“ solange nach unten korrigiert habe, bis die Dateigrößen weitestgehend identisch waren. Die JPG-Qualität war ebenfalls auf 90 % eingestellt. Dabei ist für „strength“ ein Wert von 30 herausgekommen. Beim Vergleichen der Bilder empfand ich das „Schärfe-Niveau“ in etwa gleich. Das IrfanView-Bild schien mir aber mehr Artefakte zu haben.

    Ich habe dann auch noch höhere Werte für „strength“ getestet. „strength=50“ erzeugte mir dann schon zuviel an „Schärfe“. „strength=40“ scheint mir ein brauchbarer „Universalwert“ zu sein, wenn es um die Verarbeitung vieler Bilder geht – zu mindestens nach meinem Schärfeverständnis. ;)

    Ach ja, als Anhang seien die beiden Bilder noch nachgereicht.

    Warum benötigt Fritz Photo RGB32? Vor allem für JPEG Ausgabe... :\


    Die interne Verarbeitung findet eben im RGB32-Farbraum statt. Eine Unterstützung für den RGB24-Farbraum wäre zwar machbar, aber wozu? Wo mir AviSynth doch den korrekten Farbraum übermitteln kann.

    Bleibt die Frage, ob man LimitedSharpenFaster nicht auch das Resizen überlassen sollte?
    R-, G- und B-Kanal würden dann getrennt resized werden...

    Shit! Ich hätte vorher sagen sollen das LSF + Soothe bei Bildern nicht funktioniert. Ich wusste das noch nicht als ich das Skript gepostet hatte, aber Didée hat das hier letztens erwähnt.


    Ein „einfaches Script“ zum Verkleinern und Nachschärfen könnte dann in etwa so aussehen:

    Ich habe mir nun die aktuellste AviSynth-Version installiert, LimitedSharpen aus der genannten Scriptsammlung verwendet und die drei benötigten Plugins (MaskTools, RemoveGrain und WarpSharp) installiert.

    Zunächst habe ich einen Versuch ohne LimitedSharpen gemacht. Dabei habe ich festgestellt, dass die Funktion RGBtoY() den RGB24-Farbraum benötigt. Bei der Ausgabe nach JPG wird intern (innerhalb von Fritz Photo) aber ein RGB32-Farbraum erwartet, so dass man zum Schluss noch ein ConvertToRGB32() hinzufügen muss. Fritz Photo sollte also immer mit dem RGB32-Farbraum gefüttert werden. Mit dem folgenden Script hat es dann mit LimitedSharpen geklappt.

    Code
    LoadPlugin("C:\Programme\AviSynth 2.5\plugins\RemoveGrain\RemoveGrain.dll")LoadPlugin("C:\Programme\AviSynth 2.5\plugins\MaskTools.dll")LoadPlugin("C:\Programme\AviSynth 2.5\plugins\warpsharp.dll")LoadPlugin("C:\Programme\AviSynth 2.5\plugins\rgbhack.dll")Import("lib\LimitedSharpen.avs")ImageSource("$FileName", end=0, use_DevIL=False, pixel_type="RGB24")Source = LanczosResize($Width, $Height)R = Source.RGBtoY(0).LimitedSharpen()G = Source.RGBtoY(1).LimitedSharpen()B = Source.RGBtoY(2).LimitedSharpen()$Clip = YYYToRGB(B, G, R).ConvertToRGB32()Return $Clip

    Und hier die Version mit LimitedSharpenFaster und Soothe:

    Also, irgendwie bekomme ich LimitedSharpenFaster hier nicht zum Laufen. Ständig kommt die Fehlermeldung:

    Zitat

    Script error: there is no function named „m“
    (lib/LimitedSharpenFaster.avs, line 52)

    LimitedSharpenBeta hingegen scheint zu funktionieren. Werde damit mal ein paar Tests machen.