Frage zu Farbtiefen in Bit / YCbCr 4:4:4

[Lawmachine79]

"Früher" war es ja im Allgemeinen so, dass sich der Platzbedarf eines Bildes in Byte berechnen lies durch: Auflösung X-Achse * Auflösung Y-Achse * Farbtiefe in Bit / 8.

Ist das immer noch so, vor dem Hintergrund, dass es für Farbinformation nun auch YCbCr als "Rechenart" gibt? Wieviel bittig können die drei Werte jeweils sein? Wo kommt YCbCr zum Einsatz? Nur bei Fernsehern oder auch bei Monitoren? Wo muss man diese Farbtiefenangaben und YCbCr technisch einordnen?

Was mir bekannt ist: RGB erzeugt Farben durch Verortung im System Rot-Grün-und-Blau, YCbCr durch Zuordnung eines Helligkeitswerts und die Hinzufügung blauer und roter Chrominanz.

[Gast]

Es sind weiterhin 3 Kanäle, üblicherweise mit 8bit pro Kanal, es gibt aber (wie auch bei RGB) auch die Möglichkeit für 10 oder 12bit pro Kanal.

Bei 4:4:4 werden alle Kanäle mit voller Auflösung übertragen, die benötigte Bandbreite ist also die selbe wie bei RGB mit gleicher Bitzahl pro Kanal.

Mit YCbCr sind allerdings noch andere Varianten wie 4:2:2 möglich, bei denen nur der Helligkeitskanal mit voller Auflösung übertragen wird, die Farbkanäle jedoch mit reduzierter Auflösung. Damit kann man dann eine höhere Qualität erreichen als es in RGB mit gleicher Bandbreite möglich wäre.

[Rumbah]

"Auflösung X-Achse * Auflösung Y-Achse * Farbtiefe in Bit / 8" gilt genauso auch für YCbCr 4:4:4. Die Werte sind im Normalfall auch 8 Bit groß pro Komponente.

Die Umrechnung der Werte findet mit einer einfachen Matrixmultiplikation statt, die auch umkehrbar ist, also geht dir theoretisch (natürlich im Rahmen der Rechengenauigkeit) beim Hin- und Herwandeln nichts verloren und sie sind von der Genauigkeit gleichwertig.

RGB ist das System, welches Fernseher und Monitore zur Anzeige nutzen, denn sie nutzen dafür ja rote, grüne und blaue Bildpunkte. Wenn sie auch andere Formate entgegennehmen, dann werden sie auf jeden Fall intern vom Gerät in RGB gewandelt.

YCbCr ist dem menschlichen Sehen nachempfunden, daher lassen sich dort einfacher "Optimierungen" durchführen. So werden z.B. beim TV, und auch bei allen DVDs und Blurays, die beiden Farbkanäle nur mit einem Viertel der Auflösung gespeichert (meist YCbCr 4:2:0). Unser Sehapparat kann nämlich Helligkeitsunterschiede besser wahrnehmen als Farbunterschiede, daher fällt das bei natürlichen Bildern kaum auf.
Damit hat man dann bei 4 Pixeln: 4 x 1Byte Y + 1Byte Cb + 1Byte Cr = 12bit pro Pixel.
Da das Format ursprünglich aus der analogen Welt kam, ist es bei Videoproduktionen üblich und teilweise auch dem Workflow geschuldet, dass der Wertebereich etwas gestaucht wird. Die Werte von 0-15 und 236/241-255 werden dann für andere Informationen genutzt oder als Reserve bei der Bearbeitung.

[Lawmachine79]

"Auflösung X-Achse * Auflösung Y-Achse * Farbtiefe in Bit / 8" gilt genauso auch für YCbCr 4:4:4. Die Werte sind im Normalfall auch 8 Bit groß pro Komponente.

Die Umrechnung der Werte findet mit einer einfachen Matrixmultiplikation statt, die auch umkehrbar ist, also geht dir theoretisch (natürlich im Rahmen der Rechengenauigkeit) beim Hin- und Herwandeln nichts verloren und sie sind von der Genauigkeit gleichwertig.

RGB ist das System, welches Fernseher und Monitore zur Anzeige nutzen, denn sie nutzen dafür ja rote, grüne und blaue Bildpunkte. Wenn sie auch andere Formate entgegennehmen, dann werden sie auf jeden Fall intern vom Gerät in RGB gewandelt.

