Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Support zu Fansubs
User avatar
Kaoru_Battlemuffin
Senpai
Senpai
Posts: 143
Joined: 29.12.2007 21:35
Gruppe: Gruppe Kampfkuchen

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Kaoru_Battlemuffin »

Erstaunlich erstaunlich ...

Für dfttest und FrFun7 hab ich keine settings da ich die selber noch nicht ausprobiert habe(besitze sie zar aber ...)

Bei deen, wie du selbst schon erklärt hast is nur a3d sinnvoll.
Und bei Convolution3d halt die Anime Settings, die meiner Meinung nach noch sehr oft ausreichen und von der Geschwindigkeit auch nicht gerade schlecht ist ....

Aikousha könnte wahrscheinlich ein paar Tipps zu dfttest geben ... zu FrFun7 müsste jabba sich mal erübrigen ...
Image
Image

Use CCCP9+9, Codename "NEIN NEIN NEIN"
User avatar
Devil Doll
Kámi-sama
Kámi-sama
Posts: 584
Joined: 30.12.2007 00:18
Gruppe: Devil Doll
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Devil Doll »

Langsam beginne ich, ein paar der Parameter der diversen Filterfunktionen zu verstehen...

FFT3Dfilter hat einen Parameter "bt" für die "block temporal size", der angibt, wie viele Frames für die zeitliche Komponente der 3D-Filterung berücksichtigt werden sollen. Der Default-Wert ist hier "3" (also der aktuelle Frame plus einer davor und einer danach), der maximal zulässige Wert wäre 5 (dann wird der Filter wahrscheinlich noch deutlich langsamer, vielleicht aber auch noch effizienter in Sachen XviD-Komprimierung?).

dfttest hat mit "tbsize" (= "temporal block size") einen offenbar äquivalenten Parameter. Dessen Defaultwert ist allerdings "1", d. h. dfttest ist per Default ein 2D-Filter; mit "tbsize=3" müsste er ähnlich arbeiten wie FFT3Dfilter bei dessen Default-Werten.
Allerdings habe ich bereits gesehen, dass der Defaultwert "1.7" für den "sigma"-Parameter von dcttest für mein Anime-Material viel zu aggressiv ist (das drückt den SSIM-Wert schon ohne XviD-Komprimierung unter 90%, die XviD-komprimierte Datei wird auch spektakulär kleiner, aber es ist auch offensichtlich, wieso...) - da werde ich noch etwas herumprobieren müssen.

FRFun7 hat keine Möglichkeit, als 3D-Filter zu arbeiten. Es hätte einen "lambda"-Parameter, der die Stärke des "local denoising" bestimmt (Defaultwert: "1.1") und der möglicherweise etwas Ähnliches wie der "sigma"-Parameter von FFT3Dfilter sein könnte - aber ich sehe keine Chance, dass dieser Filter "sein Geld wert" sein könnte (die Laufzeiten sind einfach zu exorbitant für einen 2D-Filter).
User avatar
Onichi
Anime Gucker
Anime Gucker
Posts: 80
Joined: 05.01.2008 15:22

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Onichi »

Ich habe mal eine allgemeine Frage dazu.
Mein Programm das ich benutze ist sehr simple in der Bedienung,
Einfach Videodatei auswählen Maße auswählen, umwandeln.
Ganz simpel in der Bedienbarkeit.

Ich habe die aktuellste Version heruntergeladen und das Ding kann immer noch nicht beide Cpu Kerne voll ausnutzen.

Jetzt die Frage passend zum Thema, unterstützen die Tools oder Programme mehere Kerne?
Das spielt doch schon eine wesendliche Rolle, vorallem weil es schon bald 6 Kerne für Server geben soll.
Image
User avatar
Kaoru_Battlemuffin
Senpai
Senpai
Posts: 143
Joined: 29.12.2007 21:35
Gruppe: Gruppe Kampfkuchen

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Kaoru_Battlemuffin »

