Chroma-Subsampling

Chroma-Subsampling ist eine Kompressionstechnik, die Farbe (Chroma) mit geringerer Auflösung speichert als die Helligkeit (Luma). Sie nutzt eine gut dokumentierte Eigenheit des menschlichen Sehens aus: Wir sind bei kleinen Skalen weit empfindlicher für Helligkeitskontrast als für Farbkontrast.

Die Notation sieht aus wie 4:2:0, 4:2:2 oder 4:4:4. Die drei Zahlen beschreiben einen 4 Pixel breiten Referenzblock: wie viele Luma-Abtastwerte (immer 4), wie viele Chroma-Abtastwerte in der ersten Zeile, wie viele in der zweiten Zeile.

• 4:4:4 — kein Subsampling. Volle Farbauflösung. Verwendet für Grafiken, Bildschirmaufnahmen, überall dort, wo Kanten und Text zählen.
• 4:2:2 — Chroma bei halber horizontaler Auflösung. Verwendet in der professionellen Videobearbeitung.
• 4:2:0 — Chroma bei Viertelauflösung (halb horizontal, halb vertikal). Verwendet von JPG, MPEG, H.264, H.265, den meisten Consumer-Videos. Spart ~50 % der Chroma-Daten bei nahezu keinem wahrgenommenen Qualitätsverlust für Fotografien.

Wo 4:2:0 versagt: scharfe Farbkanten, besonders Text. Gesättigter roter Text auf gesättigtem blauem Hintergrund wird sichtbar unscharf. Deshalb sollten Screenshots PNG sein (kein Subsampling) und Fotografien können JPG sein (4:2:0 unsichtbar).

Durchgerechnetes Beispiel

Ein 1920×1080-RGB-Bild speichert 1920 × 1080 × 3 Byte = 6.220.800 Byte (~6 MB roh). Wandelt man es in YCbCr 4:4:4 um, ist die Größe identisch — 3 Kanäle bei voller Auflösung. Wandelt man in 4:2:2 um, fallen die Chroma-Kanäle (Cb und Cr) auf je 960×1080: Gesamtbytes = 1920·1080 (Y) + 960·1080·2 (Cb+Cr) = 2.073.600 + 2.073.600 = 4.147.200, eine Reduktion der rohen Ebenendaten um 33 %. Wandelt man in 4:2:0 um, fallen die Chroma-Ebenen auf je 960×540: gesamt = 2.073.600 + 1.036.800 = 3.110.400, genau 50 % des Originals. JPG, H.264, H.265, AVIF und WebP verwenden alle standardmäßig 4:2:0, weshalb ein JPG “50 % spart”, noch bevor irgendeine DCT-Kompression läuft — das Chroma-Subsampling liefert diese Grundlinie gratis.

Moderne Encoder passen das Subsampling manchmal pro Region an: AVIF und JPEG XL können innerhalb einer einzelnen Datei manche Bildregionen mit 4:4:4 und andere mit 4:2:0 codieren und tauschen einen kleinen Mehraufwand gegen scharfen Text auf fotografischem Hintergrund. Diese Flexibilität pro Kachel ist eine der strukturellen Verbesserungen gegenüber JPEGs Beschränkung auf ein einzelnes Format pro Datei.

Wann und warum es zählt

Subsampling zählt immer dann, wenn ein Workflow scharfe Farbkanten enthält, die 4:2:0 nicht darstellen kann — Screenshots von Code oder Terminaltext, Strichgrafiken mit gesättigten Farben, Logos mit reinem Rot auf reinem Blau, für das Archiv gerasterte Vektorexporte und jedes Bild, bei dem pixelgenaue Farbe an Kanten unverzichtbar ist. Die Lösung ist, ein Format zu wählen, das standardmäßig 4:4:4 nutzt (oder unterstützt): PNG (gar kein Subsampling), AVIF mit dem Encoder im erzwungenen 4:4:4-Modus (--yuv=444 in libavifenc), JPEG XL oder modernes WebP verlustfrei. Der umgekehrte Fehler — PNG für ein 12-Megapixel-Foto zu verwenden, weil “PNG höhere Qualität hat” — verschwendet 80 %+ der Dateigröße auf Chroma-Informationen, die der Betrachter nicht wahrnehmen kann. Die professionelle Faustregel: Fotografien → JPG/WebP/AVIF 4:2:0; UI-Screenshots → PNG oder AVIF 4:4:4; gemischte Inhalte → beides testen und das Ergebnis bei 200 % Zoom rund um jeden Text inspizieren. Referenz: Chroma subsampling — formats and notation.

Warum das menschliche Sehen uns das durchgehen lässt: Die Netzhaut hat etwa 120 Millionen Stäbchen (empfindlich für Helligkeit, keine Farbinformation) und nur 6 Millionen Zapfen (zuständig für Farbe). Das 20-zu-1-Verhältnis ist der biologische Grund, warum Chroma-Subsampling funktioniert — jeden zweiten Chroma-Abtastwert zu verlieren ist für die meisten Betrachter unsichtbar, während der Verlust jedes zweiten Luma-Abtastwerts offensichtliche Posterisierung erzeugt. Dasselbe Prinzip liegt dem von JPG und jedem Video-Codec verwendeten YCbCr-Farbraum zugrunde: den wichtigsten Kanal (Y, Luma) von den beiden weniger wichtigen (Cb, Cr, Chroma) zu trennen, sodass jeder unterschiedlich abgetastet werden kann.

Das Terminal-Bildschirm-Gegenbeispiel: Programmierer, die 4:2:0-H.264-Screencasts von Code ansehen, beklagen regelmäßig, dass Text weich aussieht. Die Lösung ist entweder, auf einen 4:4:4-fähigen Codec aufzurüsten (FFV1, HuffYUV verlustfrei oder H.264 im 4:4:4-Modus — von Chrome und OBS unterstützt, aber nicht von YouTubes Standard-Transcode) oder in höherer Auflösung aufzunehmen, sodass das Herunterskalieren bei der Wiedergabe die Chroma-Artefakte verbirgt. Für nicht-textuelle Inhalte (Gameplay, Talking-Head-Video, Animation) ist 4:2:0 durchweg in Ordnung. Verwandt: sRGB, Gamma, WebP. Referenz: ITU-T T.871 — JPEG file interchange format (JFIF).