@Spider-Schwein, Blur: Ihr redet hier irgendwie völlig aneinander vorbei. Die Sache mit 16-235 und erweitertem Gamut ist insofern richtig, als dass x.v.Color (xvYCC) im Gegensatz zum "normalen YCC" den vollen 8-Bit-Wertebereich 0-255 benutzt (sowohl bei Luminanz als auch bei Chroma). Der Witz ist, dass Farben im alten Wertebereich das gleiche wie beim alten YCC bedeuten (Rückwärtskompatibilität).
@Spider-Schwein: Das hättest Du aber von vorneherein deutlicher sagen können. So wie Du es gepostet hattest, hörte es sich irgendwie an, als ob dadurch aus sRGB AdobeRGB werden könnte - was natürlich nicht der Fall ist (die RGB-Farbraumfamilien ticken da etwas anders als die "YCC-Farbraumfamilien"). In diesem Sinne hatte Blur also mit seiner Antwort schon recht.
Außerdem hat das alles gar nichts mit PC-Monitoren zu tun, da die mit RGB angesteuert werden, da spielt x.v.Color also überhaupt keine Rolle. HDMI definiert für RGB-Übertragung eigentlich nur sRGB und ab 1.4 glaube ich auch AdobeRGB. Aber selbst das dürfte für PC-Monitore relativ egal sein, weil die nicht auf einen Standardfarbraum kalibriert sind. D.h. man gibt der Grafikkarte RGB-Werte im Monitorfarbraum und die werden einfach transparent an den Monitor übermittelt. Wie groß der Monitorfarbraum ist, ist dabei völlig egal - die HDMI-Information "das hier ist sRGB" ist dann wahrscheinlich einfach nur ein Dummy (bzw. reduziert auf die Info "das hier ist RGB"). Hinweis: Die zweite Hälfte des letzten Absatzes basiert ausdrücklich auf gefährlichem Halbwissen (viel findet man nicht zu diesem Thema).
Weiterhin: Die Helligkeits/Farbauflösung (8 Bit, 10 Bit, deep color...) ist von diesen Farbraumbetrachtungen auch nochmal völlig unabhängig.
Ach mir ist das doch egal, wenn du x.v. Color ignorierst, abstreitest, leugnest oder wie man es auch immer nennen magst.
(Naja alles ist relativ, normalerweise ist es weniger). Wie das jetzt Monitore machen entzieht sich meiner Kenntnis.