CLI Encoder wie x264 oder XviD sind Multithreadfähig. Wie es mit Avisynth aussieht bin ich mir nicht sicher aber ich meine Avisynth nutzt default nur einen Kern? Man kanns allerdings mehrere nutzen auch mit verschiedenen Modes ( http://avisynth.org/ScriptFunctions nachzulesen und Multi threading)
Image
Image

Use CCCP9+9, Codename "NEIN NEIN NEIN"
User avatar
Devil Doll
Kámi-sama
Kámi-sama
Posts: 584
Joined: 30.12.2007 00:18
Gruppe: Devil Doll
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Devil Doll »

Wenn ich in VirtualDub ein AVS-Skript abspielen lasse, das eine Filterfunktion anwendet, die selbst multithreadfähig programmiert ist (dcttest ist beispielsweise eine solche und besitzt sogar einen Parameter, mit dem man dieses Feature ein- und ausschalten kann), dann wird mein (ziemlich altes) 2-Prozessor-System zu 100% ausgelastet. Avisynth alleine kann also nicht der Engpass sein.

Das ist aber nicht bei allen Abläufen der Fall. Deshalb lasse ich bei meinen aktuellen Tests auch meistens mehrere Aktionen parallel laufen - möglichst immer einen Filterdurchgang, ein XviD-Encoding und eine SSIM-Messung, um einen schönen Prozess-Mix zu bekommen (XviD und 3D-Filter saugen am meisten CPU-Zeit, 2D-Filter und SSIM-Messungen machen hingegen ungeheuer viele Festplattenzugriffe).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Das Neueste aus dem "Filterlabor": Erste Zahlenwerte zu dfttest und deen.

dfttest mit seinen Default-Parameterwerten (tbsize=1, also nur 2D-Filterung, sowie sigma=1.7, dessen Wirkung in der Readme-Datei nur mit Hilfe einer Formel erklärt wird, die ich nicht verstehe) geht anscheinend ziemlich ruppig mit dem Videomaterial um, auf welches es angesetzt wird: Allein bei der Anwendung dieses Filters geht mehr SSIM-Wert verloren als bei einer XviD-Komprimierung des Rohmaterials um Faktor 80! Dementsprechend belegt dfttest mit diesen Einstellungen (im Doom9-Thread hat auch jemand gemeint "oops - zu verwaschen" und dann Bilder besserer Qualität mit erheblich niedrigeren sigma-Werten erzeugt, bin hinunter zu sigma=0.25) bisher den vorletzten Platz in beiden SSIM-Ranglisten, einzig der "Linienzerstörer" RemoveGrain(4) richtet wohl noch mehr Schaden an. Immerhin bewirkt der Filter eine spektakuläre Einsparung an Dateigröße, aber das alleine ist ja nicht das Ziel an sich und könnte von anderen Filtern mit aggressiveren Einstellungen womöglich auch erreicht werden. Weitere Versuche mit niedrigeren sigma-Werten und vor allem mit Nutzung der temporalen Komponente werden folgen - die Default-Einstellungen scheinen aber nur für den absoluten Weichspülgang zu taugen. Auch sigma=1.3 ist noch "die Axt im Walde".
Zudem ist dfttest schon als 2D-Variante extrem langsam (Faktor 3 gegenüber FFT3Dfilter) - in der 3D-Variante wird der Filter dann unglaublich CPU-intensiv, die Laufzeit steigt nochmal um Faktor 3! Das kann's eigentlich nicht sein. Ich werde trotzdem heute Nacht mal einen Lauf mit sigma=0.6 in der 3D-Variante machen, vielleicht taugt dann ja wenigstens das Ergebnis etwas...
EDIT: Und tatsächlich: Wenn man dfttest mit passenden Parametern ausstattet, dann bekommt man Leistung für den ungeheuren Aufwand, den der Filter treibt. Als 3D-Filter mit einem vernünftigen sigma ausgestattet schlägt dfttest die bisherigen Bestleistungen von FFT3Dfilter knapp - nach 9 Stunden Laufzeit (während der Konkurrent meinen Rechner gerade mal eine Stunde lang beschäftigte).

deen mit den Parameterwerten ("a3d", 1), also der Eigenbau-3D-Filter-Variante und "mode 1" = "spatial radius" von 3x3px (den muss man angeben - der Parameter selbst hat in Abhängigkeit von anderen Parametern verschiedene Bedeutungen und der Defaultwert von 0 bewirkt bei "a3d" eine Fehlermeldung von AviSynth... seltsamer Programmierstil, finde ich) liefert alles in allem enttäuschende Ergebnisse: Ziemlich niedrige SSIM-Werte bei gleichzeitig nur sehr geringer Komprimierungswirkung. Von einem 3D-Filter hätte ich mehr erwartet. Ein höherer "spatial radius" ändert auch nur wenig am Ergebnis (der Filter wird dadurch etwas "aktiver", also kleinere Dateigröße bei allerdings sinkenden SSIM-Wert).
Inwiefern die beiden zusätzlich einstellbaren luma/chroma-Thresholds ("kleinere Werte filtern schwächer" ist alles, was die Readme-Datei dazu meint) hier etwas reißen können, kann ich noch nicht beurteilen - die Defaultwerte scheinen jedenfalls für Animes guter Qualität nicht geeignet zu sein. Wenigstens bei der Geschwindigkeit liegt deen etwa auf Augenhöhe mit FFT3Dfilter - also scheint bei dfttest irgendwas ganz schrecklich viel aufwändiger abzulaufen...

Generell ist es natürlich so, dass ein Filter-DAU ohne "Encoderaugen" wie ich im Wesentlichen versuchen kann, die mitgelieferte Dokumentation durchzulesen und dann Parameterwerte zu raten. Deshalb halte ich es für durchaus wahrscheinlich, dass in meinen Experimenten diejenigen Filter am besten abschneiden werden, die ganz einfach eine gute Dokumentation mitliefern (FFT3Dfilter und RemoveGrain) und/oder sinnvolle Defaultwerte für ihre Parameter festgelegt haben (Convolution3D).
Sowohl die beiden Anime-Varianten von Convolution3D als auch die Ober- und Untergrenze des empfohlenden sigma-Wertes von FFT3Dfilter bewirken SSIM-Werte des XviD-encodeten Videos zwischen 89 und 90%; mein Ziel wird es also sein, die übrigen Filter jeweils so einzustellen, dass vergleichbare SSIM-Werte herauskommen, und dann anhand der Dateigröße zu erkennen, wer bei Erhalt von "hinreichend viel" Qualität die beste Einsparung ermöglicht. (Wobei die Laufzeit sicherlich auch irgendwo noch in die Bewertung einfließen wird, aber die Ergebnisse von FFT3Dfilter(sigma=2.0) dürften die naheliegenderweise dreifache Laufzeit gegenüber RemoveGrain oder Convolution3D wert sein; beachte: Convolution3D arbeitet in seiner unter AviSynth2.5 lauffähigen Variante nur als 2D-Filter, was sein hohes Arbeitstempo erklärt.)

Genau diese gute Dokumentation hat mich dazu bewogen, einen weiteren Programmlauf mit RemoveGrain(1) (was laut Readme-Datei identisch ist zu trbarry's Undot), dem vorsichtigsten der knapp 20 von RemoveGrain implementierten Filterverfahren (Verfahren "2", mein "Traditionsfilter", ist der Defaultwert von RemoveGrain und die aktivere der beiden "artefaktfreien" Alternativen neben "1"), zu absolvieren - und siehe da: Das liefert tatsächlich die höchsten bisher gemessenen SSIM-Werte vor und nach der XviD-Komprimierung und gleichzeitig auch noch eine Einsparung, die immerhin mit Convolution3D in der "animeHQ"-Einstellung mithalten kann!
Also ein echter Kandidat für jemanden, der für DVDs eine Billiglösung als Filter sucht, denn in Sachen Tempo ist RemoveGrain als 2D-Filter natürlich ganz vorne mit dabei (Convolution3D ebenfalls). FFT3Dfilter(sigma=1.0) liefert allerdings die doppelte Einsparung bei fast identischem SSIM-Wert nach XviD-Komprimierung (und überzeugt generell durch ein gutes Preis/Leistungs-Verhältnis in allen SSIM-Bereichen bei akzeptabler Verarbeitungsgeschwindigkeit und einfacher Bedienbarkeit).
User avatar
Aikousha
Neko-chan
Neko-chan
Posts: 32
Joined: 30.12.2007 20:35
Gruppe: TK, GAX, kA-Oz
Location: #kompressionisten@irc.otakubox.at
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Aikousha »

Devil Doll wrote:
Aikousha wrote:Wenn man den Encoder künstlich begrenzt, muss man auch ganz genau wissen, was man tut. ... Ich bin eher der Meinung, dem Encoder alle Freiheiten zu gewähren, und ihn dafür an anderer Stelle besser zu regulieren.
Und was wäre diese "andere Stelle"? (Filtern?)
Nein, bei den Avi-Synth Filtern nicht. Geht ja um die Encoder-Einstellungen. Spontan würde ich sagen: "XviD" -> "Encoding Type: Two pass - 2nd pass" -> "more..." -> "2pass", sowie bei B-VOP. Aber wie gesagt, hier sollte man nur spielen, wenn man weiß, was man tut.
Devil Doll wrote:Generell fällt Filterung allerdings eigentlich in einen Bereich, von dessen Sinnhaftigkeit ich nach wie vor nicht überzeugt bin, gerade weil jedes neue Video anscheinend einen immer wieder neuen, individuellen Ansatz zur "angemessenen" Filterung erfordert. Mein "Test" sollte als Ergebnis haben, eine überzeugende Bestätigung für den mod16-Ansatz zu liefern, damit ein Encoder an dieser Stelle ein "Patentrezept" nutzen kann, ohne dafür eigene Zeit zu verschwenden; im Bereich der Filter scheint ein solcher Pauschal-Ansatz grundsätzlich unmöglich zu sein.
Wenn das nicht so wäre, hatten die Encoder ja nichts mehr zu tun. ;)
Es ist nunmal so, wie du sagst. Jede RAW ist anders. Für jede müssen die Filter neu abgewogen werden. Neu optimiert werden. Einige werde eher gebraucht, andere weniger, und manche nur bei Spezialfällen. Das gilt für alle Filter. Ich hab bestimmte "Lieblingsfilter" und "Standardeinstellungen". Diese nutzt ich als Ausgangsbasis. 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.

RemoveGrain(2) ist ein recht guter "quick and dirty" Filter, was nicht heißt, das der Filter nicht allerhand zum Feintunen bietet (allein die ganzen modes) (ähnliches auch bei DeGrainMedian). Es gibt bestimmt durchaus solche "Standards". Doch mir als Encoder (falls ich mich hoffentlich bald so nennen darf) geht es aber nicht um den "schnellen" Weg. Es ist ja gerade die Herausforderung, aus den Filtern das Maximum herauszuholen. Die RAW subjektiv noch schöner zu machen. Ohne Rücksicht auf Rechenzeit (bin Qualitätsfanatiker). Gute RAWs verringern das Risiko, den Film kaputt zu filtern. Doch auch wenn die Qualität heutiger DVDs (und bald BDs) recht gut ist, sie ist (fast) nie so, wie ich sie gerne hätte (rein subjektiv). (Eine leidige Tendenz die ich da leider feststelle ist, dass bei Digital-Produktionen z.T. künstliches Rauschen nachträglich hinzugefügt wird. Ganz dumm ist das auch nicht. Erstens nimmt das Auge dieses Rauschen als "fiktive" Details wahr. Zweitens wirkt es der Eingenschaft von LCDs entgegen, dass sich nicht verändernder Hintergrund "statisch" wirkt und das Auge den Hintergrund nicht mehr wahrnimmt, da sich dort "keine" Pixel ändern würden. Ich persönlich mag beides nicht: wenn dann soviel wie möglich "echte" Details und so wenig wie möglich Rauschen.)
___

Erstmal danke, dass du dir die Mühe machst, einen eigenen Test durchzuführen.

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^^)

