AviSynth - geeignet für Bildbearbeitung?

  • 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:

  • 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.

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

    Zitat

    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.

    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? =]

    MfG~Soulhunter

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

  • @ EC'03:

    Nicht die JPEG-Ausgabe braucht RGB32, sondern die Filterei -- und wenn bloß aus Performance-Gründen (4 Bytes = 32 bit = 1 LONGWORD läßt sich im Prozessor bzw. als Hauptspeicheradresse oft leichter verwalten als 3 Bytes = 3*8 Bit als einzelne Bytes).

    Die JPEG-Ausgabe nimmt sich die darin enthaltenen RGB24 aus den RGB32.

  • 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.

  • Mir gefallen die LSF-bilder wesentlich besser.

    Man beachte bei dem infranVief(IV) Bild mit der Burg nur mal die "Regenrinne" (keine ahnung wie man das bei einer Burg nennt :lol: )

    Bei IV zeigen sich extreme Artefakte; bei LSF ist der Verlauf völlig gleichmässig.

    Die lsf-Bilder Sehen alle wessentlich besser und angenemer aus IMHO.

    Super Arbeit, Archimedes1! :daumen:

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

  • 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.

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


    Jein, nicht wirklich. Der Witz an LS/F ist ja gerade, dass die Signalamplitude *nicht* verstärkt wird, sondern nur die Kantensteilheit. Mit LS/F ginge das also nur, indem man 'overshoot' erhöht -> birgt dann aber wieder die Gefahr, Halos zu produzieren.

    Das wäre dann eher die Domäne von SeeSaw. Das arbeitet ja zunächst mal ganz ähnlich wie LS/F, nur dass das begrenzen-der-Schärfung auf eine Weise durchgeführt wird, die eine Verstärkung der Signalamplitude ermöglicht.

  • 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.

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

  • 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]

  • 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.

  • 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.

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

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


    Allerdings funktioniert FFT3dGPU auf keinem meiner Rechner. :motz:

Jetzt mitmachen!

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