VLC Player - schlechter Kontrast

[BK-Morpheus]

Da ich vor kurzem festgestellt habe, dass der Kontrast im VLC unter Win7 irgendwie etwas zu schwach ist und dadurch in dunklen Bereichen des Bildes häufig komische Artefakte zu sehen sind, habe ich ein paar VLC Settings durchprobiert (YUV zu RGB Hardwarekonvertierung abschalten hat den Kontrast auch verbessert, aber andere Qualitätseinbußen gebracht).

Der SMPlayer hat das Problem bei mir übrigens auch und falls ihr das Problem auch habt, könnte euch das hier helfen.

Ich habe eine Nvidia Graka und zum Spaß mal unter den Nvidia Systemeinstellungen umgestellt, dass die Farbanpassungen nicht vom Video-Player vorgenommen werden, sondern von den Nvidia-Settings.
Dort einfach von begrenztem Dynamikbereich auf vollen Dynamikbereich umgestellt und schon ist das Bild wieder Top.
http://666kb.com/i/bg3r5bqzv5sumenf8.png

Ob die Problematik auch bei ATI Karten auftritt und ob man dem dort mit ähnlichen Einstellungen auch auch entgegen wirken kann, weiß ich jedoch nicht.

edit:
Hier mal Screenshots von der Problematik.
VLC Player und Nvidia Settings @ default
http://img213.imageshack.us/img213/6936/vlc1.th.jpg (http://img213.imageshack.us/i/vlc1.jpg/)

Zoom von einer dunklen Stelle
http://img192.imageshack.us/img192/6650/vlc2.th.jpg (http://img192.imageshack.us/i/vlc2.jpg/)


Jetzt ein Screenshot mit Nvidia Settings statt Playersettings und Dynamikumfang voll
http://img716.imageshack.us/img716/6936/vlc1.th.jpg (http://img716.imageshack.us/i/vlc1.jpg/)

[HeldImZelt]

Schau mal hier rein:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=348835

[Sailor Moon]

Ob die Problematik auch bei ATI Karten auftritt und ob man dem dort mit ähnlichen Einstellungen auch auch entgegen wirken kann, weiß ich jedoch nicht.
Eine "Problematik" ist das eher nicht, sondern hängt damit zusammen, dass im originär vorliegenden YCbCr nicht der volle 8-Bit Wertebereich ausgeschöpft wird. Das bleibt auch bei der Transkodierung nach RGB erhalten, so dass für die Ausgabe auf einem Computer-Display die Tonwerte geeignet gespreizt werden müssen (Video- vs. PC-Level). Dabei gehen wtw and btb Informationen verloren, die aber von der Quelle auch nicht genutzt werden sollten.

Gruß

Denis

[HeldImZelt]

Diese Umwandlung blieb aber eines Tages plötzlich und unerwartet aus. VMR und EVR lieferten keine einheitlichen Ergebnisse. Einige Systeme und Treiber wandelten um, andere nicht.

Vielleicht hat man sich auf dem Papier von vornherein die Option zur korrekten Umwandlung der verschiedenen Koeffizienten (BT709/601) von HD/SDTV bei diesen Renderpfaden offen gelassen. Was nVidia im Treiber als Option anbietet, ist streng genommen nicht richtig. Der Treiber kann nicht wissen, um welches Material es sich handelt und wie es richtig umzurechnen ist (50/50 Chance SDTV). Praktisch ist es zwar deutlich besser als gar keine Umwandlung, aber bei HDTV eben nicht korrekt.

Gute Player unterstützen entsprechend Pixelshader, die das Problem aus eigener Kraft beheben (und vor allem wieder in die GPU verlagern) können. Der MPC-HC z.B. liefert getrennte Shader für verschiedene SD/HD Koeffizienten.

[Sailor Moon]

Was nVidia im Treiber als Option anbietet, ist streng genommen nicht richtig. Der Treiber kann nicht wissen, um welches Material es sich handelt
Meine Messung mit SD Material war in jedem Fall korrekt, d.h hier hat er die geeignete Transformation durchgeführt. Ich weiß nicht, ob er nun immer SD-Material unterstellt, oder, wie beispielsweise meine externen Lösungen, von der Auflösung ausgeht. Hatte das nie genauer verfolgt, da HTPC kein Thema für mich war. Interessant wäre auch zu wissen, was bei skalierter YCbCr Ausgabe von orginärem SD-Material passiert. Werden die Werte geeignet angepaßt, so dass ein "dummer" TV ohne entsprechende Auswahl die "HD-Transformation" nach RGB anwenden kann?

Gruß

Denis