Persönlich würde ich einen Denoiser danach beurteilen (rein objektiv), wieviel SSIM dieser erhält, im Gegensatz zur Einstparung in der Dateigröße. 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.

Als Alternative zu RemoveGrain(2) lohnt es sich ruhig mal DeGrainMedian(2) (kurz DGM) zu probieren.

Zu Convolution3D & Deen: Nutze ich persönlich nicht. Diese Filter sind mir zu alt. (Das ich so Voreingenommen bin, möge man mir verzeihen. Aber ich finde, für diese gibt es ausreichend "modernen" Ersatz.)

Zur FRFun-Familie: Dise Filter sind nicht schlecht. Sie sind etwas "komisch" (wie alle Filter von diesem Autor), aber nicht schlecht. Es sind für mich eher Spezialfilter, auf die ich zurückgreifen würde, wenn meine "Lieblingsfilter" mit dem Ausgangsmaterial nicht zurechtkommen / ich mit dem Ergebnis nicht zufrieden bin. FRFun fordert schon etwas mehr an Feintuning, aber wenn man es geschafft hat, überzeugt auch da Ergebnis. (BTW, und nur weil ein Filter nur spatial arbeitet, heißt das nicht, das er nicht mit spatiotemporalen Mithalten kann. Vergleiche bspw. dfttest() mit dfttest(tbsize=5))

