Gamut Clipping: Warum deine Farben zerdrückt werden

Erzeuge eine zehnstufige blaue Farbrampe, dreh das Chroma hoch, damit die Markenfarbe leuchtet, und liefere sie aus. Was der Bildschirm zurückgibt, ist auf subtile Weise falsch: der blasseste Ton driftet Richtung Cyan, die dunkelsten Stufen fallen zu Beinahe-Duplikaten zusammen, und das tiefste Blau kippt ins Violette. Niemand hat sich vertippt. Mehrere der angeforderten Farben lassen sich auf einem sRGB-Bildschirm schlicht nicht darstellen, und die Umrechnung, die sie zurück in den darstellbaren Bereich zwang, hat sie zerdrückt.

Gamut Clipping ist das, was passiert, wenn eine Farbe in deinem Farbmodell existiert, aber nicht auf dem Display: Der Wert wird zurück in den Farbraum (Gamut) des Bildschirms gezwungen, und die grobe Standardmethode — jeden RGB-Kanal einzeln zu kappen — verschiebt Farbton und Helligkeit zusammen mit dem Chroma und macht aus der Farbe eine andere Farbe statt einer leiseren. Es gibt zwei Abhilfen: sauberes Gamut Mapping, wenn eine außerhalb des Bereichs liegende Farbe umgerechnet werden muss, und das Erzeugen von Paletten mit Spielraum, sodass gar keine Stufe erst den Farbraum verlässt. Beides ist in OKLCH leichter zu sehen — dieser Artikel ist Teil unseres OKLCH-Leitfadens, in dem das Modell selbst vorgestellt wird.

Was bedeutet „außerhalb des Farbraums”?

Ein Farbmodell ist ein Adressierungsschema, und Adressen können ins Leere zeigen. OKLCH akzeptiert Helligkeit 0,65, Chroma 0,25, Farbton 262,9 ohne zu murren — eine wohlgeformte Koordinate, die kein sRGB-Bildschirm darstellen kann. Der Farbraum (Gamut) ist die Menge der Farben, die ein Gerät oder Farbraum tatsächlich reproduzieren kann, und er ist ein endliches, unregelmäßiges Volumen, das im viel größeren Koordinatenraum des Modells liegt.

Am einfachsten stellt man sich die Grenze als eine Chroma-Obergrenze vor, die von der Helligkeit abhängt. Nahe Weiß und nahe Schwarz gibt es fast keinen Platz für Buntheit; die Obergrenze erreicht ihren Höhepunkt in den Mitteltönen. Bei Farbton 262,9 — dem Farbton des Blaus #2563eb, das oklch(0.546 0.215 262.9) ist — verläuft die sRGB-Obergrenze so:

Ein Zelt, keine Wand: hoch in der Mitte, an beiden Enden zusammengeschnürt. Jede Anforderung oberhalb der Fläche liegt außerhalb des Farbraums, und irgendetwas muss nachgeben.

Was macht naives Clamping mit einer Farbe?

Die billige Umrechnung kappt jeden RGB-Kanal an seinem Maximum. Fordere oklch(0.65 0.25 262.9) an, und die Rechnung erzeugt einen linearen Blaukanal bei ≈1,36 — 36 % über dem, was der Bildschirm hat. Kappe jeden Kanal in den Bereich, und du landest bei #3480ff, was zurückgelesen ≈ oklch(0.622 0.204 260.4) ergibt.

Vergleiche Anforderung und Ergebnis: Die Helligkeit sank um ≈0,028, das Chroma um ≈0,046, und der Farbton drehte sich um ≈2,5° Richtung Cyan. Nur das Chroma war im Überschuss, und trotzdem bewegten sich alle drei Achsen — weil das Kappen pro Kanal in RGB arbeitet, ohne eine Vorstellung davon, was die drei Kanäle gemeinsam bedeuten.

Sauberes Gamut Mapping hat diese Vorstellung sehr wohl: Halte Helligkeit und Farbton fest und reduziere das Chroma, bis die Farbe zurück über die Grenze in den Bereich rutscht. Dieselbe Anforderung wird auf oklch(0.65 ≈0.186 262.9) abgebildet — etwa #4f89ff — eine sichtbar leisere Version desselben Blaus.

Der perzeptive Grund, warum der Unterschied zählt: Das Auge verzeiht eher „weniger bunt” — es liest sich als dieselbe Farbe, gedämpft — aber eine Farbton-Verschiebung liest sich als eine andere Farbe. Chroma ist Volumen; Farbton ist Identität. Naives Clamping tauscht Identität gegen Volumen, und es wird umso brutaler, je weiter draußen die Anforderung liegt. Fordere einen fast weißen Blauton bei Chroma 0,22 an (die Obergrenze liegt dort bei ≈0,024), und das Clamping landet bei #9ee9ff — Farbton ≈218, ganze 45° entfernt. Der Blauton wird als Cyan ausgeliefert.