YCbCr ist dem menschlichen Sehen nachempfunden, daher lassen sich dort einfacher "Optimierungen" durchführen. So werden z.B. beim TV, und auch bei allen DVDs und Blurays, die beiden Farbkanäle nur mit einem Viertel der Auflösung gespeichert (meist YCbCr 4:2:0). Unser Sehapparat kann nämlich Helligkeitsunterschiede besser wahrnehmen als Farbunterschiede, daher fällt das bei natürlichen Bildern kaum auf.
Damit hat man dann bei 4 Pixeln: 4 x 1Byte Y + 1Byte Cb + 1Byte Cr = 12bit pro Pixel.
Da das Format ursprünglich aus der analogen Welt kam, ist es bei Videoproduktionen üblich und teilweise auch dem Workflow geschuldet, dass der Wertebereich etwas gestaucht wird. Die Werte von 0-15 und 236/241-255 werden dann für andere Informationen genutzt oder als Reserve bei der Bearbeitung.
Also habe ich bei RGB bei 32 Bit Farbtiefe eine größere Datenmenge als bei YCbCr 4:4:4 (insgesamt 24 Bit, je 8 Bit Y/Cb/Cr)? Was mich wundert: Luminanz und jede der beiden Chrominanzwerte sind maximal 8 Bit Tief? Es gibt nur 256 Graustufen? Wirkt wenig auf den ersten Blick.


Bei 4:4:4 werden alle Kanäle mit voller Auflösung übertragen, die benötigte Bandbreite ist also die selbe wie bei RGB mit gleicher Bitzahl pro Kanal.

Wie im Absatz zuvor gefragt: geht man bei RGB nicht von 32 Bit aus?

[Mr.Magic]

Wie im Absatz zuvor gefragt: geht man bei RGB nicht von 32 Bit aus?

32bit Farbtiefe sind 24bit RGB + 8bit für 256 Transparenzstufen. RGB (Deep Color) geht offiziell bis 48bit, also 16bit pro Farbkanal.

[mercutio]

"Früher" war es ja im Allgemeinen so, dass sich der Platzbedarf eines Bildes in Byte berechnen lies durch: Auflösung X-Achse * Auflösung Y-Achse * Farbtiefe in Bit / 8.

Ist das immer noch so, vor dem Hintergrund, dass es für Farbinformation nun auch YCbCr als "Rechenart" gibt? Wieviel bittig können die drei Werte jeweils sein? Wo kommt YCbCr zum Einsatz? Nur bei Fernsehern oder auch bei Monitoren? Wo muss man diese Farbtiefenangaben und YCbCr technisch einordnen?

Was mir bekannt ist: RGB erzeugt Farben durch Verortung im System Rot-Grün-und-Blau, YCbCr durch Zuordnung eines Helligkeitswerts und die Hinzufügung blauer und roter Chrominanz.

Stimmt im Prinzip auch noch, nur dass manche Bild-Datei-Formate 4 Farb-Kanäle (cmyk) haben, zusätzlich noch Alpha-Kanäle erlauben, bei fast allen noch Meta-Infos gespeichert werden können, Freistellpfade, Farbprofile hinterlegt werden können...
Manche Datei-Formate erlauben auch noch zip-, jpeg-, CCCIT3 Kompression... und was es alles sonst noch gibt.

[Ectoplasma]

Stimmt im Prinzip auch noch, nur dass manche Bild-Datei-Formate 4 Farb-Kanäle (cmyk) haben, zusätzlich noch Alpha-Kanäle erlauben, bei fast allen noch Meta-Infos gespeichert werden können, Freistellpfade, Farbprofile hinterlegt werden können...
Manche Datei-Formate erlauben auch noch zip-, jpeg-, CCCIT3 Kompression... und was es alles sonst noch gibt.

Oder kurz gesagt TIFF, da kannst du das alles reinpacken.

[Gast]

Also habe ich bei RGB bei 32 Bit Farbtiefe eine größere Datenmenge als bei YCbCr 4:4:4 (insgesamt 24 Bit, je 8 Bit Y/Cb/Cr)?

Farbtiefe sind in RGB in der Regel 3*8bit, also 24bit. Die 32bit kommen von weiteren 8bit für den Alphakanal, also für die Transparenz. Im Framebuffer selbst sind diese auch üblicherweise vorhanden, egal ob benutzt oder nicht, ans Ausgabegerät werden aber logischerweise nur die Farbinhalte, also 24bit/Pixel übertragen (Mir ist jedenfalls noch kein Ausgabegerät bekannt, dass mit Transparenz was sinnvolles anfangen kann).
Es gibt hier auch Varianten, in denen der Framebuffer aus 3x10bit für die Farbkanäle und 2bit für Alpha zusammengesetzt ist, ans Ausgabegerät gehen aber auch hier in der Regel 3x8bit.


Was mich wundert: Luminanz und jede der beiden Chrominanzwerte sind maximal 8 Bit Tief? Es gibt nur 256 Graustufen? Wirkt wenig auf den ersten Blick.