Zu FFT3D & DFT:
Bei diesen Filtern ist nicht vorerst sigma=x die erste Einstellung, sondern die Überlegung, wie groß die Blöcke für die Rausch-Erkennung sein sollen. (Größere Macroblocks & Überlappung = Macroblockgröße/2 ergeben meist starkes Denoising, brauchen aber auch viel Performance.) Falls du fft3d vs. dft testest, bitte darauf achten, dass die Macroblöcke und Überlappungen gleich groß sind.
Z.Z. experimentiere ich mit MC+dfttest. Für den Einstieg würde ich "sigma=0.5" vorschlagen. Das ist ziemlisch pauschal. Ich geb ungern Einstellungstipps, wenn ich das RAW nicht kenne. Den Parameter "swin,twin" würde ich erstmal ignorieren. Darin bin ich selbst noch nicht vertieft. Und um die Auswirkung der Windows zu verstehen, muss man schon DCT aus dem ff können.
___

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

Kleine Anmerkung am Rande: Ich Lossless-Encode derzeit mit MC+dfttest und noch ein paar anderen Spielereien. Für eine 25min-Folge würde ich mit dem Skript auf meinem E6600 ~10h brauchen. (Wie gesagt, ich bin Qualitätsfanatiker, denn Zeit ist relativ)
___

