Farbräume (Tutorial) - erweiterte Erklärung und Zusammenhänge

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Farbräume (Tutorial) - erweiterte Erklärung und Zusammenhänge

      Anzeige
      Einleitung:

      Da hier im Forum sehr viele noch arge Probleme haben Farbräume, Farbmatrizen und Farbbereiche richtig zu Unterscheiden und auch oft Probleme haben den Sinn dahinter zu verstehen, werde ich mit diesem Thread hier euch eine kleine und hoffentlich verständliche Exkursion durchführen.

      Weiterführende Erklärungen:


      RGB Farbraum

      Fangen wir also mit dem Grundfarbraum an den jeder PC von Natur aus nutzt. Rot, Grün und Blau (RGB) sind die additiven Grundfarben dessen Mischung Magenta, Gelb und Cyan ergeben (Meist bei Druckern zu finden.)
      Additiv Farben werden deshalb verwendet weil sich es um Licht handelt. 0 Licht aus (schwarz), 255 Licht an (weiß)
      Bei der materiellen Mischung von Farben wird statt Grün Gelb verwendet. Daraus würde sich aber ergeben: 255 Licht aus (schwarz) und 0 Licht an (weiß)
      Man spricht daher auch über die negative bzw. subtraktive Farbmischung.

      Hier mal die negative (subtraktive) Farbmischung (Rot, Gelb, Blau)

      Und hier einmal die additive Farbmischung (Rot, Grün, Blau)



      Für jeden Farbkanal wie Rot, Grün oder Blau werden je insgesamt 8Bit verwendet, sodass man insgesamt auf 24Bit kommt. Das heißt das jede Farbe zu jedem Pixel separat gespeichert wird.
      z.B. sieht das dann im Binären so aus:

      01110100 11110000 00001111 = 116 (Rot) 240 (Grün) 15 (Blau) = Helles Grasgrün

      Und diese 24Bit erzeugen 1 Pixel

      Und so lässt sich auch die Dateigröße für RGB berechnen:
      24Bit / 8 = 3 Byte (1Byte pro Farbkanal also)

      640px * 480px * 3 Byte = 921600 Byte = 900 KByte

      Will man nun eine bestimmte Farbe später transparent gestalten, so fügt man dem 24Bit RGB ein weiteren Farbkanal hinzu. Den sogenannten Alphakanal.
      Der Alphakanal ist lediglich eine Maske bestehend aus einem Graubild. Dieser Alphakanal hat nix mit den RGB Kanälen zu tun, sondern ist ein Extra Kanal.
      Dieser Alphakanal sagt an was Transparent sein soll und das macht er mit Farbabstufungen.
      Schwarz (0) = 100% Transparent
      Grau (128) = 50 % Transparent
      Weiß (255) = 0% Transparent.

      Hier auch noch mal ein Beispiel dazu:

      Bei einer Aufnahme wie mit MSI Afterburner, DxTory und Konsorten in RGB32 ist der Alphakanal unbeschrieben. Sprich komplett Weiß. Da RGB32 im Idealfall mit einem Kompressionscodec gespeichert wird, ist aufgrund der Hervorragenden Kompression des Alphakanals die Datei fast genauso groß wie ein RGB24 Video.


      Und das war es schon von RGB. RGB ist sozusagen der native Farbraum der für jeden PC oder Konsole gilt.



      YUV Farbraum

      Der YUV Farbraum besteht anders als der RGB Farbraum aus Komponenten Kanälen. Das Ganze wurde anfangs für analoge Fernseher genutzt um somit die Bandbreite bei der Übertragung zu reduzieren.

      Die Komponenten bestehen aus:
      Y = Luminanz (kz.: luma; Lichtstärke pro Fläche bzw. Helligkeitsanteil)
      UV = Chrominanz (kz. chroma; Farbanteil)

      Den Chroma kann man noch aufteilen in:
      U = Farbanteil für Blau (wird oft auch als Pb/Cb abgekürzt (Pb = analog (0-1); Cb = digital (0-255)))
      V = Farbanteil für Rot (wird oft auch als Pr/Cr abgekürzt (Pr = analog (0-1); Cr = digital (0-255)))

      Um ein YUV Farbraum zu erzeugen benötigt man noch eine sogenannte Farbmatrix. Diese Farbmatrix gibt an in welcher Farbauswahl im UV Bereich der Farben das Bild laufen soll. Dafür gibt es vordefinierte Normen die man auch im Internet nachlesen kann.

      Da sie feststehen und wir ohnehin keine anderen verwenden können, da diese halt überall genormt sind, reicht es zu wissen das es bestimmte Farbmatrizen gibt.

      So z.B. BT.601, BT.709, BT.2020, GBR (RGB Matrix), OPP, FCC, YCgCo

      Auch wichtig für die Berechnung des YUV Farbraumes ist der Farbbereich. Für uns interessant ist lediglich der limitierte bzw. Begrenzte Bereich (TV Range) und der Vollbereich (PC Range)

      Und schon lässt sich ein RGB in YUV umrechnen.

      Aber wie funktioniert das Ganze?

      Im Grunde ganz einfach anhand von YPbPr. Man nehme die Farbmatrix einer Norm die man verwenden möchte und rechnet:

      z.B. sind die Matrix Koeffizienten von BT.601:
      Kr = 0.299
      Kb = 0.114
      Kg = 1 - Kr - Kb = 1 - 0.299 - 0.114 = 0.587

      Damit haben wir dann die Luminanz Matrix.

      Als einfaches Beispiel wird das Ganze an einer PC Range demonstriert

      Dabei muss der Luma (Y) insgesammt 1 ergeben und U und V müssen 0 ergeben.
      Dabei muss für U (Blauanteil) der Koeffizient für blau um 1 vermehrt werden und bei V (Rotanteil) der Koeffizient für rot um 1 vermehrt. Die anderen Anteile werden negiert um halt 0 zu erhalten.

      Das Ganze sieht dann so aus:

      Quellcode

      1. |Y| | 0.299 0.587 0.114 | | 0.299 0.587 0.114 |
      2. |U| = | -0.299 -0.587 (1 - 0.114) | = | -0.299 -0.587 0.886 |
      3. |V| | (1 - 0.299) -0.587 -0.114 | | 0.701 -0.587 -0.114 |
      Als nächstes muss die Scala für U und V zwischen -0.5 und 0.5 werden. Warum ist das so? Dazu stellt man sich am besten ein Kreis vor indessen Mitte sich Weiß befindet und der Umfang die Farben darstellen. Sprich wir haben jetzt mit dieser Scala von -0.5 und 0.5 die Mitte dieses Kreises und können somit alle Farben ansprechen:

      Quellcode

      1. Pb_diff = 0.5 / (1 - 0.114)
      2. Pr_diff = 0.5 / (1 - 0.299)
      3. |Y| | 0.299 0.587 0.114 | | 0.299 0.587 0.114 |
      4. |U| = | (-0.299 * Pb_diff) (-0.587 * Pb_diff) 0.5 | = | -0.168736 -0.331264 0.5 |
      5. |V| | 0.5 (-0.587 * Pr_diff) (-0.114 * Pr_diff) | | 0.5 -0.418688 -0.081312 |
      Jetzt könnte man diese 9 neuen Koeffizienten mit dem Farbbereich multiplizieren.

      Der Multiplikator ergibt sich aus:

      Quellcode

      1. RangeMin = 16
      2. RangeMax = 235
      3. Range = (RangeMax - RangeMin) / 255 = 219 / 255
      Man könnte es jetzt weiter spinnen und jedem Kanal von Y, U und V einen anderen Farbbereich geben. Aber in der Regel wird bei Aufnahmen eine einheitliche genommen, weshalb alles weitere entfällt.

      Also, wenn der Multiplikator 1 ergibt, dann haben wir den Vollbereich (PC Range) (siehe oben, den haben wir schon ausgerechnet)
      Und bei dem begrenzten Bereich wird 219 / 255 gerechnet wo dann der Multiplikator 0,858823..... ergibt

      Daher sieht die BT.601 Matrix im TV Bereich (16 - 235) so aus:

      Quellcode

      1. |Y| | 0.256788 0.504129 0.097906 |
      2. |U| = | -0.144914 -0.284497 0.429412 |
      3. |V| | 0.429412 -0.359579 -0.069833 |
      Und jetzt kommt die Magie daran ^^

      Eine Orange RGB Farbe (255, 128, 0) wird nun folgendermaßen in YUV gerechnet:

      Quellcode

      1. |Y| | 255 * 0.299 + 128 * 0.587 + 0 * 0.114 | | 151.380997 |
      2. |U| = | 255 * -0.168736 + 128 * -0.331264 + 0 * 0.5 | = | - 85.429474 |
      3. |V| | 255 * 0.5 + 128 * -0.418688 + 0 * -0.081312 | | 73.907936 |
      Um das ganze dann im YCbCr anzugeben (digitaler Wert zwischen 0 - 255) werden diese analogen Zahlen in digitale Ganzzahlen umgewandelt.

      Quellcode

      1. |Y | | 151.380997 | |Y | | 0 + int( 151.380997) | | 151 |
      2. |Pb| = | - 85.429474 | = |Cb| = | 128 + int(- 85.429474) | = | 42 |
      3. |Pr| | 73.907936 | |Cr| | 128 + int( 73.907936) | | 202 |
      So lässt sich jede Farbmatrix und mit jedem Farbbereich berechnen.
      Man kann auch anders zum Ergebnis kommen. Dazu findet man auf Wikipedia z.B. die Formeln. Der Weg über die Koeffizienten wie hier, ist aber der genauere.

      Siehe hier:


      Es lässt sich auch online nachprüfen:
      mikekohn.net/file_formats/yuv_rgb_converter.php

      Bedenkt das dies der PC Range ist.

      Die Werte sind andere, sobald es sich um eine TV Range handelt:

      Quellcode

      1. |Y | | 16 + int( 130.009445) | | 146 |
      2. |Cb| = | 128 + int(- 73.368683) | = | 54 |
      3. |Cr| | 128 + int( 63.473949) | | 192 |

      Dies kann man z.B. hier nachprüfen:
      picturetopeople.org/color_converter.html

      Je genauer die Werte, desto besser das Ergebnis. Je nachdem was für Werte genommen werden. Daher weichen die Ergebnisse meist um 1 Wert voneinander.

      Das Prinzip sollte damit nun aber klar sein.

      Damit wird RGB aufgespaltet in Luminanz und Chrominanz.

      Das hat einen absoluten Vorteil, denn nun ist es möglich den Chrominanz Bereich zu limitieren ohne das Gesamtbild damit zu verlieren.

      Und damit kommen wir zu...


      Farbunterabtastungen:

      Die Farbunterabtastungen besagt in welchen Schritten die Farbe abgetastet werden soll.
      Wir unterscheiden in native Farbunterabtastung und in interpolierte Farbunterabtastungen.

      Jeder hat es schon mal gesehen mit 4:4:4; 4:2:2; 4:2:0; 4:1:1 oder gar 4:0:0

      Das sind Bezeichnungen und auch gleich eine Aussagekräftige Art die Farbunterabtastungen zu kennzeichnen.

      Aber was ist das nun und warum interessiert das so ungemein?

      Wer schon mal mit MagicYUV nativ YUV 4:2:0 aufgenommen hat, wird gewiss schon mal festgestellt haben das bestimmte Bereiche Grau sind.
      Grund dafür ist das am jedem 2ten Pixel kein Chromapunkt definiert ist für diese Unterabtastung.

      Das sieht dann so aus bei MagicYUV:


      Bei einer Interpolation kommen Zwischenwerte dazu die von ein Pixel zum anderen berechnet werden
      Und das Ergebnis sieht dann so aus bei MagicYUV:



      Man kann aber ein natives 4:2:0 nicht in ein interpoliertes 4:2:0 umändern und umgekehrt auch nicht. Denn dies muss vor der Aufnahme bedacht werden.

      Wie muss ich mir denn nun das Ganze vorstellen?
      Auch das ist ganz leicht und kann sogar Bildlich gezeigt werden um den Sachverhalt zu erklären:


      So sieht eine reine native Farbunterabtastung Bildlich aus.

      Die Farbunterabtastung beschreibt aber auch die Größe eines Kanals.

      z.B.
      YUV 4:2:0 bei 640x480
      Y = 640x480
      U = 320x240
      V = 320x240

      oder YUV 4:2:2
      Y = 640x480
      U = 640x240
      V = 640x240

      Und bei 4:4:4 wäre jeder Pixel mit einer eigenen Farbe ausgestattet. Halt genau so wie bei RGB.

      Und bei 4:0:0 gibt es nur den Y Kanal noch, während U und V komplett leer sind. Ergo bekommt man ein Grau Bild. Weshalb Farbräume mit 4:0:0 auch GREY genannt werden. Bzw. auch Y8, weil 8Bit dem Y Kanal zugeschrieben sind. Und kein UV existent ist. ^^

      Hier ein Ausschnitt eines 4:2:0 Videos wie man sich das Bildlich vorstellen muss:

      Wenn man jetzt die realen Kanäle wieder mischen würde, würde das Original Bild wieder entstehen.

      Das Ganze hat natürlich auch Auswirkungen auf den Speicherbedarf und ganz klar auch auf das Banding (Farbverlauf).


      Banding (Farbverlauf) und die Farbtiefe

      Das Banding bzw. zu Deutsch Farbverlauf tritt dann ein wenn die Farbtiefe nicht ausreicht.
      Die Farbtiefe wird dabei in bpp (bit per pixel) angegeben. Sie definiert wie viele Farben genutzt werden.

      Klar zu erkennen an dieser Tabelle:



      Da die UV Farbunterabtastungen von 4:2:0 nur die Hälfte vom Y Kanal beträgt, wird der UV Anteil bei einer Interpolation auf die Größe des Y Kanals gezogen. Und somit hat man in der Regel auch nur 12bpp zur Verfügung. Das spart natürlich enorm an Speicherplatz.

      Bei 4:2:2 ist es dann 2/3 von 24bpp. Sprich 16bpp

      Bei 4:1:1 wären es 1/3 von 24bpp. Sprich 8bpp. Aber da der Y Kanal schon 8Bit belegt nutzt man wie auch bei 4:2:0 genauso 12bpp

      Das Banding selbst entsteht also durch niedrigere Farbtiefe und durch die Interpolation der Zwischenräume von niedrigeren Farbunterabtastungen.


      Das Banding lässt sich aber besser Handhaben bei einer 8zu10Bit Encodierung.

      Dabei wird z.B. das 24bpp auf 30bpp aufgestockt. Sprich jeder Kanal bekommt 2Bit extra hinzu und kann somit einen größeres Farbfeld nutzen. So das Insgesammt 30bpp erreicht werden können bei einer 10Bit Encodierung.

      Maximal kann man heute bis 16Bit bei Bildern encodieren was 48bpp ergibt
      Bei Videos ist man da nur bei 12Bit und würde somit auf 36bpp kommen.

      Je höher also der Farbraum, desto geringer wird das Banding.

      Das Banding lässt sich aber auch Retuschieren via. Dithering. Das Dithering soll dafür sorgen einen höhere Farbtiefe optisch vorzutäuschen.
      Dazu gibt es mehrere Verfahren und sollten den Bildbearbeitern bekannt sein: z.B. das Floyd-Steinberg Verfahren
      Aber ob nun via Diffusion oder normalen Dithern wird nicht nur die Farben reduziert, sondern auch, was die Verfahren machen sollen auch, richtig verteilt.

      Und jetzt was sehr sehr wichtiges:
      Einen niedrigen Farbraum in einen höheren zu stecken bringt einen absolut gar nix, denn der niedrige Farbraum kann nicht besser werden, da er nur wenige Informationen hat. Man kann wo nix ist, auch nicht einfach wieder was hinzaubern was dem Original entspricht.

      Dies ist sehr wichtig zu wissen, wenn man Skalieren möchte. Skalierer, vor allem Punkt Skalierer arbeiten mit niedrigen Farbräumen extrem schlecht. Denn wo wenig Infos sind, kann auch das Ergebnis nicht gerade toll aussehen. Aber ein höherer Farbraum kann viel besser skaliert werden und erbringt auch ein besseres Skalierungsergebnis.

      Das gilt für alle Skalierer. Extrem sind da Punktskalierer die idealerweise mit einem 4:4:4 Farbraum skaliert werden sollten.


      Das wars auch erst mal zum Thema Farbräume.

      Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von Sagaras ()

    • So, bin komplett durch! :D Fragen:

      1. Du hast geschrieben, dass jeder Farbkanal 8 bit spendiert bekommt, so ergeben sich 24 bit,
      und YUV4:4:4 dürfte dann der sein, der das voll ausreizt (24bpp). 4:2:2 hätte dann wieviel weniger pro Kanal? 8,4,4 = 16bpp?

      2. Was bedeutet, dass YUV 4:2:0 bei 640x480 im Chroma nur 320x240 liefert? Wie muss man sich das vorstellen? Es ist ja nicht das halbe Bild dann weniger farbkräftig, als die andere Hälfte.

      3. Interpolate when downsampling ist dann wahrscheinlich die Funktion, die bei YUV Nativ auf Interpolation umstellt. Du hast geschrieben, dass bei einer Interpolation Zwischenwerte hinzukommen und dass UV-Anteil bei einer Interpolation auf die größe des Y Kanals gezogen wird. Bezieht sich das auf die 8 bit?

      4. Wo besteht der Unterschied zwischen 4:4:4 und 4:2:2, wenn Interpolation die anderen Kanäle wieder auf die größe von Y zieht, wenn Y in beiden ja mit 4 identisch ist?

      5. Wie wäre 12 Bit encodierung möglich? Wir arbeiten mit MeGUI ja mit 10. Warum nicht 12?
      Mein Kanal:

    • Chron schrieb:

      1. Du hast geschrieben, dass jeder Farbkanal 8 bit spendiert bekommt, so ergeben sich 24 bit,
      und YUV4:4:4 dürfte dann der sein, der das voll ausreizt (24bpp). 4:2:2 hätte dann wieviel weniger pro Kanal? 8,4,4 = 16bpp?
      Hast es dir fast ausgerechnet. 8Bit (Y) 6Bit (U) und 2Bit (V) = 16Bit für YUV 4:2:2

      Bei YUV ist der Luminanz Kanal immer mit 8Bit ausgestattet. Weil das die Lichtdurchlässigkeit halt ist die für den Chroma nötig sind. Damit halt der Chrominanz Anteil jede Farbe richtig darstellen kann.

      Chron schrieb:

      2. Was bedeutet, dass YUV 4:2:0 bei 640x480 im Chroma nur 320x240 liefert? Wie muss man sich das vorstellen? Es ist ja nicht das halbe Bild dann weniger farbkräftig, als die andere Hälfte.
      Der Chrominanz Anteil ist bei 4:2:0 immer um die hälfte kleiner von der Auflösung her. Einfach weil die leeren Zwischenräume keine Informationen beinhalten. Daher kann man sie auch zusammenstauchen. Wo nix ist, kann nix verloren gehen.
      Die leeren Zwischenräume werden dann meist Interpoliert. Das heißt da kommen berechnete Zwischenergebnisse der Farben hinzu.
      Siehe dazu das große Bild wo ich Y, U und V Kanal geteilt habe.

      Das hat nix mit Farbkraft zu tun, sondern um die Farbanzahl, da die Zwischenwerte zum einen nicht existent sind und interpoliert werden in den häufigsten Fällen. Daher hast du auch nur die Hälfte an Farbinformationen noch da und das ergibt dann halt diese 12Bit insgesamt.
      8Bit (Y), 2Bit (U) und 2Bit (V) = 12Bit

      Chron schrieb:

      3. Interpolate when downsampling ist dann wahrscheinlich die Funktion, die bei YUV Nativ auf Interpolation umstellt. Du hast geschrieben, dass bei einer Interpolation Zwischenwerte hinzukommen und dass UV-Anteil bei einer Interpolation auf die größe des Y Kanals gezogen wird. Bezieht sich das auf die 8 bit?
      Dein gesamter Rechner arbeitet Bildlich gesehen immer mit 8Bit. Du kannst an deiner Grafikkarte auch nur max. 32Bit einstellen. 24Bit RGB + 8Bit Alphakanal. Damit funktionieren Spiele.
      Man kann sein Rechner auch auf 24Bit umstellen, aber dann würden viele Spiele streiken ihren Dienst aufzunehmen. Die Farbtiefe von deinem Rechner ist halt 24Bit. Mehr würdest du auch gar nicht sehen. Sprich 24Bit Encodierung mit 10Bit würden 30Bit ergeben und das würdest du einfach nicht sehen. Das sieht aber der Encoder in Form von Banding und das Ergebnis kann sich auf YT zeigen dann, weil YT wieder auf YV12 8Bit zurück geht. Hat YT aber das 30Bit Video als Original z.B., dann ist die YV12 8Bit Encodierung um einiges Besser was Banding angeht.
      Sprich sauberer.

      Chron schrieb:

      4. Wo besteht der Unterschied zwischen 4:4:4 und 4:2:2, wenn Interpolation die anderen Kanäle wieder auf die größe von Y zieht, wenn Y in beiden ja mit 4 identisch ist?
      Die Chromabereich zerläuft dann. Das zeigt sich dann auch in den Videos wieder. Einfach weil sie Interpoliert werden

      4:4:4 = 1:1 = 100% (Keine Verschmierung der Farben)
      4:2:2 = 2:3 = ~66% (Leichte horizontale Verschmierung der Farben)
      4:2:0 = 1:2 = 50% (Leichte horizon- und vertikale Verschmierungen der Farben)
      4:1:1 = 1:3 = ~33% (Große horizon- und leichte vertikale Verschmierungen der Farben)
      4:0:0 = 0:1 = 0% (Keine Farben)

      Und das sieht man nicht nur in der Aufnahme ein wenig, sondern bemerkt es gewaltig, wenn versucht wird mit einem niedrigen Farbraum die Auflösung skaliert wird. Die ganze Verschmierung würdest du somit mit hochskalieren. Und bekommst so am Ende reinen Matsch raus.

      Je besser die Farbunterabtastung, desto besser und sauberer kann skaliert werden.

      Chron schrieb:

      5. Wie wäre 12 Bit encodierung möglich? Wir arbeiten mit MeGUI ja mit 10. Warum nicht 12?
      A) Weil eine 8to10 Bit Encodierung dir eine Dateigrößenreduzierung bringt
      B) Je höher die Bit Anzahl wird, außer der "2Bit mehr"-Variation, würde die Datei größer machen. Weil an sich logisch: Je mehr Bit für ein Kanal benötigt werden, desto größer wird die entsprechende Datei. Sagt schon der logische Menschenverstand.

      Eine genauere Erklärung dazu hat der liebe TomKeller schon gemacht: board.gulli.com/thread/1693185…ormalen-und-10bit-videos/

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Sagaras ()

    • Ein paar anschauliche Beispiele bei der Skalierung wären nicht schlecht, um den praktischen Nutzen zu verdeutlichen und dein Argument anschaulich zu untermauern.

      Abgesehen davon nettes Tutorial, ich hätte wohl einiges bei der Umrechnung von YUV zu RGB weggelassen, weil es m.M.n. zu trocken und das Wissen für den reinen Anwender meist unnötig ist.
      Videoempfehlungen:
      ShimmyMC
      NuRap
      ShimmyMC
      Napoleon Bonaparte
    • RealLiVe schrieb:

      Abgesehen davon nettes Tutorial, ich hätte wohl einiges bei der Umrechnung von YUV zu RGB weggelassen, weil es m.M.n. zu trocken und das Wissen für den reinen Anwender meist unnötig ist.
      Trocken, ja. Unnötig, nein. Und es war lediglich RGB zu YUV und nicht umgekehrt. ^^

      Weil man mit dem AVISynth Plugin ManualColorMatrix (Link) seinen individuelle Farbmatrix somit erstellen kann um dann YUV zu erzeugen.

      Interessant für z.B. BT.2020 oder andere Exoten.

      Um ManualColorMatrix aber mit Werten zu füttern bedarf es der trockenen Rechnung. ^^ Weil es muss mit den 9 Matrixwerten genau gefüttert werden um halt das entsprechende Ergebnis zu bekommen.

      Sehr schönes und flexibles Plugin. ^^

      Das Wissen für den reinen Anwender ist dann interessant, sobald er vor dem Problem steht und nicht versteht wie es funktioniert.
      Das sollte halt alles mal etwas aufgeklärt werden, daher auch die Überschrift "erweiterte Erklärung und Zusammenhänge"
      Einfach das man das auch mal sieht was da eigentlich passiert wenn RGB nach YUV konvertiert wird.


      RealLiVe schrieb:

      Abgesehen davon nettes Tutorial, ich hätte wohl einiges bei der Umrechnung von YUV zu RGB weggelassen, weil es m.M.n. zu trocken und das Wissen für den reinen Anwender meist unnötig ist.
      Werde ich die Tage noch erstellen und einfügen. ^^
    • Sagaras schrieb:

      Das sollte halt alles mal etwas aufgeklärt werden, daher auch die Überschrift "erweiterte Erklärung und Zusammenhänge"
      Einfach das man das auch mal sieht was da eigentlich passiert wenn RGB nach YUV konvertiert wird.
      Wenn du den Anspruch hast, dann sollte der Rückweg - auch wenn m.M.n. selbsterklärend - der Vollständigkeit & Klarheit halber auch hinein und die Geschichte mit den Farbmatritzen etwas genauer beleuchtet werden, samt einiger praktischer Knackpunkte. Ich erinnere mich noch an die ein oder andere Frage, bei der die Farben im Arsch waren, weil mit Matrix A aufgenommen wurde, das Bearbeitungsprogramm aber mit Matrix B dekodiert hat.
      Videoempfehlungen:
      ShimmyMC
      NuRap
      ShimmyMC
      Napoleon Bonaparte
    • RealLiVe schrieb:

      Wenn du den Anspruch hast, dann sollte der Rückweg - auch wenn m.M.n. selbsterklärend - der Vollständigkeit & Klarheit halber auch hinein
      Hier nun der Rückweg von YUV -> RGB

      Gegeben sei ein YUV Farbraum mit BT.701 Matrix im PC Range:

      Quellcode

      1. |Y | | 0.2126 0.7152 0.0722 |
      2. |Cb| = | -0.115021 -0.386939 0.5 |
      3. |Cr| | 0.5 -0.455934 -0.046027 |
      Um RGB wieder herzustellen zu können müssen die Koeffizienten wieder rausgerechnet werden. Und dazu muss man den Kehrwert an sich anwenden. Sprich man muss von der Matrix den Kehrwert bilden. A -> A-1

      Das kann man bei einem 3x3 Feld relativ noch einfach machen in 3 Zwischenschritten (Um zu sehen was da eigentlich passiert):

      Die Einheitsmatrix für das 3x3 Feld entspricht diesem Muste

      Quellcode

      1. | 1 0 0 |
      2. | 0 1 0 |
      3. | 0 0 1 |
      Und so wird auch jeder Schritt gehen. Die 1 beschreibt dann die aktuelle Position bei der Umformung.

      Schritt 1:
      (x1;y1) auf 1 bringen indem es durch sich selbst geteilt wird. Das passiert mit der ganzen x1 Reihe und vermerken uns die Zwischenwerte (Z):

      y1
      y2
      y3
      x1
      0.2126
      0.7152
      0.0722
      x2
      -0.115021
      -0.386939
      0.5
      x3
      0.5
      -0.455934
      -0.046027
      Z
      -
      -3.364064
      -0.339605


      (Z;y1) = (x1;y1) / (x1;y1) = 0.2126 / 0.2126 (Entspricht 1. Das ist der Kehr Koeffizient)
      (Z;y2) = (x1;y2) / (x1;y1) = 0.7152 / 0.2126
      (Z;y3) = (x1;y3) / (x1;y1) = 0.0722 / 0.2126

      Die neue Matrix ergibt sich dann so:
      y1
      y2
      y3
      x1
      1 / 0.2126
      -3.364064
      -0.339605
      x2
      -0.115021 / 0.2126
      -0.386939 + (-0.115021 * -3.364064)
      0.5 + (-0.115021 * -0.339605)
      x3
      0.5 / 0.2126
      -0.455934 + (0.5 * -3.364064)
      -0.046027 + (0.5 * -0.339605)



      Schritt 2:
      Der nächste Punkt auf der Einheitsmatrix. Vorgang wiederholt sich wie im ersten Schritt, nur 2te Spalte Mitte.

      y1
      y2
      y3
      x1
      4.703669
      -3.364064
      -0.339605
      x2
      -0.541021
      -0.000001
      0.539062
      x3
      2.351834
      -2.137966
      -0.21583
      Z
      -543927.444
      -
      541957.93


      (Z;y1) = (x2;y1) / (x2;y2) = -0.541021 / -0.000001
      (Z;y2) = (x2;y2) / (x2;y2) = -0.000001 / -0.000001 (Entspricht 1. Das ist der Kehr Koeffizient)
      (Z;y3) = (x2;y3) / (x2;y2) = 0.539062 / -0.000001

      Damit ergibt sich die neue Matrix aus:
      y1
      y2
      y3
      x1
      4.703669 + (-3.364064 * -543927.444)
      -3.364064 / -0.000001
      -0.339605 + (-3.364064 * 541957.93)
      x2
      -543927.444
      1 / -0.000001
      541957.93
      x3
      2.351834 + (-2.137966 * -543927.444)
      -2.137966 / -0.000001
      -0.21583 + (-2.137966 * 541957.93)


      Schritt 3:
      Der letzte Punkt auf der Einheitsmatrix. Vorgang wiederholt sich wie im ersten und zweiten Schritt, nur 3te Spalte ganz rechts.
      y1
      y2
      y3
      x1
      1829811.44
      3382138.146
      -1823181.5
      x2
      -543927.444
      -1005372.712
      541957,93
      x3
      1162900.73
      2149452.675
      -1158687.84
      Z
      1.003636
      1.855075
      -


      (Z;y1) = (x3;y1) / (x3;y3) = 1162900.73 / -1158687.84
      (Z;y2) = (x3;y2) / (x3;y3) = 2149452.675 / -1158687.84
      (Z;y3) = (x3;y3) / (x3;y3) = -1158687.84 / -1158687.84 (Entspricht 1. Das ist der Kehr Koeffizient)

      Damit ergibt sich die neue Matrix aus:
      y1
      y2
      y3
      x1
      1829811.44 + (-1823181.5 * 1.003636)
      3382138.146 + (-1823181.5 * 1.855075)
      -1823181.5 / -1158687.84
      x2
      -543927.444 + (541957,93 * 1.003636)
      -1005372.712 + (541957,93 * 1.855075)
      541957,93 / -1158687.84
      x3
      1.003636
      1.855075
      1 / -1158687.84


      Damit hätten wir die entsprechende Kehrmatrix um YUV -> RGB zu wandeln.
      Kr
      Kg
      Kb
      R
      1.003086
      0
      1.573488
      G
      0.998716
      -0.187271
      -0.467734
      B
      1.003636
      1.855075
      0




      Man könnte jetzt noch relativ Großzügig sein und alle Werte in der Spalte Kr auf glatt 1 runden hier.


      Und jetzt lässt sich der RGB Wert aus einer YUV Farbe ermitteln
      Zuerst wird der Luminaz und auch der Chrominanz dem Wert entzogen und dann mit den Matrizen der RGB Wert wieder ausgerechnet.

      Als Beispiel YUV BT.709 PC Range Wert nehmen wir mal 146, 49, 197

      Jetzt der Rückweg um die Matrix zu entfernen um das RGB Signal wieder zu erhalten:

      Quellcode

      1. |R| | (146 - 0) * 1.003086 + (49 - 128) * 0 + (197 - 128) * 1.573488 |
      2. |G| = | (146 - 0) * 0.998716 + (49 - 128) * -0.187271 + (197 - 128) * -0.467734 |
      3. |B| | (146 - 0) * 1.003636 + (49 - 128) * 1.855075 + (197 - 128) * 0 |
      4. |R| | 255,021228 |
      5. |G| = | 128,333299 |
      6. |B| | - 0,020069 |
      7. Sind die Werte > 255, dann sind sie 255
      8. Sind die Werte < 0, dann sind sie 0
      9. Restliche Werte werden gerundet.
      10. |R| | 255 |
      11. |G| = | 128 |
      12. |B| | 0 |
      Alles anzeigen

      Wer sich nun mit anderen Werten noch beschäftigen sollte, wird feststellen das sich da Rundungsfehler einschleichen.
      ABER das Verfahren was ich euch hier gezeigt habe ist nur Ungefähr so wie das Ganze in der Praxis funktioniert.
      Ein Rechner wird das mit noch mehr Genauigkeit und ein paar wenigen Gesetzmäßigkeit viel genauer machen. Bei 6 Stellen nach dem Komma, werden sich da gewiss Fehler mit einschleichen. Das bleibt nicht aus.

      Sprich RGB -> YUV und auch YUV -> RGB Konvertierungen beherbergen Rundungsfehler.

      RealLiVe schrieb:

      und die Geschichte mit den Farbmatritzen etwas genauer beleuchtet werden, samt einiger praktischer Knackpunkte. Ich erinnere mich noch an die ein oder andere Frage, bei der die Farben im Arsch waren, weil mit Matrix A aufgenommen wurde, das Bearbeitungsprogramm aber mit Matrix B dekodiert hat.
      Ja, das wird aber mittlerweile seltener gemacht.

      Dabei geht es aber nicht um das Decodieren, sondern eher um das Encodieren.
      Und zwars ist es in der Let's Play Praxis meist so: BT.601 wird aufgenommen und wird dann in BT.709 verarbeitet

      Quasi man nimmt in einen eingeschränkten UV auf und bläht ihn auf. Und das Ergebnis stimmt dann nicht mehr so ganz, als es das mit BT.601 war.

      Alle Farben die im U und V Kanal sehr ausgeprägt sind, fallen bei dieser Art der Änderung am meisten auf.

      Sollte man nicht machen daher.

      Als Vergleich BT.601 vs BT.709 im TV Bereich (Würde sich im PC Bereich genauso verhalten):
      screenshotcomparison.com/comparison/177963

      Und hier ein paar andere Vergleiche:
      BT.601 on BT.709 vs BT.709 on BT.709 = BT.601 auf BT.709 Output = Farben verblassen etwas
      BT.601 on BT.601 vs BT.709 on BT.601 = BT.709 auf BT.601 Output = Farben verdunkeln sich etwas
      BT.601 on BT.601 vs BT.709 on BT.709 = Neutral

      Die häufigsten gravierendsten Probleme entstehen meist zwischen TV vs PC Range Aufnahme oder Verarbeitung des jeweils anderen.

      Videomaterial -> Ausgaberenderer = Ausgabe
      PC on PC = Neutral vs TV on PC = Matt
      PC on TV = Dunkel vs TV on TV = Neutral
      PC on PC = Neutral vs TV on TV = Neutral

      Die meisten machen hier schon was falsch und bekommen so Farbfehler und versuchen dann meist mit Sättigung oder Helligkeit oder Kontrast entgegen zu wirken. Was falsch ist. Einfach weil die Bereiche falsch gesetzt sind.

      Und viele schaffen auch folgende Sachen:
      Videomaterial -> Hinzufügen -> Ausgaberenderer = Ausgabe
      TV -> TV -> TV = Matt
      TV -> PC -> TV = Neutral (Üblicher Weg bei Schnittprogrammen wie Vegas, Premiere und Co., PC Range = RGB Farbraum in diesem Punkt)
    • Sagaras schrieb:

      Ja, das wird aber mittlerweile seltener gemacht.
      Ich hab mal Lagarith mit MagicYUV "verglichen" (in den Unterschiedlichen Einstellungen) und selbst auf RGB gabs unterschiede was bestimmte Türkis-Töne anging... ich weiß nicht welcher von beiden "schlechter" gerundet hat, aber ich habe auch nicht den aktuellsten MagicYUV hier installiert... zumindest wich der Türkis-Ton beim 1:1 Vergleich doch "deutlich" ab, war etwas heller und driftete mehr ins Grün...

      Weiß nicht ob das bei der Umrechnung oder so passierte, die Quelle war dabei jedoch egal, ob nun direkt aus der MP4 die ich aufgenommen habe oder über den "Umweg" mit Lagarith und "nur" YV12 war dabei egal, MagicYUV hat zwar nicht das Rot verschmiert wie Lagarith beim 2. "durchlauf" aber das Türkis ist mir deutlich aufgefallen...

      Gabs da mal nen Bugfix oder sowas in MagicYUV weswegen ich es updaten sollte? (Aktuell ist 1.0rc4 hier installiert)
      ——YouTube————————————————————————————————————————————
      — Endlos-Projekte: Minecraft (SinglePlayer), Craft The World, Banished, Besiege, Sims4
      — ..Abgeschlossen: Leisure Suit Larry 6+7, Dishonored, Surface 2+3, Mirrors Edge, uvm
      — . Kurz- Projekte: The Tower, Fighting Is Magic, Euro Truck Simulator 2, uvm
      — ......Retro-Ecke: Day Of The Tentacle, Flight Of The Amazon Queen, NFS: HP2, uvm
      ————————————————————————————————————————————TbMzockt.de—
    • TbMzockt schrieb:

      Gabs da mal nen Bugfix oder sowas in MagicYUV weswegen ich es updaten sollte? (Aktuell ist 1.0rc4 hier installiert)
      Da gab es schon diverse Bugfixes. MagicYUV gibt es bereits in der Version 1.2

      TbMzockt schrieb:

      Ich hab mal Lagarith mit MagicYUV "verglichen" (in den Unterschiedlichen Einstellungen) und selbst auf RGB gabs unterschiede was bestimmte Türkis-Töne anging
      Jein, da weicht eigentlich nix ab. Du hast bei deiner alten MagicYUV a) keine Interpolation integriert die von höheren auf nidriegere Farbräume geht. (Wurde in v1.2 hinzugefügt)

      Daraus kann es schon zum einen zu nicht korrektem Verhalten der Farben führen.

      Und zum anderen musst du bei Lagarith, MagicYUV mit BT601 zusammen testen, wenn du die YUV Farbräume nimmst.

      Und bei RGB gibt es kein Unterschied bei den Farben. Never. Das kannste gerne mehrmals testen.
    • YUV 4:2:0 ist die ausführliche Bezeichnung des Farbraumes. Dieser verbraucht 12 Bytes.

      Der Aufbau dessen ist Y V U
      Y = 8 Bytes
      V = 2 Bytes
      U = 2 Bytes

      Und nun 4:2:0 -> Y:V:U
      Die 0 kann weg bei der Bezeichnung
      Also: YV

      Und das es 12 Bytes benötigt pro Pixel und schon haste die Bezeichnung YV12

      die Bezeichnung 4:2:0 bezüglich des YUV Farbraumes betreffen den Bildaufbau.

      Und die Farbmatrizen wie BT.601 und BT.709 betreffen die Farben eines YUV Farbraumes.