Beiträge von Archimedes1

Ich bin jetzt einfach zu faul, zum Suchen. In AviSynth gibt es doch die Möglichkeit, nach Herzenslust zu filtern. Könnte man AviSynth nicht auch für die Bildbearbeitung, z. B. zum Verkleinern, Nachschärfen und Entrauschen von Bildern aus der Digitalkamera, verwenden? Ich hätte da nämlich so eine Idee.

Benötigt wird:

- AviSynth+
- Fritz Photo 2020.07.08 (Vorlagen vom: 08.07.2020)

Um in den Genuss weiterer Grafikformate zu kommen, sollte man nach der Installation noch die beiden folgenden benutzerspezifischen Umgebungsvariablen erstellen:

- MAGICK_HOME = <Fritz-Photo-Programmverzeichnis>\dll\ImageMagick

- MAGICK_CODER_MODULE_PATH = <Fritz-Photo-Programmverzeichnis>\dll\ImageMagick

Diese werden von Immaavs, einem auf ImageMagick basierenden Plugin, benötigt. Damit lassen sich zahlreiche weitere Grafikformate einlesen und erstellen.

1. Bilder

Es werden die Formate BMP, JPG, PNG, PPM, TGA und TIF unterstützt, je nach Fähigkeiten des verwendeten AviSynth-Filters zum Einlesen von Bildern. Über "Start-Skript..." kann ein anderes Skript zum Einlesen von Bildern ausgewählt werden. Zur Auswahl stehen: ImageSource und ImmaRead.

2. Zuschneiden

Vor der eigentlichen Bildbearbeitung kann ein Bild noch gedreht und beschnitten werden.

3. AviSynth-Skripte

Im Vorlagenverzeichnis befinden sich bereits einige Skripte. Diese können mit Hilfe der Jobliste individuell zusammengestellt und abgeändert werden. Zum Hinzufügen und Entfernen eines Skripts genügt ein Doppelklick auf das jeweilige Skript (Drag and Drop wird ebenfalls unterstützt). Die wichtigsten Parameter sind in einem Block am Anfang des jeweiligen Skripts zusammengefasst. Diese Parameter können entweder direkt im Skript oder mit Hilfe des Skriptinspektors bearbeitet werden. Mit "Hinzufügen..." lassen sich Skripte auch außerhalb des Vorlagenverzeichnisses hinzufügen. Mit "Neu" können alle Einträge in der Jobliste entfernt und eine neue Auswahl gestartet werden. Mit "Erneut laden" kann ein vorher ausgewähltes Skript erneut eingelesen werden.

4. Vorschau

In der Vorschau kann man "Vorher" mit "Nachher" vergleichen. Durch Drücken von "Aktualisieren" wird die Vorschau gestartet. Mit den Cursor-Tasten kann man dabei bequem zwischen den Ansichten hin- und herschalten. Es wird dasjenige Bild angezeigt, welches unter "Bilder" ausgewählt ist. Ist kein Bild ausgewählt, wird standardmäßig das erste Bild aus der Liste genommen. Wenn man unter "AviSynth-Skripte" ein Skript in der Jobliste ausgewählt hat, dann kann man genau von diesem Filter einen Vorher-Nachher-Vergleich machen. Ist kein Skript ausgewählt, so erscheint in der Vorschau das Originalbild und das endgültige Bild (alle Skripte werden abgearbeitet). Durch einen rechten Mausklick kann ein Vorschaufenster auch einzeln aktualisiert werden. Der Schalter "Synchronisiere Vorschaufenster" sorgt dafür, dass die beiden Vorschaufenster "Vorher" und "Nachher" stets den gleichen Bildausschnitt zeigen (sofern möglich).

5. Einstellungen

Beim JPG-Format kann man zwischen einer festen und einer variablen JPG-Qualität wählen. Im letzten Fall gibt man einfach eine Dateigröße an, die nicht überschritten werden darf. Das Programm ermittelt dann die maximal mögliche JPG-Qualität. Mit Suchen und Ersetzen kann man den Dateinamen den eigenen Bedürfnissen anpassen. Es können hierbei sogar reguläre Ausdrücke verwendet werden. Falls "Suffix" aktiviert ist, dann haben die Ausgabedateien die folgende Form: <Originaldateiname>_<Breite>x<Höhe>.<ext>. Ist "Suffix" deaktiviert, dann ändert sich der Dateiname nicht. Wenn kein Zielverzeichnis angegeben wird, werden die Dateien in das gleiche Verzeichnis geschrieben, wo sich die Originaldateien befinden. Die Einstellungen, die beim Start des Programms Gültigkeit haben sollen, können in einer INI-Datei bearbeitet werden.

Wie erstelle ich ein Fritz-Photo-Script?

Ein Fritz-Photo-Script ist nichts anderes als ein strukturiertes AviSynth-Script mit zusätzlichen Kommentaren versehen. In diesen zusätzlichen Kommentaren sind Anweisungen für den Scriptinspektor enthalten. Ein jedes Script unterstützt dabei die folgenden Formate: YV12, YV24 und RGB32. Am Beispiel des Rotate-Scripts sei die Struktur eines Fritz-Photo-Scripts kurz erläutert.

# ==============================================================================
# http://avisynth.org.ru/rotate/rotate.html
# ==============================================================================
angle  = 0.0
color  = 0
width  = 0
height = 0
# ==============================================================================
# angle  = True, False, Beginner, Rotation angle in degrees clock wise | float
# color  = True, False, Intermediate, Ellipsis, ColorDialog, Background color of part of image | int
# width  = True, False, Intermediate, Width of the destination output image | int
# height = True, False, Intermediate, Height of the destination output image | int
# ==============================================================================

LoadPlugin("plugins\Rotate\Rotate.dll")

isYV12() ? YV12ToYV24() : isYV24() ? NOP() : NOP()

Rotate(angle=angle, color=color, width=width, height=height)

Ein Fritz-Photo-Script lässt sich in 4 Bereiche unterteilen.

- Info über das Plugin

- Parameter

- Parameter für den Scriptinspektor

- Das eigentliche Script

Der erste Bereich ist der sog. Info-Bereich. Hier kann man in einer oder mehreren Zeilen etwas zum Plugin schreiben. In der Regel steht hier einfach ein Link zur entsprechenden Homepage des Plugins.

Der zweite Bereich umfasst die Parameter, die im Script Verwendung finden. Die hier niedergeschriebenen Parameter werden auch im Scriptinspektor angezeigt.

Im dritten Bereich kann man für die einzelnen Parameter Eigenschaftswerte für den Scriptinspektor hinterlegen, und zwar in der folgenden Bedeutung: „Sichtbarkeit, Nur-Lesen-Modus, Ballonhilfe für den Parameter | Ballonhilfe für den Wert“. Auch eine Liste mit vordefinierten Werten lässt sich erzeugen (siehe z. B. SSSharp.avs). Wenn keine Eigenschaftswerte für einen Parameter festgelegt sind, dann wird der Parameter mit den Werten „True, False, Beginner“ belegt.