AviSynth v3.0 soll Multithreading unterstützten. Wann das aber jemals erscheinen wird steht in den Sternen (Schätzung: Ende 2009) So lange können sich mutige mit dem Filter MT() behelfen.
___

Für den geneigten Mitleser:
1. Die hier getesteten Parameter und Ergebnisse beziehen sich auf das Quellmaterial von DevilDoll und sind nicht ohne weiteres 1:1 übertragbar. (Keine Statistische Aussagekraft)
2. Readme der Filter lesen!
3. Doom9-Thread der Filter lesen!
4. Denken.
5. Gerne und höflich fragen.
Aikousha ist kein fansub-anerkannter Encoder, da er nicht mit YATTA und AAE umgehen kann.
Da Zeit relativ und Qualität subjektiv ist, kann ich auch bei 1fps encoden.
User avatar
Devil Doll
Kámi-sama
Kámi-sama
Posts: 584
Joined: 30.12.2007 00:18
Gruppe: Devil Doll
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Devil Doll »

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.
User avatar
Aikousha
Neko-chan
Neko-chan
Posts: 32
Joined: 30.12.2007 20:35
Gruppe: TK, GAX, kA-Oz
Location: #kompressionisten@irc.otakubox.at
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Aikousha »

Devil Doll wrote:
Aikousha wrote:Persönlich würde ich einen Denoiser danach beurteilen (rein objektiv), wieviel SSIM dieser erhält, im Gegensatz zur Einsparung in der Dateigröße.
Ich bin nicht sicher, ob ich diesen Satz verstanden habe. Meintest Du "Verhältnis" statt "Gegensatz"?
Sagen wir es einfach mathematisch:

Code: Select all

					SSIM-Verlust / Einsparung	Einparung / SSIM-Verlust
RemoveGrain(2)	0,2652 /  2,68 = 0,0990	 2,68 / 0,2652 = 10,1055
MVDegrain2		 0,4082 / 10,95 = 0,0372	10,95 / 0,4082 = 26,8251
MVDegrain2 ist besser als RemoveGrain(2): 0,0372 < 0,0990 (für die Einsparung, habe ich weniger SSIM verloren) & 26,8251 > 10,1055 (für meinen SSIM-Verlust habe ich mehr Eingespart)
Hach ja, Zahlen sind schön. Aber sie sind nicht alles. Wie gesagt, für mich zählt als erstes das, was ich sehen.
___

Danke für die Doku. Persönlich halte ich ja nichts von Test mit Resizern, aber da du hier ja a) nah an der Praxis bleiben möchtest, und b) der lossless auch schon resized ist, dürfte es kein Problem sein.
___

Ich drück es mal etwas Platt aus: Wenn es um einen "einfachen" (sprich: wenige, einfach Optionen) Filter gehen soll, wäre MVDegrainX wahrscheinlich am ehesten geeignet, denn dieser hat keine "Stärke"-Option. Es gibt zwar einen Parameter "thSAD", der ist aber nicht mit bspw. "Sigma" von DFT oder FFT3D zu vergleichen (da thSAD ganz anders arbeitet).

Für einen "Waffengleichstand" würde ich als Grundlage einen 16x16 Pixel großen Makroblock mit 8x8 Pixel Überlappung über alle Filter vorschlagen. Es ist nicht fair für alle Filter, aber für einen Vergleich ganz interessant. Da n+-3 zu lang ist, bleiben wir bei n+-2 Frames.

Vorschlag für MVDegrain2

Code: Select all

vb2 = source.MVAnalyse (isb=true,  delta=2, pel=2, blksize=16, overlap=8, idx=1)
vb1 = source.MVAnalyse (isb=true,  delta=1, pel=2, blksize=16, overlap=8, idx=1)
vf1 = source.MVAnalyse (isb=false, delta=1, pel=2, blksize=16, overlap=8, idx=1)
vf2 = source.MVAnalyse (isb=false, delta=2, pel=2, blksize=16, overlap=8, idx=1)
source.MVDegrain2 (vb1, vf1, vb2, vf2, idx=2)
Vorschlag für FFT3DFilter (Sigma anpassen)

Code: Select all

FFT3DFilter(sigma=0.75, bt=5, bw=18, bh=16, ow=8, oh=8)
Vorschlag für DFTtest (Sigma anpassen, zur Not kein "tosize=2")

Code: Select all

dfttest(sigma=0.75, sbsize=16, sosize=8, tbsize=5, tosize=2)
FFT3D & DFT brauchen keine Bewegungsanalyse wie MVDegrainX, diese könne das von Haus aus. (Es gibt aber natürlich auch die Möglichkeit einer externe Motion Compensation. Diese meinte ich, als ich von mc+dft redete.)
Aikousha ist kein fansub-anerkannter Encoder, da er nicht mit YATTA und AAE umgehen kann.
Da Zeit relativ und Qualität subjektiv ist, kann ich auch bei 1fps encoden.
Vidom
Pokito-Fan
Pokito-Fan
Posts: 1
Joined: 17.01.2008 21:54

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Vidom »

-
Last edited by Vidom on 09.08.2008 08:30, edited 1 time in total.
User avatar
Devil Doll
Kámi-sama
Kámi-sama
Posts: 584
Joined: 30.12.2007 00:18
Gruppe: Devil Doll
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Devil Doll »

