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

  • 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
  • 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.