Im vierten und letzten Bereich befindet sich das eigentliche Script. Es beginnt mit der LoadPlugin- und der Import-Sektion. Im Anschluss wird nach dem Farbformat gefragt, also, ob es sich um das YV12-, YV24- oder um das RGB32-Farbformat handelt. Je nachdem, was das Script bzw. Plugin für eine Farbe benötigt, erfolgt eine entsprechende Umwandlung. Im Beispiel von oben kann das Farbformat entweder YV24 oder RGB32 sein. Liegt dieses bereits vor, so muss auch nichts umgewandelt werden.

Wenn man nun ein Script für das Farbformat YV12 schreiben will, so bedient man sich am Besten eines der Vorlagen, die dem zukünftigen Script am nächsten kommt. Im Falle von YV12 bedient man sich am Besten des Scripts „TNLMeans.avs“ und passt das Script entsprechend an. Für ein reines RGB32-Script kann als Arbeitsgrundlage das Script „RGBAdjust.avs“ hergenommen werden.

Hier ist ja eigentlich noch was offen. Ich bin in letzter Zeit gar nicht mehr dazu gekommen, der Frage des Threadtitels nachzugehen. Werde wohl auch in nächster Zeit nicht dazu kommen. Ich erlaube mir, ein wenig zu spekulieren.

Eines ist mir auf die Schnelle aber schon klar geworden, wenn man nur die reinen Zahlenwerte (ohne Einbezugnahme des Kurvenverlaufs) hernehmen würde, dann würde man auf’s Glatteis geführt werden. Vermeintlich bessere Durchschnittswerte bei den Transcoder-Ergebnissen würden über die Tatsache hinwegtäuschen, dass es ab einem gewissen Komprimierungsgrad in schnellen und komplexen Szenen (z. B. „Formel-1-Szene“ bei den VQEG-Sequenzen) zu sehr starken Einbrüchen kommt, die man auch im laufenden Video als solche zu sehen bekommt. Bei den weniger komprimierten Videos ist davon noch nichts zu sehen, erst ab einem gewissen Komprimierungsgrad wird das System „Transcoder“ „instabil“ (die Ausreißer nehmen in ihrer Heftigkeit zu).

Wenn man aber den Kurvenverlauf miteinbezieht, so bin ich durchaus der Meinung, dass das System „SSIM“ – bei all den möglichen Gefahren - soweit funktioniert. Es gibt da nämlich so eine Grenze, wo ich nur anhand der Grafiken zwischen Gut und Böse unterscheiden würde – nämlich da, wo die Ausreißer in komplexen Szenen beginnen, zu „entarten“ (starke Ausschläge nach unten). Wobei der stichpunktartige Test, inwieweit SSIM-Werte für einzelne Transcoder-Frames überhaupt mit den subjektiven Eindrücken übereinstimmen, ja auch noch gemacht werden müsste (Fixationspunkte, Fehler auf Blockebene etc.).

Zitat von Kika

Nun, warum ch SSIM nicht traue:
SSIM unterschlägt Fehler, die beim Transcoden entstehen. Das deshalb, weil sie nur einzelen Blocks, Macroblocks oder bestenfalls Slices betreffen (bei MPEG2). Dummerweise kann man solche Fehler aber SEHEN.

Ich lasse mir jetzt auch die kleinsten lokalen SSIM-Werte je Frame ausgeben, um eben auch Problemen in den Blöcken auf die Spur zu kommen. Die Ausgabe erfolgt dann auch mit Angabe der Koordinaten des betreffenden lokalen SSIM-Fensters. Zunächst dachte ich mir noch, dass das nichts bringen würde, da vermutlich in jedem Frame immer auch sehr niedrige lokale Werte vorkommen. Dem ist aber nicht so, wie ich in einem ersten Test festgestellt habe. Es ergaben sich eine überschaubare und damit sinnvoll überprüfbare Anzahl von fragwürdigen Frames.

Ich habe dann eine Analyse der VQEG-Videos mit 85 % Komprimierung vorgenommen. Interessanterweise hat hier Nero Recode die mit Abstand kleinsten Werte aufzuweisen (z. B. 0,0235). Das Procoder-Express-Video hat diesbezüglich keine so großen Ausreißer (der kleinste Wert lag bei 0,2304).

Auf Blockebene, vermutlich aber auch in größeren Bereichen, scheint Nero Recode da wirklich öfter mal etwas (kräftig) zu verhunzen. Ob und wie sich diese Ausreißer negativ bemerkbar machen, muss erst durch eine Sichtkontrolle überprüft werden.

Zitat von Check It Out

Etwas problematisch finde ich den Ausgangsansatz, ein ProCoder Express Video zu verkleinern - und zwar erneut mit dem ProCoder Express. Evtl. erleichtert das dem ProCoder Express die Arbeit durch gleichlaufende Routinen, zB minimale Vorfilterungen.
Neutraleres Mpeg-Material wäre gerechter. Bestimmt gibt es da auch Referenzmaterial.

Der Gedanke ging mir anfangs auch schon durch den Kopf.
Aber soweit ich das gesehen habe, profitiert der Canopus Procoder Express nicht wirklich davon. Auch ging es mir hier nicht primär um den "knallharten Vergleich" zwischen den beiden Varianten. Dazu müssen sowieso mehrere (unterschiedliche) Referenzclips getestet werden.

Ich habe in der Zwischenzeit auch noch eine Testreihe mit den VQEG-Sequenzen durchgeführt. Dazu habe ich das Mpeg-2-Video, dass mit dem “Spezialencoder“ enkodiert wurde, wieder in 5-er Schritten (95, 90, 85% usw.) komprimieren lassen. Dazu aber ein anderes Mal mehr.

Wie’s der Zufall so will, bin ich dabei auf eine Szene gestoßen, die das Thema „Fixationspunkte“ sehr gut veranschaulicht. Als Demonstration habe ich aus den 75-%-Videos mal den Frame 742 herausgepickt. In beiden Fällen handelt es sich um ein B-Frame. Leider ging die Erstellung der Animationen nicht ohne sichtbare (Farb-)Verluste einher. Deswegen mögen die folgenden Grafiken auch nur als grobe Anhaltspunkte dienen.

Der Frame für das Nero-Recode-Video hatte einen sehr schlechten Wert von 0,8171 (Q in Y).