Aikousha wrote:Wenn es um einen "einfachen" (sprich: wenige, einfach Optionen) Filter gehen soll, wäre MVDegrainX wahrscheinlich am ehesten geeignet, denn dieser hat keine "Stärke"-Option.
Gar keine Stärke-Einstellmöglichkeit fände ich auch unpraktisch, dann könnte ich nicht auf unterschiedliches Video-Material eingehen.
Der sigma-Parameter von FFT3DFilter gefällt mir gerade deshalb, weil er ein skalarer Wert ist und die Readme-Datei ein vernünftiges Werte-Intervall [1.5,2.5] für "normale" Fälle angibt (und in diesem Intervall liefert der Filter dann relativ proportional zusätzliche Komprimierungswirkung für SSIM-Verlust; meine vorliegende DVD scheint auch mit weniger "Filterkraft" noch ganz gut filterbar zu sein). Dass MVDegrain2 gleich mit seinen Standardwerten ein Glückstreffer war, spricht deshalb eher für seine anscheinend gut gewählten Defaultwerte als für sein Bedienungskonzept insgesamt (zumal er ja eine doch etwas unhandlich aussehende Konstruktion für seine Bewegungsanalyse benötigt - diese ist aber dafür gut dokumentiert).

MVDegrain3 liegt nach 8 Stunden Rechendauer trotz Verwendung von pel=4 (Viertelpixel-Bewegungen - bedeutet das, dass mein XviD-Encoding mit QPel dazu das passende Gegenstück wäre?) nach Aikoushas "Rentabilitätsformel" mit 22,43 Punkten nur auf Rang 2, kratzt jedoch dabei an der 200MiB-Grenze bei immer noch recht gutem SSIM-Wert.
Was die Bewertung angeht, so denke ich, einen gewissen "Mindestverlust" hinnehmen zu wollen - denn wenn ich das nicht tue, dann würde der reine Quotient zwischen Einsparung und SSIM-Verlust bei extrem schwacher Filterung (also einem Divisor von nahezu Null) extrem stark streuende Ergebnissen liefern. Deshalb habe ich auch die SSIM-Werte von 90% und 89% mit Linien markiert - ungefähr innerhalb dieses Bereichs würde ich den Quotient für sinnvoll halten. (Derzeit sieht es so aus, als würden die wirklich heftigen Filter sogar eine Chance haben, bei 200 MiB 90% SSIM zu erreichen - mal sehen, ob das tatsächlich möglich ist, viel fehlt ja nicht mehr.)
Alternativ zum Filtern könnte ich ja auch einfach versuchen, mit XviD-2-pass auf 950 kb/sec zu encoden (das werde ich auch noch irgendwann ausprobieren), um auf diese Weise 30 MB einzusparen - ich gehe allerdings davon aus, dass der SSIM-Wert dabei stärker leidet als beim Filtern (denn sonst hätte das Filtern ja irgendwie deutlich weniger Sinn, auch wenn mir bewusst ist, dass das Ziel beim Filtern nicht primär die Einsparung von Dateigröße ist, aber Entrauschen führt nun mal auch zu besserer Komprimierbarkeit, insofern sind beide Ziele wenigstens teilweise deckungsgleich).

Bei FFT3Dfilter habe ich die richtigen Parameter wohl noch nicht gefunden (als nächstes werde ich Vidoms Tip mit den Farbkanälen ausprobieren, Schärfen will ich im Moment nicht, das würde den SSIM-Wert stark beeinträchtigen; danach kommen die Filter-Skripte von Aikousha dran), die Erweiterung auf temporalen Radius 2 alleine bringt nicht den Quantensprung, kostet allerdings auch immer noch vergleichsweise wenig CPU-Zeit (das wird mit Vidoms Einstellungen dann deutlich langsamer, aber immer noch unter 5 Stunden, meint die Hochrechnung).

