AviSynth - geeignet für Bildbearbeitung?

Zitat von sidewinder711

Soweit so gut. Was mir immer nur mit Probieren gelingt, ist die Heranziehung des richtigen Farbraumes. Gibt es eigentlich ein Script, welches automatisch den richtigen Farbraum und die erforderliche mod-Grösse, je nach Filter, auswählt ?

Wenn man die Vorlagen verwendet, muss man sich diesbezüglich keine Gedanken machen. Eine Farbraumumwandlung und Größenanpassung findet nur statt, wenn sie auch wirklich benötigt wird.

Problematisch kann es eigentlich nur dann werden, wenn man außerhalb der Vorlagen einen Filter einsetzt, der nicht im RGB-Farbraum, sondern im YV12-Farbraum arbeitet. Ein YV12-Bild wird innerhalb des Programms immer in der doppelten Größe angenommen (die Vorlagen sind darauf abgestimmt). Ein YV12-Filter muss somit immer speziell gefüttert werden (Halbierung des Helligkeitskanals, getrennte Verarbeitung des Farbkanals etc.). Nach der Filteranwendung muss das Bild dann wieder auf die doppelte Größe gebracht werden. Anschließend muss der (bearbeitete) Farbkanal wieder zugeführt werden. Das packt man am besten in eine Funktion.

Beispiel:

function ff_Ylevels(clip input, int input_low, float gamma, int input_high, int output_low, int output_high) {  input.PointResize(input.Width / 2, input.Height / 2).Ylevels(input_low, gamma, input_high, output_low, output_high).PointResize(input.Width, input.Height).MergeChroma(input, 1)}

Nun will man sicherlich nicht für jeden neu zu testenden YV12-Filter gleich eine passende Funktion bzw. Vorlage schreiben. Den Verlust von Chrominanzinformationen in Kauf nehmend, kann man sich auch wie folgt behelfen (wichtig sind die Zeilen vor und nach der Filteranwendung):

Import("lib\FritzPhoto\FritzPhoto.avs")


isYV12() ? YV12toRGB().ConvertToYV12(matrix="pc.601") : ConvertToYV12(matrix="pc.601")
# YV12-Filter 1
# YV12-Filter 2
ConvertToRGB32(matrix="pc.601")

Auf diese Weise kollidiert man nicht mit den bestehenden Vorlagen.

Zitat von katjarella

1: YV12toRGB() ist doch eigentlich YV12toRGB32(), also mit Alphamaske. Ich hatte einmal das "Problem" das div. Programme das PNG mit Alphakanal nicht lesen wollten oder besser gesagt Falsch darstellten.

Falls das RGB32-Format Probleme macht, braucht man nur das entsprechende Script – hier ImageWriterPNG – abzuändern.

Zitat von katjarella

2: wenn ich die Zielauflösung 640x480 einstelle, warum kommt überall nur 600x480 raus? Quell ist 720x576

Liegt ein Bild mit einer Auflösung von 720x576 vor, so entspricht das einem Seitenverhältnis von 45:36. Und genau dieses Seitenverhältnis wird wieder erzeugt. Das Bild ist dabei immer kleiner, gleich der angegebenen Zielauflösung. Für Vergrößerungen müsste man die Resize-Scripts entsprechend anpassen.

Zitat von katjarella

3: noch ne techn. Frage: gibts eine Möglichkeit, diese Verabeitungslog zu sehen, bei mir geht das zu schnell auf die letzte Seite und da steht ja dann nix.

Was meinst du mit Verarbeitungslog? Auf der letzten Seite werden eigentlich nur die momentan bearbeiteten Bilder angezeigt - mehr auch nicht.

Wenn kein Resize-Script zum Einsatz kommt, ändert sich auch die Auflösung nicht.

Da die ganze Logik bewusst in den Scripts enthalten ist (am Anfang hatte ich die Berechnung des richtigen Seitenverhältnisses noch im Programm gelöst), bietet sich ein entsprechender Schalter in den Resize-Scripts an. Werde die Resize-Scripts daraufhin mal abändern. Im Programm bietet sich dann natürlich auch ein entsprechender Schalter an. Ansonsten ist das Programm "dumm wie Stroh" (was aber nicht so bleiben muss) - es reicht die Parameter nur weiter (durch Suchen und Ersetzen von Schlüsselwörtern).