Es gibt auch bei RGB nicht mehr. Bei Graustufen sind die Werte für R, G und B ja jeweils gleich, also auch nur 256 für die reinen Graustufen.


Wie im Absatz zuvor gefragt: geht man bei RGB nicht von 32 Bit aus?
Wie gesagt die 32bit meinen normalerweise ARGB, aber ja beispielsweise wird oft bei Kompressionsformaten bei der Erreichbaren Kompression übertrieben, da man von 32bit ausgeht, in Wirklichkeit man aber den Alpha-Kanal (wenn dieser nicht gebraucht wir) komplett verwirft und diesen Schritt mit zur Kompression rechnet.

[PatkIllA]

Bei YCbCr gilt es noch zu beachten, dass 16 als Schwarz gilt und 235 als weiß. Praktisch hat man also keine vollen 8 Bit.
Deswegen hat man etwas mehr als Rundungsfehler, wenn man RGB nach YCbCr und wieder zurückwandelt.
Ich habe bis heute nicht verstanden, wofür man das außerhalb der Produktion brauchen sollte. Noch schlimmer ist, dass es das teilweise auch RGB gibt.

[aufkrawall]

Es ist auch full range YCbCr möglich und auch damit spart man immer noch massig Bandbreite gegenüber RGB.
Die verlustlose Konvertierung ist wohl nicht so einfach, da gab es lange Threads bei doom9 zu.

[Lawmachine79]

Wie ist das eigentlich bei YCbCr 4:2:0? Da wird ja auf jeder Achse nur jedem zweiten Pixel Chrominanzwerte zugeordnet. Aber die anderen Pixel werden dann ja nicht in Helligkeitsstufen dargestellt. Bekommen die "automatisch" den Chrominanzwert des "vorhergehenden" Pixel, der Chrominanzwerte zugeordnet bekommen hat?

[iuno]

Ja. Der Wert gilt dann eben nicht nur fuer den "vorhergehenden", sondern fuer beide.
Eine Suche nach "Farbunterabtastung" oder "Chroma Subsampling" liefert dir alle Erklaerungen ;)

[24p]

Es ist auch full range YCbCr möglich und auch damit spart man immer noch massig Bandbreite gegenüber RGB.
Die verlustlose Konvertierung ist wohl nicht so einfach, da gab es lange Threads bei doom9 zu.


BTW wäre mit YCBr 4:2:2 sogar 4K@120Hz mit hdmi2.0 möglich.

[Gast]

Wie ist das eigentlich bei YCbCr 4:2:0? Da wird ja auf jeder Achse nur jedem zweiten Pixel Chrominanzwerte zugeordnet.

Ja, bei 4:2:0 wird die Auflösung für die Farbkanäle in jede Richtung Quasi halbiert.

Bei 1920x1080 werden die Chromakanäle nur in 960x540 übertragen.
Jeweils 4 Pixel bekommen dann die gleichen Chromawerte, der Helligkeitswert ist allerdings für jedes Pixel vorhanden.

[Gast]

"Früher" war es ja im Allgemeinen so, dass sich der Platzbedarf eines Bildes in Byte berechnen lies durch: Auflösung X-Achse * Auflösung Y-Achse * Farbtiefe in Bit / 8.

Ich glaube, Du würfelst da verschiedene Sachen durcheinander. Einseits die Speicherung eines Einzelbildes (zB im Basisformat BMP) und die Speicherung bewegter Bilder in einem Datenstrom, wofür zu verschiedenen Tricks gegriffen werden musste und wird (Stichwort x264).

https://de.wikipedia.org/wiki/Farbunterabtastung


"
Ist das immer noch so, vor dem Hintergrund, dass es für Farbinformation nun auch YCbCr als "Rechenart" gibt?

Das ist einer der "Tricks" um die Datenmenge bei bewegten Bildern zu reduzieren.
https://de.wikipedia.org/wiki/YCbCr-Farbmodell

So ganz taufrisch ist sie auch nicht: https://de.wikipedia.org/wiki/ITU-R_BT_601

"Was mir bekannt ist: RGB erzeugt Farben durch Verortung im System Rot-Grün-und-Blau, YCbCr durch Zuordnung eines Helligkeitswerts und die Hinzufügung blauer und roter Chrominanz.

So einfach ist das nicht. Es geht darum, große Datenmengen sinnvoll zu verkleinern. Dabei nutzt man Schwächen des menschlichen Sehapparates aus um weniger relevante Informationen wegzulassen (Verringerung der Abstastrate und -Umfang).

Letztlich aber werden aus den YCbCr Daten RGB Daten gewonnen um diese auf einem Monitor überhaupt darstellen zu können, denn diese können mit den reduzierten Daten / Signalen meist nichts anfangen.