[BK-Morpheus]

Schau mal hier rein:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=348835
Interessanter Thread...den hatte ich noch gar nicht gesehen.
Naja, mit dem "workaround" bin ich jetzt zufrieden mit dem Bild, aber dass sowas nötig ist empfinde ich schon als störend.

[aths]

Eine "Problematik" ist das eher nicht, sondern hängt damit zusammen, dass im originär vorliegenden YCbCr nicht der volle 8-Bit Wertebereich ausgeschöpft wird. Das bleibt auch bei der Transkodierung nach RGB erhalten,Nur wenn man die falsche Transformationsmatrix nutzt. Wikipedia zum Beispiel gibt Koeffizienten an, dass RGB 0..255 auf Y 16..235 hin- und zurückgerechnet wird.

[Sailor Moon]

Nur wenn man die falsche Transformationsmatrix nutzt. Wikipedia zum Beispiel gibt Koeffizienten an, dass RGB 0..255 auf Y 16..235 hin- und zurückgerechnet wird.
Klar gibt es auch gleich eine geeignete Matrix, die Spreizung und Transformation beinhaltet (das sollte ja schon mathematisch klar sein). Aber ich denke, dass so deutlich war, was ich meinte. "Falsch" ist dabei relativ zum Ausgabegerät zu sehen. Gerade bei einigen Hybridmodellen im LCD-Bereich gibt es tatsächlich Bildschirme, die per HDMI immer Videolevel erwarten, egal ob in RGB oder YCbCr zugespielt wird (was für non Videocontent natürlich alles andere als ideal ist).

Gruß

Denis

[HeldImZelt]

Videolevel ist nicht gleich Videolevel. HDTV und SDTV haben unterschiedliche Koeffizienten und damit verschiedene Farbabstände zueinander. Das hat erst mal nicht direkt was mit den Schwarz- und Weißwerten zu tun.
When standardising high-definition video, the ATSC chose a different formula for the YCbCr than that used for standard-definition video. This means that when converting between SDTV and HDTV, the color information has to be altered, in addition to image scaling the video.
http://en.wikipedia.org/wiki/YUV#BT.709_and_BT.601

[Sailor Moon]

Videolevel ist nicht gleich Videolevel. HDTV und SDTV haben unterschiedliche Koeffizienten und damit verschiedene Farbabstände zueinander. Das hat erst mal nicht direkt was mit den Schwarz- und Weißwerten zu tun.
Ja, logisch, ich meinte auch nichts anderes. Es muß eben die richtige Transformationsmatrix gewählt werden. Im Bereich der Standalone-Videoprozessoren geschieht das anhand der Auflösung des zugespielten Materials (notfalls kann man eine manuelle Festlegung treffen - sieht beim Radiance dann so (http://foto.arcor-online.net/palb/alben/69/1896769/2560_6332623736373235.jpg) aus) und auch die TVs entscheiden so. Deswegen muß man gerade bei der Zuspielung in YCbCr ja etwas aufpassen, wenn man skaliertes SD-Material zuspielt. Die wenigsten TVs (bei Sony geht es) erlauben eine Auswahl der korrekten Matrix für SD bzw. HD und gehen bei >= 720 Zeilen sturr von originärem HD Material aus. Entsprechend muß eine Anspassung schon vorher erfolgen, auch wenn ein YCbCr Workflow durchgehalten wird. Aber diese Grundsatzüberlegungen entbinden uns ja trotzdem nicht von weiteren Anpassungen in Bezug auf den Signalpegel, wenn in RGB zugespielt wird. Alle LCD-TVs sollten aber für die Zuspielung in digitalem RGB ohnehin einen separaten Schalter haben (bei Samsung: "HDMI Schwarzwert").

Bezüglich der Transformation nach RGB am Rechner gehe ich aber eigentlich davon aus, dass treiberseitig hier auch nach Quellauflösung entschieden wird. Wie gesagt, HD-Material habe ich farbmetrisch für den Workflow am Rechner nicht vermessen (habe gar kein internes Blu-ray Laufwerk oder entsprechendes Material auf dem Rechner), für SD wurde aber die korrekte Transformation durchgeführt.

Wo ich gerade das Verhalten einiger Computer-LCDs erwähne: Ich hatte hier kürzlich zwei Bildschirme, bei den es genau anders herum als in meinem o.g. Beispiel war. D.h. sie gingen per HDMI grundsätzlich von PC-Leveln aus, auch bei Zuspielung in YCbCr. Das ist natürlich besonders "interessant", weil ich keine externe Lösung kenne, die das geeignet umsetzen würde.

Gruß

Denis