AviSynth - geeignet für Bildbearbeitung?

Das hatten wir doch schon mit RGBHack diskutiert. Das Umetikettieren des R-, G- und B-Kanals als Y-Kanal führt nicht zwangsläufig zum gewünschten Ergebnis. Wenn ich zum Beispiel FFT3DFilter nacheinander den R-, G- und B-Kanal als Y-Kanal serviere, so wird vorhandenes Farbrauschen nicht bzw. nur ungenügend entfernt.

Zur Kontrolle habe ich das auch noch mal mit TNLMeans getestet. Ergebnis: Auch hier wird evtl. vorhandenes Farbrauschen nicht bzw. nur unzureichend entfernt.

Source = last
R = Source.ShowRed("YV12").TNLMeans()
G = Source.ShowGreen("YV12").TNLMeans()
B = Source.ShowBlue("YV12").TNLMeans()
MergeARGB(Source, R, G, B)

P.S.: Eigenartigerweise funktioniert bei mir MergeRGB nicht, dafür aber MergeARGB.

Ich habe mal meinen aktuellen Stand hochgeladen. Es gab nicht all zu viele Änderungen. In den Scripts zum Verkleinern habe ich den Parameter "GammaCorrection" hinzugefügt. Die Ergebnisse sehen damit zwar schon sehr gut aus, aber dennoch ist der Parameter eher als Experiment zu verstehen.

Zum Entrauschen verwende ich mittlerweile die Kombination TNLMeans und FFT3DFilter. Für TNLMeans ist ebenfalls ein Script vorhanden.

Nachdem Immaavs – ein auf ImageMagick basierendes Plugin – wieder weiterentwickelt wird, habe ich im Plugin-Verzeichnis die alte Version gegen die neue Version getauscht.

Damit ist auch die Möglichkeit gegeben, das JPEG-2000-Format zu erzeugen.

Zitat

Es gibt teilweise qualitative Unterschiede bei den verschiedenen Encodern, die sich vor allem bei höheren Kompressionsraten bemerkbar machen. Die einfachste, kostenlose Möglichkeit dürfte derzeit ImageMagick, GraphicsMagick oder ExactImage bieten, die auf der JasPer-Library beruhen. Unterstützt wird allerdings nur einfache Komprimierung. Quelle: http://de.wikipedia.org/wiki/JPEG_2000

Wenn ich das richtig sehe, erfährt der Chromakanal in SeeSaw nur dann eine Änderung, wenn NRlimit <> 0 ist. Wie auch immer, den Chromakanal müsste ich so oder so extra behandeln, wenn ich SeeSaw für das Programm hier verwenden will. Ist SeeSaw für einzelne Bilder überhaupt sinnvoll einsetzbar?

Ausgehend von diesem Thema bin ich nämlich gerade am Experimentieren, da ich ein extrem verrauschtes Bild vorliegen habe, dass zudem Verblockungen und Kompressionsartefakte aufweist (das Bild hat nur eine JPG-Qualität von etwa 50 %). Eine Paradesdisziplin für TNLMeans also! Das Entrauschen, Entblocken und Entfernen der Kompressionsartefakte gelingt damit auch wunderbar. Da das Bild aber auch noch sehr unscharf ist, müsste es auch noch nachgeschärft werden. Das wiederum sieht im Nachhinein nicht so besonders aus (weswegen ich in aller Regel nach dem Entrauschen auch darauf verzichte). Deswegen die Idee, SeeSaw dafür zu verwenden. Die Kombination von Entrauschen und Nachschärfen ist doch die Domäne von SeeSaw?

Der Funktionsaufruf für SeeSaw würde in etwa wie folgt aussehen:

function ff_seesaw(clip input1, clip input2, float ssx, float ssy, int NRlimit, int NRlimit2, float Sstr, int Slimit, float Spower, float Szp, float SdampLo, float SdampHi, float bias, int sootheS) {
  Source = (Sstr == 0) ? input1 : SeeSaw(
      \ input1.PointResize(input1.Width / 2, input1.Height / 2),
      \ input2.PointResize(input2.Width / 2, input2.Height / 2),
      \ ssx      = ssx,
      \ ssy      = ssy,
      \ NRlimit  = NRlimit,
      \ NRlimit2 = NRlimit2,
      \ Sstr     = Sstr,
      \ Slimit   = Slimit,
      \ Spower   = Spower,
      \ Szp      = Szp,
      \ SdampLo  = SdampLo,
      \ SdampHi  = SdampHi,
      \ bias     = bias,
      \ Smode    = ssx < 1.35 ? 11 : ssx < 1.51 ? 20 : 19,
      \ sootheT  = 0,
      \ sootheS  = sootheS
    \ ).\
    PointResize(input1.Width, input1.Height).MergeChroma(input1, 1)


  NRdiff = yv12lutxy(input1, input2, uexpr="x y - 128 +", vexpr="x y - 128 +", Y=1, U=3, V=3)
  NRL = string(NRlimit)
  Denoised = (NRlimit==0) ? input1 : yv12lutxy(input1, NRdiff, uexpr="y 128 " + NRL + " + > x " + NRL + " - y 128 " + NRL + " - < x " + NRL + " + x y 128 - - ? ?", vexpr="y 128 " + NRL + " + > x " + NRL + " - y 128 "+ NRL +" - < x " + NRL + " + x y 128 - - ? ?", Y=1, U=3, V=3)
  Source.MergeChroma(Denoised, 1)
}

Nach dem eigentlichen Aufruf von SeeSaw (die Clips müssen wieder halbiert zugeführt werden), liegt der Chromakanal unverändert vor. Anschließend erfolgt dann die Behandlung des Chromakanals.

Kann ich machen. Das Ganze ist halt noch etwas quelltextlastig. Eine mehr oder weniger detaillierte Beschreibung findet man so oder so im entsprechenden Plugin- bzw. Script-Verzeichnis. Bei einigen Vorlagen kommt man um ein Lesen der Dokumentation des entsprechenden Plugins bzw. Scripts ohnehin nicht herum.

Noch ein kleiner Nachtrag zu den Entrauschmethoden.

Die Ergebnisse mit FFT3DFilter sind ja an und für sich nicht so schlecht. Gestört hat mich allerdings immer diese Artefaktproblematik, die ich nie hundertprozentig in den Griff bekam. Auch scheint FFT3DFilter recht speicherhungrig zu sein. Bei größeren Bildern erhalte ich regelmäßig Fehlermeldungen (Abstürze).

Nicht nur, dass TNLMeans hier wesentlich genügsamer ist, es produziert auch die eindeutig besten Ergebnisse unter den bisher getesteten Entrauschmethoden. Mit TNLMeans erhalte ich keine Artefakte und die Methode erhält auch die meisten Details.

In einem Differenzbild zwischen dem Original und der entrauschten Version kann man sehr gut sehen, was eigentlich vom Original entnommen wurde. Im Idealfall sieht man in so einem Differenzbild nur Rauschen und möglichst wenig Details. In dieser Disziplin schneidet TNLMeans, nachzulesen in den wissenschaftlichen Papieren, unter den herkömmlichen Entrauschmethoden am besten ab. Da man Rauschen aber nie gänzlich eliminieren kann, ist ein weiteres Kriterium für die Beurteilung von Entrauschmethoden sehr wichtig, nämlich, dass eine Methode aus Rauschen (im Idealfall) wieder nur Rauschen erzeugt ("Rauschen-zu-Rauschen-Prinzip"). Das klingt etwas widersprüchlich. Ist es aber nicht. Es geht hier nämlich um die Artefaktfreiheit. Und auch hier schneidet TNLMeans wieder mit am besten ab.

Bei größeren Bildern entrausche ich zunächst nur einen kleinen aussagekräftigen Ausschnitt (z. B. 600x400). Ausgehend von den Parametern Ax=Ay=10, Sx=Sy=3, Bx=By=1, ermittle ich zunächst geeignete Werte für h_y, h_u und h_v (Stärke der Filterung für die einzelnen Farbkanäle). Sind diese gefunden, so wende ich sie für das ganze Bild an. Um das letzte Quentchen an Details herauszuholen, setze ich Bx=By=0. Allerdings müssen dann für h_y, h_u und h_v etwas größere Werte verwendet werden. Einziger Nachteil der Geschichte: Das Filtern dauert dann um einiges länger! Aber was ist schon Zeit?

Brot + Zeit = Brotzeit :lol:

Hierzu müsste man anhand mehrerer Bilder einen Vergleichstest machen. Ich selbst habe NeatImage nicht auf meinem Rechner. Ich hatte aber schon oft die Möglichkeit, mich an ein mit NeatImage entrauschtes Bild heranzutasten. Das Original wurde dabei mit TNLMeans in etwa um das gleiche Maß entrauscht. Nach meinem persönlichen Eindruck hatte TNLMeans stets die Nase vorn. Irgendwo muss sich die lange Berechnungszeit ja lohnen. :lol: Allerdings wusste ich nicht immer, welche Einstellungen in NeatImage verwendet wurden.