Wichtig ist die Abtastung zB im professionellen Bereich (Broadcast), wo man nicht mit 4:2:0 arbeiten kann sondern eine "volle Abtastung" (4:4:4) benötigt um dieses ohne Verluste / Ausfransungen an harten Farbkanten verarbeiten zu können (zB Schriften drüberlegen). ...

Also immer schön differenzieren: Bilder als solche werden meist verlustfrei (tga/bmp) gespeichert und sind "RGB" - bewegte Bilddaten aber sind ein völlig anderes Thema...

[Isogul]

Ganz genau prima erklärt! Man kann das in mehreren Bereichen einsetzten, auch in der Übertragung.
Ist aber alles egal, es bringt nur verschlechterungen im Bild, darum sollte man wenn es geht überall in der Kette auf volle Qualität und Farbauflösung setzten. 4:2:0 gibt es nur im Consumer Videobereich, das vergessen auch viele im "Home" Videoschnitt. Hier sollte man auch wenn möglich immer mit 4:4:4 oder 4:2:2 arbeiten wie im Broadcast Bereich üblich um optimal Qualität zu haben.

[Lawmachine79]

Ich glaube, Du würfelst da verschiedene Sachen durcheinander. Einseits die Speicherung eines Einzelbildes (zB im Basisformat BMP) und die Speicherung bewegter Bilder in einem Datenstrom, wofür zu verschiedenen Tricks gegriffen werden musste und wird (Stichwort x264).

https://de.wikipedia.org/wiki/Farbunterabtastung




Das ist einer der "Tricks" um die Datenmenge bei bewegten Bildern zu reduzieren.
https://de.wikipedia.org/wiki/YCbCr-Farbmodell

So ganz taufrisch ist sie auch nicht: https://de.wikipedia.org/wiki/ITU-R_BT_601



So einfach ist das nicht. Es geht darum, große Datenmengen sinnvoll zu verkleinern. Dabei nutzt man Schwächen des menschlichen Sehapparates aus um weniger relevante Informationen wegzulassen (Verringerung der Abstastrate und -Umfang).

Letztlich aber werden aus den YCbCr Daten RGB Daten gewonnen um diese auf einem Monitor überhaupt darstellen zu können, denn diese können mit den reduzierten Daten / Signalen meist nichts anfangen.

Wichtig ist die Abtastung zB im professionellen Bereich (Broadcast), wo man nicht mit 4:2:0 arbeiten kann sondern eine "volle Abtastung" (4:4:4) benötigt um dieses ohne Verluste / Ausfransungen an harten Farbkanten verarbeiten zu können (zB Schriften drüberlegen). ...

Also immer schön differenzieren: Bilder als solche werden meist verlustfrei (tga/bmp) gespeichert und sind "RGB" - bewegte Bilddaten aber sind ein völlig anderes Thema...
Ah, also RGB ist immer noch das "Darstellungsformat" und YCbCr ist "nur" das "Übertragungsformat"? Auf welcher Ebene wird das denn umgerechnet?

[aufkrawall]

Von der Kamera und vom Videorenderer/Grafiktreiber.

[iuno]

+ggf. im Monitor/TV

[Lawmachine79]

Können aus einem Luminanz und zwei Chrominanzkanälen alle 16.777.216 Farben des RGB-Farbraums dargestellt werden oder kommt es zu Verlust, weil der YCbCr-Farbraum "geringer aufgelöst" ist. Ich lese hier immer von 8 bzw. 10 Bit. Damit ist doch pro Kanal gemeint oder?

[iuno]

Grundsaetzlich hast du die gleiche Menge an Farben, da du weiterhin drei Kanaele zu jeweils (z.B.) einem Byte hast. 2^8^3 bleiben ~16 Mio, egal wie es transformiert wird. Der Farbraum an sich kann freilich anders sein.

Ja, damit meint man pro Kanal. 8 bpc (bits per color) ist "normal", aber es gibt eben auch Standards mit 10, 12, 14... bpc. Man wird auch bei luminance-chrominance Modellen mehr Bit pro Kanal definieren koennen, ich weiss aber nicht inwieweit das standardisiert ist.

[aufkrawall]

Man muss halt bei der Konvertierung aufpassen. Ich hatte das vor ein paar Jahren mit AviSynth gemacht und dabei hatte das YCbCr-Ergebnis wesentlich weniger Farben als in RGB. Es ist also wohl Clipping aufgetreten. Mit bloßem Auge war der Unterschied allerdings nicht auszumachen, wobei das auch am Content liegen kann. Pure Gradienten dürften wesentlich anfälliger sein.