Warum werden Farbrampen flach, statt einfach nur gedämpft zu werden?

Eine einzelne zerdrückte Farbe ist ein punktueller Defekt. Paletten scheitern systematischer, denn eine Farbrampe fordert Chroma über viele Helligkeiten hinweg an, während die Obergrenze darunter variiert. Überall dort, wo die Anforderung zu hoch schießt, wird jede überschießende Stufe gegen dieselbe Grenze gepresst — und Stufen, die sich unterscheiden sollten, kommen nahezu identisch an.

Zahlen vom dunklen Ende einer blauen Farbrampe, angefordert bei konstantem Chroma 0,28, mit Stufen im Abstand von 0,05 in der Helligkeit:

Der angeforderte Abstand betrug 0,05 in der Helligkeit; der gelieferte Abstand liegt bei ≈0,021–0,025 — weniger als die Hälfte und genau an der Schwelle eines gerade noch wahrnehmbaren Unterschieds. Rund 0,02 L ist ungefähr der Punkt, an dem zwei benachbarte Farbfelder aufhören, sich klar unterscheidbar zu lesen — weshalb Scale Composer eine Warnung auslöst, sobald zwei benachbarte Stufen näher als das landen. Beachte, dass auch die Farbton-Spalte von ≈264 auf ≈269 driftet: Das flachgedrückte Band ist nicht einmal ein einheitliches Blau.

Das ist das tote Band aus dem Eingang — kein Rendering-Bug, nur mehrere Stufen, die sich einen Zaun teilen.

Wie erzeugt man eine Palette, die niemals clippt?

Indem man die Obergrenze als Eingabe behandelt statt als Zufall. Die Lösung auf der Erzeugungsseite heißt Spielraum: Bei jeder Helligkeit kappt man das angeforderte Chroma leicht unter der Farbraum-Obergrenze, sodass keine Stufe je überhaupt gekappt werden muss.

So baut Scale Composer Skalen von Haus aus: Stufen werden auf einer Helligkeitskurve platziert, das Chroma folgt einem glockenförmigen Profil mit einem Mindestwert — großzügig in den Mitteltönen, wo die Obergrenze hoch ist, und zu den Enden hin auslaufend, wo sie niedrig ist — und das Profil wird bei der Helligkeit jeder Stufe knapp unter der Obergrenze gekappt. Die kräftige Mitte bleibt kräftig, die blassen und dunklen Enden behalten ihre Identität, und jeder Wert, der herauskommt, war von Anfang an darstellbar.

Öffne die Obergrenzen-Ansicht in Scale Composer — dieselbe blaue Ausgangsfarbe, bei der das Chroma jeder Stufe knapp unter der sRGB-Obergrenze mitläuft, während es über die Farbrampe steigt und fällt. Zieh das Chroma nach oben, und du siehst, welche Stufen zuerst clippen würden.

Behebt Display-P3 das Gamut Clipping?

Es verschiebt den Zaun; es entfernt ihn nicht. Display-P3 — der weitere Farbraum auf den meisten aktuellen Smartphones und Macs — hebt die Chroma-Obergrenze am stärksten dort an, wo Farbe ohnehin lebt: bei Farbton 262,9 beträgt der Zuwachs nahe Weiß nur ≈0,003, aber rund um Helligkeit 0,45–0,50 sind es ≈0,05 (von ≈0,225 hinauf auf ≈0,276). Mitteltonstufen, die gegen die sRGB-Obergrenze gepresst saßen, bekommen echten Raum zum Atmen.

Die Disziplin bleibt allerdings dieselbe: P3 hat seine eigene Obergrenze, und eine Anforderung jenseits dieser clippt genauso schlimm. Das Erzeugen mit Spielraum gegen die P3-Grenze ist derselbe Algorithmus unter einer höheren Fläche. Im P3-Modus von Scale Composer trägt jede Stufe einen color(display-p3 …)-String für Bildschirme, die ihn nutzen können, während die hex-Spalte sRGB-gekappt bleibt — Fallback und Erweiterung, erzeugt von einer Skala, statt von Hand gepflegt.

Sieh die Entlastung dort, wo sie ankommt

Schalte dieselbe blaue Farbrampe in den P3-Modus und beobachte, wie die Mitteltonstufen den neuen Spielraum aufnehmen: Das Chroma steigt genau dort, wo früher der sRGB-Zaun drückte, Helligkeit und Farbton bleiben stehen, und die blassen Enden bewegen sich kaum. Sobald du die Obergrenze als Kurve gesehen hast — etwas, unter dem eine Palette entlangfährt, statt dagegen zu krachen — hört Gamut Clipping auf, ein mysteriöser Rendering-Bug zu sein, und wird zu dem, was es immer war: eine Anforderung, die der Bildschirm nie erfüllen konnte, abgefangen zur Erzeugungszeit statt am Auslieferungstag entdeckt.