[Blockierte Grafik: http://img244.imageshack.us/img244/5208/ne…rame0742rg5.gif]

Der Frame für das Procoder-Express-Video hatte dagegen einen Wert von 0,9412.

[Blockierte Grafik: http://img373.imageshack.us/img373/6916/pr…75frame0eq6.gif]

Bei der Betrachtung dieses Frames relativiert sich der schlechte Werte von Nero Recode ein wenig. Die (möglichen) Fixationspunkte liegen ja irgendwo am Formel-1-Rennwagen (Helm des Fahrers, Kanten, Schriftzüge etc.) und nicht im Hintergrund. Und gerade dieses „Drumherum“ sieht beim Nero-Recode-Frame sehr übel aus. Die Unterschiede am Rennwagen sind dagegen wesentlich geringer. In einem laufenden Video wird man den schlechten „Kontext“ des Nero-Recode-Videos gar nicht (so) mitbekommen, erstens, wegen der Fixationspunkte und, zweitens, wegen dem sich stark bewegenden Hintergrund.

Das Thema „Fixationspunkte“ ist ja durchaus nicht uninteressant. Aber ich würde jetzt mal (ganz frech) behaupten, dass es letztendlich keine große Rolle spielt, ob die SSIM-Werte in so einem Bereich höher bewertet werden oder nicht. Laut dem Entwickler der SSIM-Metrik würden z. B. auch zufällig erzeugte lokale SSIM-Fenster („Sliding Windows“) ebenfalls brauchbare Ergebnisse liefern (der Vorschlag wurde aus Performancegründen gebracht). In Tests wurde gezeigt, dass hierzu nicht mehr als 100 „Sliding Windows“ nötig sind! Ich behaupte ferner, dass, wenn man nur einen Teil des Bildschirms, z. B. die Hälfte oder ein Drittel davon, analysiert, dass dann die Ergebnisse genauso brauchbar sind („wie im Großen, so im Kleinen“). Insofern könnte es durchaus sein, dass eine Hinzunahme der Fixationspunkte – die ja im Endeffekt nichts anderes als gewichtete lokale SSIM-Fenster sind - keine wirkliche Verbesserung bringen würde.

Zitat von Kopernikus

Archimedes: In welcher Programmiersprache hast du denn dein SSIM Implementiert?

Denn falls du mit C Code was anfangen kannst, hätte ich hier einige Routinen, die versuchen die Fixation zu modellieren. Dann könnte man versuchen SSIM ein bisschen zu "tunen".

Das Programm habe ich mit Borland Delphi erstellt. C-Quellcode stellt aber kein Problem dar.

Die ganze Thematik erscheint mir dann doch etwas „vage“. Hängt da nicht viel zu viel vom „Auge des Betrachters“ ab (Alter, Geschlecht etc.)? Auch stellt sich mir die Frage nach der Performance einer solchen Implementierung. Ein interessanter Ansatz ist es aber durchaus.

Zitat von Kika

SSIM unterschlägt Fehler, die beim Transcoden entstehen. Das deshalb, weil sie nur einzelen Blocks, Macroblocks oder bestenfalls Slices betreffen (bei MPEG2). Dummerweise kann man solche Fehler aber SEHEN.

Bei der SSIM-Variante für Video haben wir es mit 8x8 Pixel großen „Sliding Windows“ zu tun, damit sollten Fehler in den Blöcken zu mindestens erfasst werden. Bei einem 720x576 großen Frame ergeben sich damit 405697 lokale SSIM-Werte. Wenn nun nur ein paar davon sehr schlecht aussehen, die anderen dagegegen sehr gut, wird das für den durchschnittlichen SSIM-Wert kaum Auswirkung haben. Stimmt.

Dann wäre es doch sinnvoll, neben dem Durchschnittswert auch den oder die kleinsten lokalen SSIM-Werte pro Frame ausgeben zu lassen (evtl. mit Koordinaten)? Auf diese Weise würde man sehen, wo in einem Frame evtl. größere Probleme in kleineren Bereichen auftreten.

Zitat von Kika

Ein Beispiel: Ein Transcoder entscheidet, dass eine große Fläche, die ein Drittel des Bildes einnimmt, ruhig stärker komprimiert werden kann(wobei sie versaubeutelt wird), während der Encoder aber das geamte Bild verändert - nur, was empfindet man auf psychovisueller Ebene als besser? SSIM mit Sicherheit den Transcoder, Menschen aber den Encoder.

Das Beispiel leuchtet mir durchaus ein. Hier kommt etwas ins Spiel, dass eine SSIM-Analyse durchaus „ad absurdum“ führen kann. Aber auch hier geht es wieder um die Verteilung der lokalen SSIM-Werte (nur in einem größeren Zusammenhang). Aber ist das nicht auch wieder ein konstruiertes Beispiel? Arbeiten Transcoder wirklich so? Wenn solche Dinge tatsächlich vermehrt auftreten sollten, dann lassen sich diese doch bestimmt vermehrt an Framebeispielen aufzeigen.

Mal eine Zwischenfrage an die Runde, welche Bereiche auf dem Bildschirm nimmt das Auge eigentlich am intensivsten wahr? Gibt es so was, wie einen goldenen Schnitt? Randbereiche werden sicherlich weniger kritisch betrachtet. Eventuell könnte man auch eine regionale Gewichtung der lokalen SSIM-Werte berücksichtigen. Alternativ könnte man mit der Crop-Funktion von AviSynth auch ein kleineres Analysefenster wählen.

Ich habe mir die Kurvenverläufe der einzelnen Videos jetzt mal näher angeschaut. Es bestätigt sich, irgendwo bei 85 % Komprimierung würde ich anfangen, darüber nachzudenken, ob die Encoder-Version, trotz des niedrigeren durchschnittlichen SSIM-Wertes, nicht doch vorzuziehen ist. Wohlgemerkt, beim vorliegenden Video.

Ich mache das hauptsächlich an der „Wasserspringbrunnenszene“ abhängig (bei etwa 85 % Komprimierung beginnt sich die Szene zunehmend zu verschlechtern).

[Blockierte Grafik: http://img247.imageshack.us/img247/6703/derzoobesuch85frame1097by5.jpg]

Hinzu kommt, dass die Procoder-Express-Linie in den meisten anderen Frames auch einen lineareren Verlauf hat (was auch immer das im laufenden Video zu bedeuten hat). Eventuell mache ich auch noch einen Test mit den VQEG-Sequenzen, um die Sache bei Szenen mit viel Bewegung zu untersuchen. Das scheint sich schon mal als ein limitierender Faktor beim Transcoden herauszustellen (trotz hoher durchschnittlicher SSIM-Werte).

Das ist jetzt nur mal ein „Herantasten“, alleinig durch eine SSIM-Analyse. Ob diese Eindrücke Bestand haben, muss erst eine Sichtkontrolle zu Tage fördern.

Zitat von Check It Out

Archimedes1, Recode arbeitet ohne Eingriff in die Registry standardmäßig mit Qualität "sharp", insofern ist klar, warum sich die Kurven fast gleichen. Fast gleichen bedeutet aber auch, dass Änderungen durchgeführt wurden. Zu ermitteln war/ist, ob es eventuell weniger Ausreißer nach unten gibt. Wie stellen sich denn die Minimalwerte der einzelnen Metriken dar?

Die oben gezeigte Grafik ist durchaus repräsentativ. Mehr Unterschiede sind da nicht auszumachen. Einzige Ausnahme ist der „ausklingende Framebereich“ von 1474 bis 1499 – dort laufen die Kurven etwas auseinander.

[Blockierte Grafik: http://img165.imageshack.us/img165/1677/derzoobesuch60frame1384ao0.jpg]

Die Zahlenwerte waren dann auch fast gleich. Ich habe die Analyse allerdings ohne die schwarzen Ränder, also mit Crop(16, 16, -16, -16) durchgeführt, deswegen sind die von dir ermittelten Werte vermutlich auch größer. Meine Analyse ergab folgende Zahlenwerte:

Nero Recode 2 (Version 2.2.6.17):

Zitat

PSNR in Y: 34,5164 dB
MSE in Y: 22,9849
MSE in U: 0,9914
MSE in V: 0,6589
Euklidischer Abstand in Y: 2,9823
Euklidischer Abstand in U: 0,5103
Euklidischer Abstand in V: 0,3508
Euklidischer Abstand in YUV: 3,2806

Q in Y: 0,9535
SSIM in Y: 0,9556

Kleinstes Q in Y: 0,8105 (1134)
Größtes Q in Y: 0,994 (100)

Alles anzeigen

Nero Recode 2 (“sharp”):

Zitat

PSNR in Y: 34,5104 dB
MSE in Y: 23,0166
MSE in U: 1,0065
MSE in V: 0,6739
Euklidischer Abstand in Y: 2,9845
Euklidischer Abstand in U: 0,5161
Euklidischer Abstand in V: 0,3563
Euklidischer Abstand in YUV: 3,2877

Q in Y: 0,9536
SSIM in Y: 0,9557

Kleinstes Q in Y: 0,8106 (1134)
Größtes Q in Y: 0,9947 (1474)

Alles anzeigen

Ich bin jetzt noch nicht dazu gekommen, alle Videos zu begutachten. Aufgefallen ist mir jedoch, dass die „Wasserspringbrunnenszene“ bei den Nero-Recode-Videos mitunter sehr übel aussieht. Irgendwo unterhalb von ca. 90 % Komprimierung geht die Qualität, was diesen Framebereich betrifft, schlagartig in den Keller. Die Procoder-Express-Videos sind zwar auch voll von Verblockungen, sehen aber bei weitem nicht so schlimm aus. Vielleicht auch ein Hinweis darauf, wo die Grenzen eines Transcoders liegen.

[Blockierte Grafik: http://img47.imageshack.us/img47/6145/derzoobesuch60frame1097gp0.jpg]

Die Frage ist halt, wie sensitiv man solche Stellen aufnimmt bzw. wie wichtig einem solche Stellen sind. Ob die laut SSIM-Kurve besseren Stellen diesen „Ausreißer“ wettmachen, müsste man erst durch eine Sichtkontrolle überprüfen. Denn, was habe ich von hohen SSIM-Werten in den meisten anderen Framebereichen, wenn ich diese auf einem Sichtgerät gar nicht „wahrnehme“, und eine einzige Szene „versaut“ den ganzen Eindruck?

Zitat von Kika

Der SSIM-Wert kann mir doch gar nicht sagen, ob Ergebnis A besser ist als Ergebnis B. Über das Warum wurde ja schon hinreichend diskutiert.

Sagen wir mal so, der SSIM-Wert gibt Auskunft darüber, inwieweit das Ergebnis A (subjektiv) besser mit einem Referenzsignal übereinstimmt als Ergebnis B. Ob man dieses „Maß an Übereinstimmung“ als „besser“ ansieht, bleibt jedem selbst überlassen.

Ich weiß, der Vergleich hinkt, aber genauso gut könnte ich zu meinem Hausarzt bei der nächsten Blutuntersuchung sagen, was jucken mich die Zahlen, das Einzige, was zählt, ist meine subjektive Befindlichkeit.

Dort ist die Sache doch ähnlich. Blutwerte sagen zwar viel aus, aber eben nicht alles. Auch können sie mal daneben liegen. Liegen Werte im Grenzbereich (siehe Ausreißer bei den SSIM-Werten), wird der Sache einfach nachgegangen (erneute Untersuchung etc.).

Zitat von Kika

Wenn solche Messergebnisse Sinn haben sollen, dann müssen sie innerhalb einer Gruppe gleich arbeitender Programme ermittelt worden sein. Also nur Transcoder oder nur Encoder.

Das höre ich auch immer wieder. Aber noch niemand hat mir das durch ein Beispiel belegen können. Und gerade solche Beispiele interessieren mich, um eben die Grenzen einer SSIM-Analyse – ja, die gibt es! - mal sichtbar zu machen. Und ich meine jetzt nicht irgendwelche konstruierte Beispiele (z. B. ein schwarzes Loch in der Mitte eines Videos).

Vielleicht liegt die „überkritische Haltung“ gegenüber solchen Analysen auch daran, dass SSIM-Werte häufig einfach falsch interpretiert werden. Wenn ich z. B. irgendwo einen sog. Codec-Test lese, wo tabellarisch die SSIM-Werte aufgelistet sind und daraus sogar eine Rangfolge ermittelt wird, sträuben sich mir die Haare. Ich weiß häufig gar nichts über die Referenzvideos (Auswahl der Szenen, Art der Szenen etc.), noch über die Einstellungen der Encoder, noch weiß ich etwas über den Kurvenverlauf. Wenn, dann müsste man, ähnlich wie bei Computerschachprogrammen, eine sog. Ratingliste führen, wo eine Vielzahl von ausgewählten Clips analysiert werden. Auf diese Weise hätten die Zahlen eine größere Aussagekraft. Zusätzlich würde ich die ermittelten Ergebnisse (die Unterschiede in den SSIM-Werten) auch noch auf ihre „Wirksamkeit“ hin überprüfen (Sichttests) und aus all dem dann eine Synthese bilden.

Ich habe mir die 4 Clips der aktuellen Nero-Recode-Version jetzt mal näher angeschaut und mit dem Clip der älteren Version 2.2.6.17 verglichen. Die Komprimierung war ja auf 60 % eingestellt. Die Einstellungen „smooth“, „max smooth“ und „sharp“ erzeugen fast die gleichen Kurven wie die ältere Nero-Recode-Version. Speziell die Einstellung „sharp“ erzeugt eine fast deckungsgleiche Kurve. Einen Sichtungstest habe mir erspart.

[Blockierte Grafik: http://img409.imageshack.us/img409/6/derzoobesuch60frame0947zm0.jpg]

So viel scheint sich da wohl doch nicht getan zu haben.

Die Einstellung „max sharp“ erzeugt zwar die besten SSIM-Werte, aber auch die größeren Ausreißer, auch ist die Kurve alles andere als „ruhig“. Das müsste man getrennt betrachten.

Danke dir. Habe mir die Clips soeben heruntergeladen. Interessanterweise hat die 2. Variante („max smooth“) den größten PSNR-Wert. Hier können wir einen Widerspruch zu den SSIM-Werten erkennen (die 2. Variante hat nicht den größten SSIM-Wert). Bis jetzt dachte ich eigentlich immer, der PSNR-Wert steigt und fällt reziprok auch mit dem euklidischen Abstand. Ist aber nicht so.

Derweil kann ich ja mal - zur allgemeinen Diskussion - die Ergebnisse der SSIM-Analyse für die 95 % Komprimierung veröffentlichen, zunächst einmal ohne Interpretation der Werte. Das sollte den subjektiv noch zu gewinnenden Eindrücken keinen Abbruch tun.

Nero Recode 2 (95 % Komprimierung):

Zitat

PSNR in Y: 43,531 dB
MSE in Y: 2,8839
MSE in U: 0,0491
MSE in V: 0,0369
Euklidischer Abstand in Y: 0,2839
Euklidischer Abstand in U: 0,0183
Euklidischer Abstand in V: 0,0113
Euklidischer Abstand in YUV: 0,2956

Q in Y: 0,9952
SSIM in Y: 0,9957

Kleinstes Q in Y: 0,9693 (1134)
Größtes Q in Y: 1 (42)

Alles anzeigen

Procoder Express (95 % Komprimierung):

Zitat

PSNR in Y: 39,5872 dB
MSE in Y: 7,1509
MSE in U: 0,2865
MSE in V: 0,2023
Euklidischer Abstand in Y: 1,5006
Euklidischer Abstand in U: 0,2161
Euklidischer Abstand in V: 0,1581
Euklidischer Abstand in YUV: 1,6592

Q in Y: 0,9829
SSIM in Y: 0,9837

Kleinstes Q in Y: 0,9196 (1137)
Größtes Q in Y: 0,9986 (809)

Alles anzeigen

Die etwas auffälligeren Kurvenverläufe seien hier schon mal gezeigt.

[Blockierte Grafik: http://img100.imageshack.us/img100/990/derzoobesuch95frame0150xj8.jpg]

[Blockierte Grafik: http://img242.imageshack.us/img242/4213/derzoobesuch95frame0408rs1.jpg]

[Blockierte Grafik: http://img171.imageshack.us/img171/791/derzoobesuch95frame0672ey5.jpg]

[Blockierte Grafik: http://img243.imageshack.us/img243/3393/derzoobesuch95frame0822si8.jpg]

[Blockierte Grafik: http://img174.imageshack.us/img174/2757/derzoobesuch95frame0947ot0.jpg]

Im nachfolgenden Framebereich habe ich die Y-Skalierung geändert.

[Blockierte Grafik: http://img155.imageshack.us/img155/4983/derzoobesuch95frame1097ti3.jpg]

[Blockierte Grafik: http://img124.imageshack.us/img124/9546/derzoobesuch95frame1147em7.jpg]

[Blockierte Grafik: http://img242.imageshack.us/img242/6736/derzoobesuch95frame1222av6.jpg]

[Blockierte Grafik: http://img142.imageshack.us/img142/3899/derzoobesuch95frame1384nk3.jpg]

Es gilt nun herauszufinden, ob die ermittelten SSIM-Werte auch tatsächlich mit den subjektiven Eindrücken übereinstimmen. Da man ja nicht alle Frames per Einzelbildvergleich sichten möchte, muss das halt stichprobenartig verifiziert werden. Falls jemand irgendeinen (aussagekräftigen) Frame entdeckt, der nachweislich nicht mit dem dazugehörigen SSIM-Wert übereinstimmt, der möge diesen bitte melden! Eventuell scheiden sich auch hier schon die Geister.

Verläuft der Stichprobentest soweit erfolgreich, gilt es zu testen, inwieweit die Ausreißer in den Grafiken sich auch in einem laufenden Video erkennbar machen. Schließlich geht es ja auch um die „richtige Interpretation“ der Werte. Mit Sicherheit werden kleinere Ausreißer bei Szenen mit viel Bewegung relativiert usw.

Zitat von max

Archimedes

darf ich dein Testfile mal durch den großen Procoder jagen ?

Na klar!

Ja, die Nero-Recode-Version ist relativ alt. Diese stammt noch aus der 6-er Version von Nero, die ich (ganz bewusst) nicht mehr auf die 7-er Version „geupdatet“ habe. Ich denke aber, dass die Version gut genug ist, um unserer Frage nach der Sinnhaftigkeit einer SSIM-Analyse nachzugehen.

Ich habe jetzt mal eine Testreihe mit meinem einminütigen Zooclip (DV-Video) gemacht. Dazu habe ich zunächst mit dem Procoder Express das Referenzvideo erstellt. Das DV-Video wurde dabei mit variabler Bitrate (3500/6500/8500) und in zwei Durchgängen enkodiert.

Dieses Referenzvideo wurde nun mit Nero Recode 2 und dem Procoder Express auf unterschiedliche Komprimierungsgrade gebracht (95, 90, 85, 80, 75, 70, 65 und 60 %). Die jeweiligen Dateien waren dann auch ziemlich gleich groß. Zu den metrischen Analysen kommen wir später.

Fangen wir mal ganz homöopathisch an, bei 95 % Komprimierung.

Original:
http://rapidshare.com/files/11300503…rozent.zip.html

Nero Recode 2 (95 % Komprimierung):
http://rapidshare.com/files/11357114…rozent.zip.html

Procoder Express (95 % Komprimierung):
http://rapidshare.com/files/11428727…rozent.zip.html

Welche Version gefällt besser?

Check It Out: Wäre es dir möglich, vom obigen Referenzvideo mit der aktuellen Nero-Recode-Version eine Variante mit 60 % Komprimierung anzufertigen. So hätte ich schon mal eine ungefähre Ahnung davon, wie sich die Versionen unterscheiden.

Was soll dieses "quality=4" eigentlich bewirken? Mastering Quality? Ich habe das mal mit den History-Settings versucht, mit dem Ergebnis, dass der Procoder Express solche Einstellungen einfach ignoriert. :motz:

Zitat von Check It Out

Welche Recode-Version hast Du eigentlich genau benutzt und mit welchen Einstellungen (2pass, High Quality?).

Ich habe die Version 2.2.6.17 von Nero Recode 2 verwendet. Einstellungsmöglichkeiten gab es nicht allzu viele. Ich habe „Erweiterte Analyse“ und „High Quality Modus“ eingestellt.

Zitat von Kopernikus

Die verwendete SSIM Implementierung folgt nicht dem Paper (kein 11x11 Gauss-Gewichtungsfenster, Lumimasking weiß ich nicht), somit sind die Ergebnisse nur mit Vorsicht übertragbar (zumindest die zweite Nachkommastelle ist fragwürdig).

Wir sprechen hier nicht über das AviSynth-Plugin, sondern über eine eigene Implementierung.

Das mit der Gauss’schen Gewichtung innerhalb eines 11x11 großen „Sliding Windows“ wurde ja deswegen vorgeschlagen, um „Verblockungen der SSIM-Fenster“ innerhalb eines Frames zu vermeiden. Die in den Artikeln vorgeschlagene SSIM-Variante bezog sich allerdings immer auf Einzelbildvergleiche! Für Videos wurde eine eigene (performantere) SSIM-Variante vorgeschlagen:

http://www.cns.nyu.edu/~zwang/files/papers/vssim.pdf

Daran dürfte sich auch der Entwickler des AviSynth-Plugins orientiert haben. Darin wurde die Gauss’sche Gewichtung jedenfalls nicht erwähnt. Es ist vielmehr die Rede davon, aus Performancegründen, den SSIM-Wert für ein Frame lediglich aus einer begrenzten Anzahl von „Sliding Windows“ (< 100) zu ermitteln. Diese „Sliding Windows“ sollen nach dem Zufallsprinzip erzeugt werden.

Das AviSynth-Plugin ist z. B. dem Vorschlag gefolgt, die SSIM-Werte auch für die Farbkanäle zu berechnen. In einer E-Mail teilte mir der Entwickler der SSIM-Metrik jedoch mit, dass er sich bezüglich der Farbkanäle alles andere als sicher ist. Getestet und für gut befunden wurde die SSIM-Metrik nur für den Y-Kanal, nicht jedoch für die Farbkanäle.

Zitat

…but the SSIM is not intended to apply for negative values (at least nobody has tested and studied)

Weiter schrieb er, dass er sich bezüglich der Farbkanäle auch nicht sicher sei, ob das „die korrekte“ Methode sei.

Auch im Artikel „Video Quality Assessment Based on Structural Distortion Measurement” (siehe Link) wird erwähnt, dass die Einschränkung auf den Y-Kanal keinerlei signifikante Einschränkungen bei den Tests zur Folge hatten.

Zitat

For example, setting the color weighting parameters WY to one and WCb and WCr to zero in (8) (in other words, only the luminance channel is used for video quality assessment) does not have significant effect on the overall performance of the algorithm on the VQEG dataset.

Das soll uns jetzt aber nicht daran hindern, die eine oder andere vorteilhafte Methode doch zu verwenden.

In meiner eigenen Implementierung bin ich ebenfalls dem obigen Artikel gefolgt, jedoch lasse ich den SSIM-Wert lediglich für den Y-Kanal berechnen. Auch wurde eine Gewichtung nach Bewegungsvektoren nicht vorgenommen. Die einfacheren Metriken berücksichtigen z. B. die Farbkanäle. Ich werde die Farbkanäle bei der SSIM-Berechnung vermutlich aber wieder berücksichtigen (und sei es nur zu Testzwecken).

Zitat von Kopernikus

Als Beispiel habe ich neulich mit einer qualitätsbasierten Rate Control für XviD experimentiert, die versucht einen konstanten SSIM Wert zu halten, und die Ergebnisse sahen z.T. furchtbar aus, weil wenige Blocks sehr schlecht waren, obwohl die SSIM Werte relativ hoch lagen.

Und genau solche Beispiele interessieren mich! Kann man das an einem Einzelbildvergleich demonstrieren? Eventuell ließe sich das auch durch den Verlauf der lokalen SSIM-Werte innerhalb eines Frames zeigen (schlechtester lokaler SSIM-Wert).

Über den Sinn und Unsinn einer SSIM-Analyse brauchen wir uns sicher nicht zu unterhalten. Es ist mittlerweile durchaus „erwiesen“, dass eine SSIM-Analyse bis zu einem bestimmten Grad in einem bestimmten Rahmen „funktioniert“. Da sie, wie andere Metriken auch, jedoch fehlbar ist - wie übrigens auch das eigene subjektive Sehvermögen -, bedarf es eben auch einer gewissen Nachkontrolle (ganz gleich, wie diese auch immer aussehen mag). Mir ist eine SSIM-Analyse z. B. sehr hilfreich, wenn es darum geht, mögliche Schwachstellen in einem Video zu erkennen. Dort, wo die SSIM-Werte nämlich stark in den Keller gehen, befinden sich in aller Regel auch immer problematische Frames. Diese gilt es dann zu prüfen, inwieweit sich diese in einem laufenden Video auch als solche zu erkennen geben.

Vielleicht wäre es mal interessant, das Ganze an einem Beispiel zu demonstrieren. Mich würden die einzelnen, sicher unterschiedlichen Meinungen durchaus interessieren.

Wenn eine SSIM-Analyse im Kontext „Transcoder versus Encoder“ nun wirklich nicht taugen soll („Äpfel-Birnen-Vergleich“), dann lässt sich das doch bestimmt anschaulich „beweisen“!?

Zitat von LigH

Da man hier mehr oder weniger Äpfel mit Äpfeln vergleicht ... kann ich daran nicht wirklich etwas kritisieren. Dennoch ist auch SSIM eine von vielen künstlichen Metriken, und die subjektive Empfindung ist das einzig wahre Kriterium.

Das ist sie eben nicht. Eine „einfache mathematische Formel“ mag zwar „künstlich“ sein, aber wenn sie, wie im vorliegenden Fall der SSIM-Metrik, durch eine Vielzahl von (wissenschaftlichen) Tests auf ihre Brauchbarkeit getestet und optmiert wurde und wird, dann ist sie in meinen Augen nicht mehr „nur künstlich“.

Wir dürfen natürlich nicht den Fehler begehen, und wie ein Gasmann einfach nur den Zähler ablesen und gut ist’s. Das kann eine einzelne SSIM-Analyse sicher nicht leisten. Die Zahlen wollen auch richtig interpretiert werden. Aber ich will mich hier nicht als „Verteidiger der Metriken“ aufspielen. Wenn, dann bin ich an der Anwendbarkeit interessiert, an den Fällen, wo eine Metrik eben nicht funktioniert etc. Ich bin dann auch immer dankbar, wenn mir jemand so einen Ausnahmefall schildert. In der Regel stehe ich solchen Analysen durchaus kritisch gegenüber. Erst durch eine Vielzahl von Analysen bekommt man ein Gefühl dafür. In der Mehrzahl der Fälle – richtige Interpretation vorausgesetzt -, stimmen die Werte zu mindestens mit meinen Sehgewohnheiten überein.

Im vorliegenden Fall (Transcoder versus Encoder) wäre das durchaus noch zu klären. Deswegen sollte dieser Thread ja auch als „Abgleich“ dienen.

Check It Out:
Zu deinen Fragen komme ich noch zurück.

Da es hier schon einmal Thema war, nagle ich das mal hier fest.

Bei diesem „Vergleich“ geht es mir in erster Linie darum, herauszufinden, ob eine SSIM-Analyse in solch einem Kontext überhaupt sinnvoll ist bzw. wie die Zahlen und Kurven – beides gilt es ja zu berücksichtigen! - hier zu interpretieren sind. Eventuell könnte man auch Versuche mit einer abgewandelten Form der SSIM-Metrik machen. Als weiteren „Nebeneffekt“ können wir uns auch gerne (noch mal) über das Thema „Transcoder versus Encoder“ im Allgemeinen unterhalten.

Ich habe dazu einen 1:35 Minuten langen Fernsehmitschnitt („9-Darter von Raymond van Barneveld“), der laut BitRate Viewer eine mittlere Bitrate von 5837 kbps aufzuweisen hat, auf etwa 68 % der Originalgröße verkleinern lassen. Einmal mit Nero Recode 2 und einmal mit dem Procoder Express. Die Dateigrößen waren dann auch annähernd identisch.

Gerade bei den von Requantisierern produzierten Videos fördern SSIM-Analysen ja stets sehr hohe Werte zutage. Das liegt, wie bereits bekannt, daran, dass bei der Requantisierung die Struktur als solche beibehalten wird (GOP, Frames, Bewegungsvektoren etc.). Je geringer die Kompression ist, desto mehr Frames ensprechen 1:1 den Originalframes. Dass eine metrische Analyse hier gute Werte liefert, liegt auf der Hand. Aber wie sieht es mit der Verteilung der Werte aus? Stimmen die Werte auch so gut mit den subjektiven Eindrücken überein, wie beim Vergleichen von Mpeg-2-Videos, die aus DV-Videos entstanden sind?

Aber schauen wir uns zunächst einmal die reinen Zahlenwerte der Analyse an. Der Wert „Q in Y“ ist, wie bereits bekannt, der gewichtete SSIM-Wert (dunkle Bereiche fließen weniger stark in die Bewertung mit ein, als helle Bereiche). Der Wert „SSIM in Y“ ist der ungewichtete SSIM-Wert (dunkle und helle Bereich fließen gleichermaßen stark in die Bewertung mit ein). Um auch eine einfache Metrik mit ins Spiel zu bringen, seien hier auch die euklidischen Abstände im YUV-Farbraum genannt. Diese Metrik hat in diesem Zusammenhang übrigens den gleichen Stellenwert wie PSNR und MSE. Irgendwie finde ich den euklidischen Abstand aber anschaulicher (durchschnittliche Entfernung eines Pixels vom Originalpixel im zwei- bzw. dreidimensionalen Raum).

Insgesamt wurden 2398 Frames untersucht.

Nero Recode 2 (ca. 68 % Komprimierung):

Zitat

Euklidischer Abstand in Y: 1,0421
Euklidischer Abstand in U: 0,3578
Euklidischer Abstand in V: 0,3582

Euklidischer Abstand in YUV: 1,4012

Q in Y: 0,984
SSIM in Y: 0,9843

Kleinstes Q in Y: 0,8873 (314)
Größtes Q in Y: 1 (816)

Procoder Express (ca. 68 % Komprimierung):

Zitat

Euklidischer Abstand in Y: 1,8574
Euklidischer Abstand in U: 0,8361
Euklidischer Abstand in V: 0,8612

Euklidischer Abstand in YUV: 2,6255

Q in Y: 0,9662
SSIM in Y: 0,9684

Kleinstes Q in Y: 0,8989 (763)
Größtes Q in Y: 0,9975 (1858)

Man sieht schon mal, dass wir es generell mit hohen SSIM-Werten bzw. mit sehr niedrigen euklidischen Abständen zu tun haben. Ein Blick in die CSV-Datei, wo die Ergebnisse der einzelnen Frames stehen, verrät u. a. auch, dass im vorliegenden Video viele dunkle Bereiche vorhanden sind (die Werte für die Gewichtung der einzelnen Frames sind relativ niedrig).

Nun aber zu den Grafiken, zu den Kurvenverläufen.

Die Mehrzahl der Frames präsentieren sich in etwa so, wie in der nachfolgenden Grafik (Framebereich von 0 bis 215) zu sehen ist. Die Linie des Procoder Express liegt (deutlich) unterhalb der Nero-Recode-Linie.

[Blockierte Grafik: http://img228.imageshack.us/img228/9267/transcoderversusencoderqg4.jpg]

Für Framebereiche, die etwas Besonderes, Auffälliges zeigen, habe ich extra Grafiken angefertigt. Zum Beispiel kann man in der nachfolgenden Grafik schon mal Ausreißer von Nero Recode 2 gegenüber dem Procoder Express ausmachen. Ob und wie sich diese Ausreißer im laufenden Video zeigen, muss erst noch geklärt werden.

[Blockierte Grafik: http://img403.imageshack.us/img403/5978/transcoderversusencodervr8.jpg]

Im nachfolgenden Framebereich zeigt sich im ersten Teilbereich von 444 bis 501 zunächst das gewohnte Bild (die Line des Procoder Express verläuft unterhalb der Nero-Recode-Linie). Ab Frame 502 zeigt Nero Recode 2 jedoch wieder schlechtere Werte (Kamerafahrt durch das Publikum).

[Blockierte Grafik: http://img408.imageshack.us/img408/999/transcoderversusencodergr6.jpg]

Bisher haben wir nur kleine Ausreißer von Nero Recode 2 gesehen, aber nun wird’s etwas heftiger. Im nachfolgenden Framebereich ab Frame 838 zeigt Nero Recode deutliche „Aussetzer“ (im Video wird eine Kamerafahrt durch das Publikum gezeigt und anschließend erfolgt eine weiche Überblendung auf einen der Spieler).

[Blockierte Grafik: http://img153.imageshack.us/img153/958/transcoderversusencoderkg6.jpg]

Am deutlichsten finden sich diese „Aussetzer“ dann im Framebereich von 1416 bis 1523 (weiche Überblendung mit anschließender Kamerafahrt durch das Publikum). Wir merken uns diese schlechten Stellen und prüfen, wie sich diese im laufenden Video bzw. in einem Einzelbildvergleich bemerkbar machen.

[Blockierte Grafik: http://img527.imageshack.us/img527/5610/transcoderversusencoderuf2.jpg]

Beim Betrachten der Videos fällt der Unterschied zwischen Nero Recode 2 und Procoder Express durchaus auf – und zwar in zweierlei Hinsicht. Während in ruhigen Szenen Nero Recode das schärfere und weniger „verschwommene“ Bild liefert, produziert der Procoder Express bei weichen Überblendungen und Kamarafahrten durch das Publikum weniger Verblockungen (hier kommt wohl die Sache mit den Bewegungsvektoren ins Spiel).

Ich habe zur Verifizierung der SSIM-Metrik dann auch noch ein paar Stichproben in Form von Einzelbildvergleichen gemacht, mit dem Ergebnis, dass überall da, wo ich das bessere Bild gesehen habe, auch die Werte am höchsten waren.

Nun interessierte mich, wie das Ganze bei weniger Komprimierung aussieht. Deswegen habe ich auch noch einen Versuch mit ca. 90 % Komprimierung gestartet. Die Zahlen präsentierten sich wie folgt:

Nero Recode 2 (ca. 90 % Komprimierumg):

Zitat

Euklidischer Abstand in Y: 0,1521
Euklidischer Abstand in U: 0,042
Euklidischer Abstand in V: 0,0457

Euklidischer Abstand in YUV: 0,1916

Q in Y: 0,9973
SSIM in Y: 0,9981

Kleinstes Q in Y: 0,9588 (1438)
Größtes Q in Y: 1 (0)

Procoder Express (ca. 90 % Komprimierung):

Zitat

Euklidischer Abstand in Y: 1,5285
Euklidischer Abstand in U: 0,7224
Euklidischer Abstand in V: 0,7412

Euklidischer Abstand in YUV: 2,2177

Q in Y: 0,9758
SSIM in Y: 0,9769

Kleinstes Q in Y: 0,9269 (763)
Größtes Q in Y: 0,9983 (1858)

Auffällig bei den Zahlen war schon mal, dass der kleinste Q-Wert bei Nero Recode 2 diesmal einen relativ hohen Wert hatte (0,9588). Ganz anders als noch bei der 68 % Komprimierung (0,8873). In den Grafiken konnte man dann auch erkennen, dass keine Ausreißer mehr auszumachen sind. Selbst der bei 68 % Komprimierung kritische Framebereich von 1416 bis 1523 (siehe oben) zeigte sich hier in einem ganz anderen Gewand.

[Blockierte Grafik: http://img113.imageshack.us/img113/5711/transcoderversusencoderfw1.jpg]

Bei 90 % Komprimierung ist beim vorliegenden Video die Sachlage klar. Dem Nero-Recode-Video ist hier eindeutig der Vorzug zu geben. Bei 68 % Komprimierung könnte man sich noch streiten, inwieweit die Ausreißer wirklich als störend empfunden werden.

Fazit: Eigentlich kann es nur ein Zwischenfazit sein, denn man müsste noch mehr Clips testen, um mehr Sicherheit zu haben, aber so, wie es sich mir hier präsentiert, bin ich schon der Ansicht, dass man mit einer SSIM-Analyse Aussagen bzgl. der Qualität treffen kann. Man muss die Zahlen und Kurven nur „richtig interpretieren“. Im vorliegenden Beispiel hat Nero Recode 2 bei 68 % Komprimierung zwar den deutlich besseren Durchschnittswert, aber anhand der Kurven offenbaren sich dann doch arge Schwachstellen (die sich auch im laufenden Video bemerkbar machen).

Der Komprimierungsgrad von ca. 68 % ist gar nicht mal so schlecht gewählt, denn irgendwo hier würde ich, trotz der besseren durchschnittlichen SSIM-Werte, das Procoder-Express-Video vorziehen, eben weil es eine „linearere Bildqualität“ liefert.

Ich denke, gerade bei Vergleichen zwischen Transcodern (Requantisierern) und Encodern auf der Basis von Metriken sollte man ein besonderes Augenmerk darauf richten, ab wann ein Transcoder beginnt, (häufiger) Ausreißer zu produzieren (z. B. im direkten Vergleich mit einem Encoder). Spätestens ab diesem Punkt würde ich ein Encoder-Video, trotz der evtl. schlechteren SSIM-Werte, einem Transcoder-Video vorziehen.

Das habe ich natürlich nicht getestet.

Zitat von Eastermeyer

Stimmt es , das der TMPGEnc im RGB24 Farbraum arbeitet ?
Hab ich jetzt schon häufig gelesen.

Wäre es also sinnvoll am Ende jedes Scripts

Code

ConvertToRGB24()

anzuhängen ?

Egal, ob ein ConvertToRGB24() oder ein ConvertToYUY2() zum Einsatz kommt, die von TMPGEnc produzierten Videos sind pixelidentisch.

Ich habe zur Verifizierung ein DV-Video einmal im YUY2-Farbraum und das andere Mal im RGB24-Farbraum von TMPGEnc enkodieren lassen. Am Ende des Scripts stand entweder ein ConvertToRGB24(interlaced=true) oder ein ConvertToYUY2(interlaced=true). Ein einfache metrische Analyse förderte zutage, dass die Videos pixelidentisch sind. Hätte es Verluste durch Farbraumumwandlungen gegeben, so hätten sich diese in den Zahlen niedergeschlagen.

Zitat von kotyczka

Aber der liegt wohl an der Einstellung 'laute Umgebung' in PowerDVD.

So ist es. Damit wird eine AC3-Datei dynamikkomprimiert wiedergegeben.

Zitat von kotyczka

Wobei mir nicht klar ist, warum PowerDVD diesen Effekt bei einer nicht komprimierten ac3-Datei erzeugt

Der Wert für die Dialognormalisierung und die Art der Dynamikkompression sind als sog. „Metainformationen“ in der AC3-Datei hinterlegt. Der eigentliche Audio-Teil bleibt hiervon unberührt. Diese „Metainformationen“ dienen einem Decoder dazu, dass er weiß, wie laut er die AC3-Datei wiedergeben soll und ob er ggf. eine Reduzierung des Dynamikumfanges vornehmen soll.

Ich habe mir vor kurzem mal die Arbeit gemacht, und die Werte für die verschiedenen Profile der Dynamikkompression in eine Excel-Tabelle eingetragen. Herausgekommen sind dann unterschiedliche Grafiken. Die Grafik für die Profile „Film Light“ und „Film Standard“ sieht dabei wie folgt aus.

[Blockierte Grafik: http://img180.imageshack.us/img180/3245/dynamicrangecontrol0104yk7.jpg]

Man sieht sehr schön, an welchen Stellen eine Lautstärkeänderung stattfindet und wo nicht.

Ziel der Dynamikreduzierung ist ja der verbesserte Komfort beim Anhören eines Films, soll heißen, man muss die Lautstärke bei leisen und lauten Stellen nicht ständig nachregeln. Leise Stellen werden lauter wiedergegeben, laute Stellen werden leiser wiedergegeben (vereinfacht ausgedrückt). Im "mittleren Lautstärkebereich" gibt es dann auch einen Bereich, in dem keine Lautstärkeänderung stattfindet – dieser Bereich wird "Null Band" genannt. Unterhalb dieses „Null-Band-Bereiches“ erfolgt eine Anhebung der Lautstärke, oberhalb eine Absenkung derselben (je nach gewähltem Profil unterschiedlich stark). Die Mitte dieses „Null-Band-Bereiches“ entspricht exakt -31 dB.

Jetzt wird vielleicht verständlicher, warum der Dialognormalisierungswert bei Verwendung einer Dynamikkompression unbedingt korrekt zu ermitteln und zu setzen ist. Ansonsten erfolgt die Lautstärkeänderung an der falschen Stelle und es kommt zu sog. „Pumpeffekten“.

kotyczka: Worum geht es bei deinen AC3-Dateien exakt? Geht es primär darum, dass diese komfortabel über das Notebook gehört werden können? Referenz für mich wäre immer, wie sich die AC3-Dateien über eine „normale Anlage“ anhören. Ich würde mir die Frage stellen, kann ich den Audio-Teil komfortabel, d. h., ohne ständig am Lautstärkeregler drehen zu müssen, anhören. Wenn ja, dann benötige ich keine Dynamikkompression. Oder haben deine Audio-Dateien wirklich einen so hohen Dynamikumfang?