Man kann mit OBS und Pascal auch in YCbCr 4:4:4 und verlustloser Kompression aufnehmen. Das funktioniert leider nicht ganz perfekt, bei Desktop-Icons lassen sich geringfüge Unterschiede ausmachen.
Für Spiele-Captures aber trotzdem ein enormer Gewinn. Dummerweise kann man es nicht hardwarebeschleunigt abspielen. Vielleicht könnte es die Hardware und es scheitert an der Software.

In einer idealen Welt wäre wohl jeder Content YCgCo 4:4:4 > 10 Bit und jedes Gerät käme mit solchem Input klar. :redface:

[Foobar2001]

Ich glaube du verwechselst "kein Chroma-Subsampling" mit "verlustlos"?

60Hz verlustloses Video waeren absurde Datenmengen (>300MB/s in 1440p)

[aufkrawall]

Ich hatte bisher nur den gut zu komprimierenden Desktop damit aufgenommen.
Tatsächlich​ müsste die Bitrate bei Spielen durch die Decke gehen.
Ist allerdings h.264 high profile, die Kompression sollte also besser sein als z.B. vom Fraps-Codec.
(auch h.264 kann lossless sein, auch wenn es die spec nicht vorsieht.)

[Gimmick]

Man muss halt bei der Konvertierung aufpassen. Ich hatte das vor ein paar Jahren mit AviSynth gemacht und dabei hatte das YCbCr-Ergebnis wesentlich weniger Farben als in RGB. Es ist also wohl Clipping aufgetreten. Mit bloßem Auge war der Unterschied allerdings nicht auszumachen, wobei das auch am Content liegen kann. Pure Gradienten dürften wesentlich anfälliger sein.


Man muss da ein wenig schauen welches Ausgangsmaterial man hat und was bei der Wiedergabe erwartet wird. Wenn durch die falsch eingestellte Matrix ein 0-255 RGB erwartet, aber ein 16-235 gesendet wird erscheint alles etwas matt, weil kein richtiges Schwarz wiedergegeben wird.

Ansonsten ändern sich durch die Transformation von RGB<->YCbCr schon die Farben ein wenig. Die Zahlen in der Transformationsmatrix sind in ihrer Genauigkeit begrenzt.


Ich glaube du verwechselst "kein Chroma-Subsampling" mit "verlustlos"?

60Hz verlustloses Video waeren absurde Datenmengen (>300MB/s in 1440p)

Verlustfrei ist nicht das gleiche wie unkomprimiert =).

[Lawmachine79]

Ich glaube du verwechselst "kein Chroma-Subsampling" mit "verlustlos"?

60Hz verlustloses Video waeren absurde Datenmengen (>300MB/s in 1440p)
Unkomprimiert wären absurde Datenmengen. Es ist aber möglich, verlustlos zu komprimieren, m.W. hat H.264 da mehrere Profile zu bieten, k.a. ob da verlustfreie dabei sind.

Intracoding dürfte weitestgehend verlustfrei sein, die Entropiekodierung des Bitstroms auch. Intercodierung mit Bewegungsvorhersage dürfte Verluste erzeugen, ebenso das Quantisieren der DCT-Koeffizienten.


(auch h.264 kann lossless sein, auch wenn es die spec nicht vorsieht.)
Auch das "dickste Profil" nicht? Aber wahrscheinlich wird auch im dicksten Profil quantisiert, ansonsten könnte man sich die Entropiekodierung ja auch fast sparen.

[Foobar2001]

Verlustfrei ist nicht das gleiche wie unkomprimiert =).
Nein, ist es nicht. Aber in seinem Fall ist es weder verlustlos noch unkomprimiert. 4:4:4 deaktiviert nur Chroma-Subsampling, das heisst noch lange nicht dass es verlustlos ist.

Es gibt H.264 lossless und x264 kann das auch, aber die Datenmengen sind absurd.

[Lawmachine79]

Nein, ist es nicht. Aber in seinem Fall ist es weder verlustlos noch unkomprimiert. 4:4:4 deaktiviert nur Chroma-Subsampling, das heisst noch lange nicht dass es verlustlos ist.

Es gibt H.264 lossless und x264 kann das auch, aber die Datenmengen sind absurd.
Wieviel wird da noch eingespart im Vergleich zu unkomprimiertem Material? Und welche "Reduktionstechniken" werde da dann noch genutzt?

[Foobar2001]

Alles was sonst auch laeuft. Wie gesagt, der einzige Unterschied ist, dass die Chroma-Planes volle Aufloesung haben, sonst wird genau das gleiche gemacht.

[iuno]

Ich glaube er meinte den Vergleich lossless (h.264) vs. unkomprimiert
@warmachine79: es werden halt keine Informationen verworfen sondern nur so komprimiert, dass man alle urspr. verfuegbaren Informationen wieder errechnen kann. PNG komprimiert z.B. auch verlustfrei und ist viel kleiner als eine unkomprimierte bitmap.
Kurzer Test mit 30 Sekunden Gameplay Video, nicht das beste Beispiel, weil das Original ja auch schon komprimiert ist, aber als Anhaltspunkt:
"Original": 160 MiB
unkomprimiert: 4,9 GiB
x264 lossless: <700 MiB (haengt natuerlich auch wieder vom preset ab)