Vor allem bei dfttest habe ich noch nicht begriffen, wieso der schon mit "harmlosen" Einstellungen so schrecklich langsam ist; auch erscheint mir das vorgeschlagene sigma von 0.75 eher noch zu aggressiv zu sein (schon mein bisheriger Versuch mit sigma=0.6 liegt ja nach SSIM deutlich unter 90%). Mit Aikoushas Parameterliste ist dfttest übrigens wesentlich schneller als bei Verwendung seiner Defaultwerte - es wird kein Problem sein, den Test wie gewünscht durchzuführen.
Bei FFT3Dfilter wiederum erscheint mir ein sigma-Wert von 0.75 angesichts der bisherigen Ergebnisse eher zu vorsichtig, das dürfte dann bei der Dateigröße gegen MVDegrain2 oder gar MVDegrain3 keine Chance haben.

Ganz allgemein frage ich mich inzwischen, inwiefern Filter und Codec inhaltlich zusammenarbeiten könnten. Wäre es denkbar, einen Filter speziell so auszulegen, dass er einem anschließenden XviD-Lauf (ggf. mit bekannten Parametern, Encoding-Matrix etc.) die Arbeit maximal erleichtern könnte (weil er weiß, mir welcher Art von Problemsituationen der Codec wie gut fertig wird)? Denn gerade das ist es, was meinen "Test" von denjenigen Tests unterscheidet, die ich bisher gelesen habe: Ich weiß sehr viel über mein späteres Zielformat und will möglichst viel von diesem Wissen bei der Wahl der Filter-Parameter nutzen.
User avatar
Devil Doll
Kámi-sama
Kámi-sama
Posts: 584
Joined: 30.12.2007 00:18
Gruppe: Devil Doll
Contact:

Re: Versuchsanordnung für Vergleichstest (Komprimierbarkeit)

Post by Devil Doll »

Das von Vidom vorgeschlagene Experiment mit den Farbkanälen bei FFT3Dfilter bringt gemäß meinem Versuchsaufbau erstaunlicherweise keine messbare Verbesserung (bei "sigma=1.0" entstehen 89.98% SSIM bei 212.504.790 Bytes Dateigröße, das ist fast identisch zu "sigma=1.1" ohne "plane=4"), obwohl es in der Tat über 200% an zusätzlicher Rechenleistung gefressen hat.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Die Ergebnisse der Filter-Einstellungen mit den von Aikousha in Posting 3541 vorgeschlagenen Parametern lassen MVDegrain2 weiterhin besser aussehen als die beiden anderen 3D-Filter: Bei sehr ähnlichen SSIM-Werten für alle drei Versuche wird das XviD-Encoding nach dem MVDegrain2-Filter deutlich am kleinsten, und das noch dazu nach der kürzesten Laufzeit aller drei Filter.

Bei der Laufzeit wäre noch Luft nach oben, wir könnten also auch mal einen temporalen Radius von 3 versuchen. dfttest bleibt allerdings mit 4:15 Stunden Laufzeit der langsamste der drei Filter (und das trotz Nutzung beider CPU-Kerne!), während FFT3Dfilter für seine Aufgabe 2:35 Stunden benötigt und MVDegrain in gerade mal 2:05 Stunden die deutlich größte Einsparung erreicht.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Gerade eben habe ich einen "Filter" gefunden, der geradezu erschreckend gut funktioniert. Er heißt: Gar nicht filtern, einfach mit XviD-2pass auf eine Dateigröße zielen! Der SSIM-Wert eines solchen Encodings spielt in der Spitzengruppe mit, und dass die Laufzeit unschlagbar niedrig ausfallen muss (der zusätzliche erste "Pass" kostet bei mir 11 Minuten), versteht sich von selbst. Der einzige Filter, der diese XviD-Komprimierung in Sachen "Rentabilität" noch überbieten kann, ist MVDegrain2/3, bei gleichem SSIM-Wert von 89.99% mit immerhin 5 MB weniger an Dateigröße.
Der Verzicht auf P-Frames mit einem Quant von 1 scheint in diesem Fall übrigens nicht zu schaden - im Gegenteil: Die gleich große Datei mit Verwendung solcher Frames hat sogar einen schlechteren SSIM-Wert.
Post Reply

Who is online

Users browsing this forum: No registered users and 22 guests