Zitat von sidewinder711

Verbesserungsvorschlag/Frage:
Lässt es sich einrichten, dass die vorgenommen Einstellungen für Höhe, Breite, Qualität und insb. der Speicherpfad beim nächsten Start von FritzPhoto automatisch eingestellt bleiben/wieder geladen werden ?

Wenn du andere Einstellungen beim Start des Programms benötigst, brauchst du nur die INI-Datei zu ändern.

Zitat von sidewinder711

Zudem habe ich versucht, einige der Rauschfilter anzuwenden, insb. auch welche genommen, die noch nicht bei Deinen Templates dabei sind. Zum einen gab es Probleme mit TNLMeans&FFT3d (kein Abspeichern und Programmabstürze), zum anderen hatte ich Probleme mit den Farbräumen bei Hinzuziehung anderer Avisynth-Filter.

Mit FFT3DFilter habe ich bei größeren Bildern auch regelmäßig Abstürze (reproduzierbar).

Bei Verwendung von anderen AviSynth-Filtern, die nicht als Vorlage enthalten sind, muss die Farbraumproblematik beachtet werden! Wenn der Filter im YV12-Farbraum arbeitet, kann man es sich einfach machen, und am Anfang der Verarbeitungskette einfach ein ConvertToYV12(matrix="pc.601") setzen. Auf diese Weise verliert man allerdings Chrominanzinformationen. Zu beachten wäre außerdem, dass die Vorlagen dann nicht mehr funktionieren (liegt ein Bild im YV12-Farbraum vor, gehen die Vorlagen davon aus, dass das Bild in doppelter Größe vorliegt). Am Ende der Verarbeitungskette muss dann zwingend ein ConvertToRGB32(matrix="pc.601") stehen. Zu mindesten lassen sich auf diese Weise – unter dem Verlust von Chrominanzinformationen - schnell andere Filter testen.

Was man halt vermeiden sollte, sind unnötige RGB-YV12-RGB-Wandlungen, die ja nicht ganz frei von Verlusten sind. Die Vorlagen benötigen entweder den RGB- oder den YV12-Farbraum. Je nachdem, welche Vorlagen zum Einsatz kommen, sind Farbraumumwandlungen angesagt. Bis zu zwei, drei solcher Umwandlungen bereiten in der Regel aber keine Probleme. Sichtbar werden die Verluste erst ab der 3. Umwandlung (motivabhängig). Mehr Umwandlungen sind in der Regel aber auch nicht nötig. Beim Verkleinern (RGB-Farbraum) und Nachschärfen (YV12-Farbraum) wird z. B. nur 1 Umwandlung benötigt.

Anbei ein Beispiel. Das 1. Bild ist das Original. In den anderen Bildern ist in den Dateinamen und in den Bildern die Anzahl der Farbraumumwandlungen zu ersehen.

Bei größeren Berechnungen mache ich in der Regel ein Häkchen bei "Niedrige Prozesspriorität".

Kannst du mal ein Beispielbild hochladen?

Ich habe den betreffenden Bereich (ganz unten) mal mit Ylevels bearbeitet und mit Overlay und einer geeigneten Maske, einem Grauverlaufsbild (siehe 1. Bild im Anhang), wieder dem Original hinzugefügt.

Die von mir verwendete Maske, das Graustufenbild, ist auch nur eine erste Annäherung an das Problem: In einem begrenzten Bereich wird das Bild nach unten immer heller. Wenn man ganz genau hinsieht, stellt man fest, dass das Bild im linken unteren Bereich noch in Ordnung ist und eigentlich keiner Behandlung bedarf. Man könnte jetzt natürlich hergehen, und eine optimierte Maske erstellen.

Bei der Bearbeitung des betreffenden Bereichs habe ich mich allerdings nur auf einen 256 Pixel breiten Rand von unten konzentriert. Wenn ich den zu bearbeitenden Bereich auf 384 Pixel vergrößere, sieht das Ergebnis etwas anders aus (siehe Bild im Anhang). Den Bereich habe ich diesmal mit YlevelsG und mit einem Gamma von nur 0,2 bearbeitet.

Sei clip1 das Originalbild, clip2 der mit YlevelsG bearbeitete Bereich und mask das Graustufenbild (das ich natürlich entsprechend vergrößert habe). Dann ergibt Overlay(clip1, clip2, 0, 1274, mask) das Bild, das im Anhang zu sehen ist.

Passend zum Bild: Viele Wege führen nach Rom.