[Gast]

Wieviel wird da noch eingespart im Vergleich zu unkomprimiertem Material? Und welche "Reduktionstechniken" werde da dann noch genutzt?
zwischen 0-99% hängt ja vom video ab, wenn du dieses Rauschen hast wenn kein TV Kanal gefunden wurde, dann sparst du nix, wenn das bild eine stunde weiß ist dann jede Menge...

[Lawmachine79]

Alles was sonst auch laeuft. Wie gesagt, der einzige Unterschied ist, dass die Chroma-Planes volle Aufloesung haben, sonst wird genau das gleiche gemacht.
Wenn es wirklich losless ist, dürfte es eigentlich nicht alles machen. Ein H.264-Profil heisst "High Intra 4:4:4" - da dürfte z.B: keine Interprediction stattfinden. Und wenn es wirklich losless ist, frage ich mich, wie die Quantisierung ablaufen soll. Da _muss_ eigentlich was verloren gehen.

[Gast]

Wenn es wirklich losless ist, dürfte es eigentlich nicht alles machen. Ein H.264-Profil heisst "High Intra 4:4:4" - da dürfte z.B: keine Interprediction stattfinden. Und wenn es wirklich losless ist, frage ich mich, wie die Quantisierung ablaufen soll. Da _muss_ eigentlich was verloren gehen.
4:4:4 hat doch absolut nichts mit losless zutun... das sind 2 verschiedene Dinge.

Du kannst auch 4:2:0 Losless machen, was auch Sinn macht wenn man eben dieses Ausgangsmaterial hat.

Losless = CRF 0

[Foobar2001]

Ach du meintest was wird beim lossless profile gemacht. Sorry ich dachte nur was 4:4:4 angeht an sich.

Lossless duerfte noch die Motion-Prediction und DCT machen und dann Cabac, aber halt keine Quantisierung.

[Lawmachine79]

Ach du meintest was wird beim lossless profile gemacht. Sorry ich dachte nur was 4:4:4 angeht an sich.

Lossless duerfte noch die Motion-Prediction und DCT machen und dann Cabac, aber halt keine Quantisierung.
Produziert CABAC nicht mehr Overhead als es ohne Quantisierung noch Einsparpotential gibt? Und Motion-Prediction dürfte doch auch verlustbelastet, nur die "räumliche" Prediction innerhalb eines Bildes (Intra) ist m.W. verlustfrei.

[Rooter]

Du kannst auch 4:2:0 Losless machen, was auch Sinn macht wenn man eben dieses Ausgangsmaterial hat.Das kann aber nicht lossless sein weil man ja Cb und Cr nur mit halber Auflösung speichert.

MfG
Rooter

[iuno]

Doch natuerlich, wenn das Ausgangsmaterial auch schon so aufgenommen wurde.
Wir reden hier von "lossless" gegenueber der Originalaufnahme, nicht einer unmoeglichen idealistischen Aufnahme.

[Lawmachine79]

Doch natuerlich, wenn das Ausgangsmaterial auch schon so aufgenommen wurde.
Wir reden hier von "lossless" gegenueber der Originalaufnahme, nicht einer unmoeglichen idealistischen Aufnahme.
Stimmt, dann müssen die Eingangs- und Ausgangsmatrixen am Ende identisch sein.

[pest]

Produziert CABAC nicht mehr Overhead als es ohne Quantisierung noch Einsparpotential gibt? Und Motion-Prediction dürfte doch auch verlustbelastet, nur die "räumliche" Prediction innerhalb eines Bildes (Intra) ist m.W. verlustfrei.

1. Nein
2. Nein
3. Nein

nur die eigentliche Quantisierung ("abschneiden von Frequenzen") ist verlustbehaftet

es ist natürlich Quatsch ein verlustbehaftetes Video in ein Lossless Format umzuwandeln da durch das Quantisierungsrauschen der Verlustfreie Codec so seine Probleme hat.

[Lawmachine79]

1. Nein
2. Nein
3. Nein

nur die eigentliche Quantisierung ("abschneiden von Frequenzen") ist verlustbehaftet

es ist natürlich Quatsch ein verlustbehaftetes Video in ein Lossless Format umzuwandeln da durch das Quantisierungsrauschen der Verlustfreie Codec so seine Probleme hat.
Und beim Quantisieren werden nicht nur Frequenzen abgeschnitten, sondern auch ähnlichen Werten ein einheitlicher Wert zugeordnet, so dass die Entropiekodierung wirksamer wird.
Wieso dürfen dann in HQ-Profilen nur Intrapredictionbilder verwendet werden (z.B: High 4:4:4 Intra)?