Hat schon jemand Erfahrungen mit dem Script "Super Slow Sharpen" gesammelt? Beim folgenden Bild, welches mit Spline36Resize von 3367x2525 auf 1200x899 verkleinert wurde, habe ich mal ganz bewusst die Default-Einstellungen nur "geringfügig" geändert, um den Effekt zu zeigen.

Original
[Blockierte Grafik: http://www.bildercache.de/thumbnail/20081121-022756-987.jpg]

SSSharp(rad=0.25, ssw=true, strength=2.2, iter=1, ss=true, denoise=1)
[Blockierte Grafik: http://www.bildercache.de/thumbnail/20081122-122156-561.jpg]

Habe die Vorlagen mal wieder aktualisiert. Bei den Resize-Scripts gibt es nun auch die boolsche Eigenschaft "KeepAspectRatio". Neu hinzugekommen sind u. a. die Scripts "LimitedSharpenFasterMod" und "SuperSlowSharpen". Als nicht ganz unnütz könnte sich das Script "Grid" erweisen, das ein Koordinatensystem in ein Bild einzeichnet.

[Blockierte Grafik: http://img227.imageshack.us/img227/3773/sn8503800640x0480gp8.jpg]

Hab' mal wieder ein kleines Update hochgeladen.

Unter Einstellungen sind die Schalter "Seitenverhältnis beibehalten" und "Pixelmaße exakt einhalten" hinzugekommen. Da ich das Programm hauptsächlich zum Verkleinern und Nachschärfen verwende, habe ich LimitedSharpenFaster nun ebenfalls in den Einstellungen integriert (siehe Anlage). Für's Verkleinern und Nachschärfen muss man nun nicht mehr in den jeweiligen Scripts herumhantieren. Häufig benutzte Scripts können in der INI-Datei unter "Job List" hinzugefügt werden. Beim Starten des Programms wird die Jobliste dann mit diesen Scripts gefüllt. Ich habe hier mal das Script "FritzPhotoResize" eingetragen.

Das soll aber auch nur eine Zwischenlösung sein. Der Benutzer sollte generell die Möglichkeit haben, entweder in den Scripts selber zu hantieren oder die Parameter mit Hilfe eines "Objektinspektors" bzw. "Scriptinspektors" zu bearbeiten.

Eigenartig, wenn ich im Zusammenhang mit Supersampling die Parameter dest_x und dest_y innerhalb von LimitedSharpenFaster verwende, dann hat das Script so gut wie keine Wirkung mehr.

Zwischen der Ausgabe von (siehe 1. Bild im Anhang):

Zitat

ConvertToYV12()
LanczosResize(640, 480)
ConvertToRGB()

und (siehe 2. Bild im Anhang):

Zitat

ConvertToYV12()
LimitedSharpenFaster(Strength=80, dest_x=640, dest_y=480)
ConvertToRGB()

besteht fast kein Unterschied. Kann mir das jemand erklären?

Dagegen bewirkt die vorherige Verkleinerung den (für mich) erwarteten Effekt (siehe 3. Bild im Anhang):

Zitat

ConvertToYV12()
LanczosResize(640, 480)
LimitedSharpenFaster(Strength=80)
ConvertToRGB()

Eigentlich will ich ja Mehrfach-Resizing (bei Verwendung von Supersampling) verhindern.

Das Originalbild ist 2048x1536 groß.

Danke dir! Supersampling macht hier also nur in einem begrenzten Skalierungsbereich wirklich Sinn.

Die Sache ist nämlich die, im Script "FritzPhotoResize" verkleinere ich die Bilder zunächst immer auf die gewünschte Zielgröße. Anschließend wird LimitedSharpenFaster darauf angewendet. Wenn nun Supersampling zum Einsatz kommt, dann wird das betreffende Bild ja wieder hochskaliert. Vereinfacht sieht das so aus:

LanczosResize(640, 480)LimitedSharpenFaster()

Demnach müsste die folgende Variante doch besser sein?

LanczosResize(Round(640 * 1.5), Round(480 * 1.5))
LimitedSharpenFaster(ss_x=1.0, ss_y=1.0, dest_x=640, dest_y=480)

In meinem Fall - ohne einer Änderung in LSF - würde ich dafür sorgen, dass LSF mit einer Eingangsgröße von (dest_x x ss_x) x (dest_y x ss_y) und mit ss_x=ss_y=1 angesteuert wird. Werde die Scripte mal daraufhin abändern.