Aikousha wrote:Doch für jede RAW arbeite ich mich von meinem Standard zum Optimum hin. Doch um dieses Optimum zu erreichen, ist erstens einiges an "Vorbildung" nötig und zweitens Erfahrung.
Du bist eben auch Encoder. Ich bin Übersetzer und will mit geringem Aufwand Releases bauen, bei denen die Leecher nicht die Hände über dem Kopf zusammenschlagen (wenn ich da an gewisse GerDub-Rips denke, die noch nicht mal ansatzweise deinterlaced sind... sowas stört dann sogar mich, weil die einerseits schon unkomprimiert grausig aussehen und andererseits auch noch fürchterlich schlecht komprimierbar sein müssen, also beim MP4-Encoden auf feste Dateigröße zusätzlich nochmal einiges an Qualität verlieren werden).
Gleichzeitig glaube ich fest an die Effizienz des Einsatzes guter, simpler Werkzeuge (etwa der tfm()/tdecimate()-Kombo aus TIVTC oder auch der WinWord-Rechtschreibkontrolle für Fansubs, die bei mir vor jedem Release in jeder Episode im Schnitt noch einen Tippfehler findet, den ich selbst auch in fünf QC-Durchgängen noch übersehen habe, und das in nur wenigen Minuten Arbeit).
Und ehrlich gesagt reizt mich das, was ich hier gerade treibe (ein richtiger wissenschaftlicher "Test" ist es ja nicht - ich betrachte es eher als "Wirtschaftsspiel"), deutlich mehr, als ein Video stundenlang anzusehen in der Hoffnung, eine Aussage über dessen Videoqualität machen zu können... denn immerhin lerne ich hier wenigstens schon mal, diverse Filter grundsätzlich einschätzen zu lernen (wenngleich eher aus Usability-Blickwinkeln, aber eben auch Aspekte wie 2D/3D, temporaler Radius usw.).
Bisher habe ich "gelernt", dass RemoveGrain(2) angesichts dessen, was 3D-Filter können, zu "kurz gesprungen" war - FFT3Dfilter liefert mit benutzerfreundlichen Defaultwerten in nur einer Stunde Laufzeit pro Episode etwas, was bei gleichem SSIM mindestens 5% Dateigröße zusätzlich einspart. Auch habe ich "gelernt", dass der SSIM-Wert während des Encodens bei einem 3D-gefilterten Video anscheinend weniger stark abfällt als bei einem 2D-gefilterten (ich vermute, weil XviD bei seiner Frames-Delta-Speicherung von der temporalen Filterung profitiert?).
Mein nächstes Ziel ist es, herauszufinden, ob ein solcher 5%-Schritt durch Erhöhung auf, sagen wir mal, 5-10 Stunden Filterzeit nochmal möglich ist - dass ein 3D-Filter mit "temporalem Radius 2" (d. h. 5 Frames) fünfmal so lange braucht wie ein 2D-Filter, ist ja irgendwie naheliegend, aber anscheinend bewirken auch noch andere Schrauben bei den komplizierteren Filtern etwas in Sachen Laufzeit, etwa unterschiedlich komplexe Suchfunktionen bei der Bewegungsanalyse von MVDegrain.
Mehrere
Tage am Stück einen Filter über eine einzige Episode laufen zu lassen halte ich dann irgendwie doch nicht mehr für wirtschaftlich - nicht zuletzt, weil ich ja gar nicht mehr objektiv feststellen kann, ob dadurch irgendwas qualitativ besser wird (denn dazu müsste ich ja mehrere solcher Läufe nacheinander durchführen und die Ergebnisse miteinander vergleichen).
Aikousha wrote:Erstmal danke, dass du dir die Mühe machst, einen eigenen Test durchzuführen.
Ich empfinde es nicht als Mühe, sondern als meinen Teil eines gemeinsamen Workshops, der es für Encoder wie Dich lukrativ machen soll, Kommentare in diesem Thread zu schreiben, durch die alle Leser (nicht zuletzt ich selbst) etwas lernen können (und sei es nur, was man beim Aufbau von Testbedingungen alles falsch machen kann...). Das ist meine Variante von "es wird ausgebildet" (meine Fansubwiki-Artikel gehören auch dazu). Deine Kommentare motivieren mich beispielsweise, die ReadMe-Dateien zu lesen, was ich bisher nur eher sporadisch versucht habe (weil mir Grundlagenwissen fehlt).
Aikousha wrote:Persönlich würde ich einen Denoiser danach beurteilen (rein objektiv), wieviel SSIM dieser erhält, im Gegensatz zur Einstparung in der Dateigröße.
Ich bin nicht sicher, ob ich diesen Satz verstanden habe. Meintest Du "Verhältnis" statt "Gegensatz"?
Wieviel SSIM in einem konkreten Fall erhalten wird, das liegt doch nicht am Denoiser, sondern an dessen Einstellungen (etwa dem "sigma" von FFT3Dfilter). Aber wenn "RemoveGrain(2)" bei einem Verlust von 1.17% SSIM nach XviD-Komprimierung (also
relativ zum ungefilterten XviD-Encoding, nur das ist ja letzten Endes der Netto-Filtereffekt) zwar 5.45% Dateigröße einspart, "FFT3Dfilter(sigma=2.0)" bei einem Verlust von nur 0.97% SSIM aber 10.28%, dann habe ich einen zählbaren Gewinn
zumindest ohne Qualitätsverlust erzielt, nämlich 5% Dateigröße. (Vorausgesetzt, ich vertraue SSIM als "Augenersatz".) Zudem sehe ich an meiner Tabelle, dass "FFT3Dfilter(sigma=2.2)" sehr wahrscheinlich denselben SSIM-Wert wie "RemoveGrain(2)" liefern und dabei noch eine Idee mehr einsparen würde (weil ich dabei ja noch 0.2% SSIM "investieren" kann).
Deshalb sortiere ich meine Testergebnisse zwar nach SSIM, aber eigentlich interessant finde ich
dann diejenigen Zeilen, bei denen eine relativ hohe Einsparung gegenüber ihren Tabellennachbarn (also bei "gleicher Qualität") herauskommt - diese Werte habe ich dann auch fett hervorgehoben (inzwischen von diesen wiederum solche, bei denen eine vergleichsweise kurze Laufzeit zu den entsprechenden Ergebnissen führt - das hat z. B. "dcttest()" bisher eine "Belobigung" gekostet).
Eine echte
Verbesserung des Bildes (für welche Du vermutlich filterst) werde ich bei Verwendung von SSIM natürlich nie erzielen können, das ist mir schon bewusst.
Aikousha wrote:Das allein sagt aber nicht viel aus. Für mich ist das was ich sehe, das wichtigste. Selbst wenn nach dem Denoising mein SSIM um 5,0% fällt, mir das Ergebnis aber gefällt, werde ich so denoisen.
Wenn ich diese Encoderaugen hätte, dann würde ich das womöglich auch tun...
Aikousha wrote:Als Alternative zu RemoveGrain(2) lohnt es sich ruhig mal DeGrainMedian(2) (kurz DGM) zu probieren.
Alle von Dir genannten Filter stehen auf meiner Liste; inzwischen tendiere ich aber dazu, die "schweren Geschütze" in einer Einstellung verwenden zu wollen, die eine "endliche" Laufzeit bewirkt (bei dfttest habe ich schon gesehen, wie die Laufzeit explodiert, wenn man
sämtliche Qualitätsschrauben gleichzeitig nach oben dreht... irgendwann wird CPU-Leistung dann doch eine knappe Ressource, wenn die Laufzeiten für das Filtern einer einzigen Episode
weit mehr als einen Tag betragen).
Wenn ich durch eine Steigerung der Filter-Laufzeit von 20 auf 60 Minuten bei gleichem SSIM-Wert 10 MB pro Episode einsparen kann, finde ich die Zeit gut investiert; wenn ich für die nächsten 10 MB Einsparung zu gleichen Bedingungen aber 30
Stunden Filterlaufzeit brauche, dann wird der Sinn der Aktion irgendwann fragwürdig. (Insbesondere dann, wenn ich eine komplette Serie subben und in einem Rutsch encoden und releasen will... das XviD-Encoden für alle 10 Episoden BSM lief bequem in einer Nacht durch.)
Aikousha wrote:DeviDoll, ich würde es begrüßen, wenn du deine Tests ausführlicher Dokumentieren könntest. (Bspw. wie BrotherJohn es macht. Bei seinem mod16-Test brauch ich nur meine DVD aus Regal zu nehmen und kann sofort den Test gegenprüfen.) Mir persönlich sind v.a. die AviSynth-Skripte und die XviD-Einstellungen am wichtigsten.
Pro Durchgang läuft ein AVS-Skript in VirtualDub 1.6 und speichert ggf. seine Ausgabe als AVI-Container mit Direct Stream Copy.
1. Durchgang (Laufzeit: ca. 20 Minuten)
Code: Select all
Mpeg2Source ("C:\DVD-Analyse\Iriya no Sora\Iriya DVD4\DVD4.d2v")
tfm (slow=2)
tdecimate (mode=1)
crop (2, 0, -2, -0)
LanczosResize (640, 480)
Erzeugt einen unkomprimierten Stream (18.527.780.452 byte) als AVI; dieser wird aufbewahrt und dient als Referenz für sämtliche nachfolgenden SSIM-Messungen.
2. Durchgang (Laufzeit: variabel je nach Filter, bisher 20-550 Minuten): Anwendung eines Filters (=ein AVS-Skript mit nur genau dem in der Ergebnistabelle angegebenen einzeiligen Filter-Aufruf), wiederum via Direct Stream Copy unkomprimiert in ein AVI gespeichert.
Bei MVDegrain wird dies erstmals nicht mehr gehen, weil für dessen Bewegungsvektoranalyse ein komplettes (kleines) Skript geschrieben werden muss (hier habe ich das MVDegrain2-Beispiel aus dem Handbuch exakt abgeschrieben, weil mir dessen Laufzeit mit gut 4 Stunden spontan noch vertretbar erschien - mein Versuch, die Parameter etwas "nach oben zu drehen", hätte dann mehr als 30 Laufzeit nach sich gezogen).
Wenn ich mehrere Dimensionen einstellen muss, dann funktioniert das mit meiner Tabellenform bei den Ergebnissen nicht mehr; deshalb habe ich bisher versucht, alles bis auf "sigma" oder dessen Äquivalent unverändert zu lassen. (Letzten Endes "teste" ich damit wohl eher die Defaultwerte der Filterfunktion als deren eigentliche Fähigkeiten, weil ich für letztere erst mal einen Plan entwickeln müsste - genau das will ich aber vermeiden, weil ich ja ein Ergebnis ohne permanenten Pflegeaufwand haben will, das trotzdem als Nachfolger von "RemoveGrain(2)" gute Dienste tun wird. In Doom9-Threads habe ich gesehen, dass andere "Encoder" zum Teil auch so denken und am liebsten nur einen einzigen Sigma-Parameter haben wollen, am besten mit einem Wertepaar, das "animeHQ" bzw. "animeLQ" entspricht.)
Erzeugt wiederum eine 18.527.780.452 byte-Datei als AVI; diese wird bis nach dem 5. Durchgang aufbewahrt und dann gelöscht.
3. Durchgang (Laufzeit: ca. 40 Minuten):
a=AVISource ("Episode 4 ungefiltert unkomprimiert.avi").trim(1,0)
b=AVISource ("Episode 4 MVDegrain2 unkomprimiert.avi").trim(1,0)
return ssim (a, b, "Episode 4 MVDegrain2 unkomprimiert.csv", "Episode 4 MVDegrain2 unkomprimiert.txt", lumimask=1)
Erzeugt CSV- und TXT-Datei; der SSIM-Wert der TXT-Datei ist der gesuchte Messwert. Dateinamen werden pro Filter-Kandidat angepasst.
4. Durchgang (Laufzeit: ca. 50 Minuten): XviD-Komprimierung (VirtualDub 1.6, FastRecompress). Parameter: Das, was ich beim Encoden immer verwende. Relativ zu den XviD-Defaults ist das: +QPel, max.consecutive BVOP 4, target bitrate 9999, +Chroma Optimizer, VHQ-mode 4, +VHQ for BFrames, min.P-Frame Quant=2.
5. Durchgang (Laufzeit: ca. 40 Minuten): SSIM-Messung wir 3. Durchgang, aber nun XviD-Encoding relativ zur Referenzdatei.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Aikousha wrote:Dies ist einer der aktuelleren Denoiser-Vergleiche, den ich auf Doom9 gefunden habe. (jetzt weißt du auch, warum dfttest bei mir ganz oben auf der Liste steht^^)
Ich finde die Angaben für die Parameter der jeweiligen Filter dort sehr vage - insofern sagt mir der Test zunächst schon mal nichts darüber aus, welche Parameter-Tupel ungefähr vergleichbare Resultate liefern. Auch scheint gegen Ende des Threads "DCTFun7" relativ gut abzuschneiden - und gegen dfttest habe ich bisher, dass er
ungeheuer langsam ist für das, was er an Ergebnissen liefert (als temporaler Radius-1-Filter langsamer als MVDegrain2 mit Radius 2!).
Für einen richtigen Vergleichstest der Filter müssten vermutlich die Programmierer gegeneinander antreten. Jeder müsste ein Video einreichen dürfen (denn letzten Endes werden sich bestimmte Filter für bestimmte Videos besonders gut eignen), alle Teilnehmer müssten als Aufgabe gestellt bekommen,
bei einer Einsparung von mindestens 5% pro Video ein maximales Produkt der SSIM-Werte sämtlicher eingereichter Videos zu erzeugen, und jeder dürfte mit seinem eigenen Filter vier Wochen lang an allen Videos herumfiltern... so eine Art "Springreiterfinale mit Pferdetausch", wobei die Videos die Pferde wären und die Filter samt ihrer Programmierer die Reiter.
Das Problem am Entfernen von künstlich erzeugten Rauschen, wie es in diesem Doom9-Testszenario vorgegeben ist, erscheint mir, dass es in einem idealisierten Universum stattfindet, nämlich ohne anschließende Komprimierung des Materials. Genau letzteres ist aber bei Anime-Fansubs unverzichtbar - die gefilterten Videos sollen ja letzten Endes zu den Leechern übertragen werden, was in unkomprimierter Form nicht (in akzeptabler Zeit) möglich ist.
Deshalb interessiert mich ein hoher SSIM-Wert direkt nach dem Filtern (den ich mit
jedem Filter hinkriege, sofern ich nur das sigma klein genug wähle) auch gar nicht, sondern eben ein hoher SSIM-Wert nach dem XviD-Encoden bei einer gewünschten Maximal-Dateigröße (bzw. umgekehrt
eine geringe Dateigröße bei einem gewünschten Mindest-SSIM-Wert nach XviD-Encoding). In meinem konkreten Beispiel also etwa die minimal erzielbare Dateigröße für SSIM-Werte über 90% bzw. über 89.5%, wenn ich also ca. 0.5% bzw. 1% SSIM für die Filterung zu "opfern" bereit bin in der Hoffnung, dabei möglichst viel Dateigröße zu sparen. Denn letzteres kann mangels anderer Qualitätskriterien als SSIM ja wohl nur das einzige anzustrebende Ziel des Filterns sein, wenn man keine nicht quantifizierbaren Ziele wie "schönes Aussehen" anstrebt.
Ich leiste mir auch den Luxus eines ziemlich langen Videos (40000 Frames), weil ich die in diesem Doom9-Test verwendeten 30 Frames nicht wirklich aussagekräftig finde (insbesondere was eine eventuelle MP4-Komprimierung angeht, die ich ja mit "testen" will - für das DeGrainen von künstlichem Noise alleine könnten sie ausreichen).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ich habe meine Tabelle etwas erweitert, um den Temporalen Radius und die Laufzeit der Filterdurchgänge (welche jeweils das Lesen&Schreiben von 17 GB Daten auf meiner Festplatte beinhalten und damit nicht unter 15 Minuten fallen können, die alleine schon das ungefilterte Kopieren der Datei dauern würde - die 2D-Filter verbrauchen also praktisch "keine" Zeit) mit aufzunehmen.
MVDegrain2 (siehe
hier) schaffte heute gleich mit dem ersten Versuch (sehr gute Dokumentation!) den Sprung in die
Spitzenklasse sowohl nach SSIM als auch nach Dateigröße und liefert damit angesichts einer noch erträglichen Laufzeit eine ernst zu nehmende Alternative zu FFT3Dfilter - was dcttest bei meinen bisherigen Versuchen noch nicht ganz gelungen ist (bei gleicher Dateigröße 0.41% SSIM weniger, und das trotz gut doppelter Laufzeit,
und letzteres trotz Ausnutzung beider CPU-Kerne, was FFT3Dfilter nicht kann!).
Das Skript zum MVDegrain2-Filterdurchgang:
Code: Select all
source = AVISource ("Episode 4 ungefiltert unkomprimiert.avi")
vb2 = source.MVAnalyse (isb=true, delta=2, pel=2, overlap=4, sharp=1, idx=1) # Vektor-Liste für Frame-2 erzeugen
vb1 = source.MVAnalyse (isb=true, delta=1, pel=2, overlap=4, sharp=1, idx=1) # Vektor-Liste für Frame-1 erzeugen
vf1 = source.MVAnalyse (isb=false, delta=1, pel=2, overlap=4, sharp=1, idx=1) # Vektor-Liste für Frame+1 erzeugen
vf2 = source.MVAnalyse (isb=false, delta=2, pel=2, overlap=4, sharp=1, idx=1) # Vektor-Liste für Frame+2 erzeugen
source.MVDegrain2 (vb1, vf1, vb2, vf2, thSAD=400, idx=1)
Das ist alles mit zusätzlicher CPU-Power noch
erheblich aufrüstbar: "pel=4" wäre beispielsweise genauer in der Bewegungsanalyse, und man könnte noch eine genauere (aber langsamere) Suchfunktion verwenden (hier wurde der Default verwendet) - alleine diese beiden Änderungen würden die Laufzeit von 4 auf 30 Stunden hochziehen. Und
außerdem gibt es noch MVDegrain3, das dann mit temporalem Radius von 3 (also 7 Frames) arbeiten würde... wer so richtig CPU-Zeit verbraten will, ist hier richtig, denke ich mal. "thSAD" scheint der "sigma"-Parameter zu sein - an dem habe ich noch nicht gedreht.
Mein nächster Test wird "FFT3Dfilter (sigma=1.1, bt=5)" sein, um zumindest "Waffengleichheit" gegenüber MVDegrain2 in Bezug auf den temporalen Radius von 2 herzustellen - FFT3Dfilter wird dafür nur 1:50 Stunden brauchen, bei dcttest versuche ich das gar nicht erst... das würde Tage dauern. Wie ich für FFT3Dfilter eine gleichwertige Bewegungsanalyse bauen müsste, das habe ich noch nicht begriffen.