[Foobar2001]

Prediction jeglicher Art sorgt nur fuer besseres (kleineres) Delta in den Residuals und ist prinzipiell nicht verlustbehaftet. Solange du das Residual verlustfrei kodierst kannst du auch weisses Rauschen als Predictor benutzen.

[Lawmachine79]

Prediction jeglicher Art sorgt nur fuer besseres (kleineres) Delta in den Residuals und ist prinzipiell nicht verlustbehaftet. Solange du das Residual verlustfrei kodierst kannst du auch weisses Rauschen als Predictor benutzen.
Hmm, ok, aber warum dann kein Interprediction in HQ-Profilen?

[Isogul]

Also ihr macht ja auch ein Gemehre! Wenns nur um 1080P geht, dann nimmt man im Schnitt wirklich Lossless oder Codecs wie Lagerith etc. die auch Lossless arbeiten. Das bringt die beste Qualität, ist wenig CPU belastend und Speicherplatz juckt doch keinen weiter. Ansonsten wird im Profibereich mit Codecs wie DNXHD oder DNXHR gearbeitet, optional auch noch Prores, wobei der nicht sehr effektiv ist im Vergleich zur dargebotenen Bildqualität, jedoch arbeiten alle in 4:2:2 bei 10Bit oder auch 4:4:4 10bit oder mehr in verschiedenen Bitraten. Von Sony und Co gibts auch noch ähnliche Proficodecs, die nutzt man dann dazu.Der Rest der sonst in 4:2:0 ist, ist alles Consumer Kram und nicht als Master gedacht.

[Fusion_Power]

Ganz nebenbei, wo stellt man in Win10 die Farbtiefe ein? Früher war das bei der Auflösung mit dabei, jetzt gibt es die Einstellung gar nicht mehr direkt, war mir bisher nie aufgefallen. Es gibt jetzt ein Farbprofil-Menü, kannte ich auch noch nicht. Aber da steht auch nix von Farbtiefe.

[aufkrawall]

Wird womöglich offiziell gar nicht unterstützt, der DWM kann keine 10 Bit pro Kanal darstellen (und weniger als 8 Bit sind ja unsinnig). Bei 10 Bit Input gibts dann Clipping zu 8 Bit.
Wahrscheinlich geht deshalb mit Hitman DX12 auch kein HDR, sondern nur mit DX11. Ich hatte es schon ein paar Mal geäußert: Ich habe den Verdacht, mit DX12 gibt es gar keinen exklusiven Vollbildmodus mehr und die Ausgabe läuft immer irgendwie über den DWM. Mit DX11 im exklusiven Vollbild geht die Bildausgabe direkt über den Treiber/Kernelgegenstelle, was dann auch 10 Bit Ausgabe ermöglicht.

[Foobar2001]

Das liegt an deinem Treiber, nicht an DWM. DWM kann sehr wohl 10 bit, GeForce-Karten nur nicht. Quadros schon.

Hmm, ok, aber warum dann kein Interprediction in HQ-Profilen?
Weil HQ auch nicht verlustlos ist und solange du die Residuals nicht verlustlos kodierst koennen schon mehr Artefakte entstehen.

[aufkrawall]

DWM kann sehr wohl 10 bit
Wo kann man das nachlesen?

[Foobar2001]

Was meinst du mit "wo kann man das nachlesen"? Wie glaubst du laeuft Photoshop im 10-Bit-Modus auf Windows 10 wo man DWM nicht abschalten kann?

Wenn du unbedingt eine Quelle brauchst: https://imagescience.com.au/knowledge/10-bit-output-support
January 2016 - The best advice currently on the PC is to use NVIDIA Quadro cards - these have much better drivers than the ATI cards. We recommend the K620 or ideally the faster M2000 based cards, as used in our Photoshop PCs. 10 bit is completely reliable with these setups in our experience, up to and including with Windows 10.

[aufkrawall]

Was meinst du mit "wo kann man das nachlesen"?

MSDN z.B.


Wie glaubst du laeuft Photoshop im 10-Bit-Modus auf Windows 10 wo man DWM nicht abschalten kann?

OpenGL Overlay.


Wenn du unbedingt eine Quelle brauchst: https://imagescience.com.au/knowledge/10-bit-output-support
Da steht nicht, dass der DWM mit 10 Bit läuft.

[Foobar2001]

Was soll bitte ein OpenGL-Overlay sein? Alles was im Fenstermodus laeuft geht mit aktivem DWM durch den Compositor, also muss auch der DWM-Framebuffer 10-10-10 sein. Nur exklusives Fullscreen hat die Moeglichkeit daran vorbei zu gehen.

Nochmal, Windows 10 koennte 10-bit-Farbe nicht unterstuetzen wenn DWM es nicht koennte.

MSDN z.B.
Link. Und zwar bezogen auf Windows 10. In Windows 7 war es tatsaechlich so, dass man DWM abschalten musste.

[aufkrawall]

Was soll bitte ein OpenGL-Overlay sein? Alles was im Fenstermodus laeuft geht mit aktivem DWM durch den Compositor, also muss auch der DWM-Framebuffer 10-10-10 sein. Nur exklusives Fullscreen hat die Moeglichkeit daran vorbei zu gehen.

Anscheinend nicht:
https://forums.adobe.com/thread/1190583
Offenbar unterstützt der Quadro-Treiber, ein vom DWM unabhängiges OGL-Rendering über dessen Compositing zu legen, wovon Photoshop für Bitrate >8 Gebrauch macht.


Nochmal, Windows 10 koennte 10-bit-Farbe nicht unterstuetzen wenn DWM es nicht koennte.

Ich gehe auch weiterhin davon aus, dass es das nicht kann.


Link.
Den solltest du ja liefern. Wo steht irgendwo ein Hinweis, z.B. in der MSDN, dass der DWM 10 Bit Ausgabe unterstützt?

[Foobar2001]

Anscheinend nicht:
https://forums.adobe.com/thread/1190583
Offenbar unterstützt der Quadro-Treiber, ein vom DWM unabhängiges OGL-Rendering über dessen Compositing zu legen, wovon Photoshop für Bitrate >8 Gebrauch macht.
PNY Quadro K4000
Dell U3011 via Displayport
Windows 7 x64
Photoshop CS6 x64
2560 x 1600 Desktop resolution
:rolleyes:

Ich gehe auch weiterhin davon aus, dass es das nicht kann.
Ich gehe weiterhin davon aus, dass die Erde eine Scheibe ist.

Den solltest du ja liefern. Wo steht irgendwo ein Hinweis, z.B. in der MSDN, dass der DWM 10 Bit Ausgabe unterstützt?
Ich bin dir ueberhaupt nichts schuldig. Ich weiss es.

[aufkrawall]

Oder du glaubst es zu wissen. Ist ja bezeichnend, dass offenbar im ganzen Internet nichts zu finden ist (oder doch?), was deine These unterstützen würde.

Edit. Ach, du erzählst eh Unfug. Erst soll es unmöglich sein, dass der Treiber den DWM umgeht, und jetzt ist das auf einmal egal. Deine Posts sind das allerunterste Niveau und offenbaren einen kaputten Charakter...

[Foobar2001]

Kannst du kein Englisch? "10 bit is completely reliable with these setups in our experience, up to and including with Windows 10"

Und nein, das ist nicht wegen "OpenGL Overlay". Es gibt kein "Overlay" mit WDM.

Microsoft hat angekuendigt, dass Windows 10 10-Bit-Farbe kann, ich bin mir sicher. Kannst du sicher googlen wenn du unbedingt musst.

NVIDIA und AMD beschraenken es auf ihre Workstation-Karten zur Marktsegmentierung. Das ist dein Problem.

[iuno]

Ich bin dir ueberhaupt nichts schuldig. Ich weiss es.
Was ist das denn? Warum schreibst du ueberhaupt noch was wenn du nichts erlaeutern willst? Es wurde doch ganz normal nach einer Quelle gefragt.
Ich benutze zwar kaum Windows und ein Monitor Upgrade steht auch nicht an, aber es wuerde mich halt trotzdem auch mal interessieren wie dort der Stand ist.

[Foobar2001]

Der Stand ist, du brauchst eine FirePro und Quadro und ein Display das 10-Bit kann und es funktioniert einwandfrei mit Windows 10.

[aufkrawall]

Es gibt kein "Overlay" mit WDM.

Du hältst dich ja für so allwissend :rolleyes: :
enable windowed overlay (Windows 7 and newer): [Disabled] Only available on Nvidia and Intel GPUs. Uses a low level overlay method which bypasses the GPU LUT (monitor profile) so madVR emulates it when using this option, this is done in 16-bit so madVR can provide better quality than the GPU. Overlay also bypasses the OS to a large extent; screen-shots are not possible. D3D9 Only.
https://forum.doom9.org/showthread.php?t=171787

[Foobar2001]

Das ist fuer Video und geht ueber steinaltes D3D9 (https://msdn.microsoft.com/en-us/library/windows/desktop/dd797814(v=vs.85).aspx)

Photoshop rendert seinen Main-View absolut garantiert nicht mit einem D3D9-Video-Overlay :ugly: