blend-mode = "saturation" - Ich kapiere es nicht.

[Rolf B]

Hallo alle,

ich möchte einen HSL Farbkreis so modifizieren, dass die Farben darin zur Mitte hin ihre Sättigung verlieren. Eigentlich also das, was ich hier gezeigt habe - aber ich möchte das Selbermalen des Farbkreises vermeiden und dachte, ich könnte den conic-gradient des Farbkreises mit einem radial-gradient überlagern und dabei einen Überblendmodus einsetzen, der die Sättigung herausnimmt.

Das Ergebnis sollte dann so aussehen ("handgemalt" im Canvas):

Das sollte nach meinem Verständnis mit background-blend-mode: saturation gehen, wenn ich die beiden folgenden Bilder überblende. Links ein Farbkreis mit grauem Zentrum (20px Radius, erstellt durch Überlagerung eines konischen Gradienten mit einem Radialgradienten, der ab 20px transparent ist), rechts ein Radialverlauf mit einem Innenraum, der 0% Sättigung hat (20px Radius, wie links) und 100% außen. Bei Überblendmodus "saturation" sollte die Farbe der Sättigungsmaske wurscht sein.

Auf CSSisch gesprochen, sieht es so aus:

canvas, div {
  display: inline-block;
  width: 200px;
  aspect-ratio: 1/1;
  border-radius: 50%;
  outline: 1px solid black;
}
div {
  --conic: radial-gradient(
               circle at center,
               #808080 20px, transparent 20px),
           conic-gradient(red, yellow, lime, 
               cyan, blue, magenta, red);
  --radial: radial-gradient(
               circle closest-side at center,
               #808080 20px, #ff0000);
}
div:nth-child(1) {
  background: var(--conic);
  background-blend-mode: normal;
              
}
div:nth-child(2) {
  background: var(--radial);
}

Dass sich das Farbrad mit in hsl longer hue, red, red einfacher erstellen lässt, weiß ich, aber der Fuchs versteht das nicht und für den springe ich ja hier durch den Stöckchenwald.

Ja. Und dann kommt das dritte div, das beides zusammenfügen soll:

div:nth-child(3) {
  background: var(--radial), var(--conic);
  background-blend-mode: saturation, normal;
}

Das Ergebnis sieht im Vergleich mit der Wunschvorstellung so aus: 🤮 (JSFiddle dazu)

Mal zu hell, mal zu dunkel, sowohl in Chrome wie auch in Firefox - was läuft da falsch mit diesem Überblendungsmodus? Das Fiddle zeigt die Quellen, den CSS-Mix und die durch Ringe erzeugte Wunschvorstellung im Canvas - im Fuchs natürlich kaputt.

Oder verstehe ich diesen Überblendmodus nur nicht? Das ist nämlich kein alleiniges CSS Problem - wenn ich im Canvas die globalCompositeOperation auf "saturation" setze und die CSS-Gradienten im Canvas male, passiert exakt das gleiche. Ich habe ein Fiddle gemacht, das genau das tut: https://jsfiddle.net/Rolf_b/cf8y0ghx/. Mit einem Mouseover kann man die Farbwerte erkunden (rgb2hsl aus dem Wiki-Farbwähler). Man sieht, wie die L-Werte wild herumspringen, obwohl sie in beiden Quell-Bitmaps bei 50% bleiben.

Ist dieser Überblendmodus einfach kaputt? MDN schreibt: saturation nimmt Hue und Lightness der unteren Bitmap sowie die Saturation der oberen Bitmap und baut das zur Ergebnisfarbe. Jedoch…

Rolf

[Camping_RIDER]

Aloha ;)

Hm. Ich bin leider 0 drin im HSL-Game und kann dir daher nicht ganz genau sagen, was da nicht funktioniert oder ob in deinem ursprünglichen Gedanken ein Denkfehler drin ist.

Allerdings habe ich das, was du suchst (glaube ich?) ganz anders hinbekommen, völlig ohne blend-mode, nur mit Transparenz:

--> Hier mein geforktes JSFiddle

Ob das jetzt dein Problem löst, weiß ich nicht.

Jedenfalls habe ich mir das mit dem blend-mode saturation auch nochmal angeschaut, und dieses weitere geforktes JSFiddle ist in diesem Zusammenhang interessant.

Ich habe im Vergleich zu deinem lediglich den Gradienten --radial mit hsl-Definition der Farben geschrieben. Damit kann man testen, ob das...

MDN schreibt: saturation nimmt Hue und Lightness der unteren Bitmap sowie die Saturation der oberen Bitmap und baut das zur Ergebnisfarbe.

...stimmt. Denn nach dieser Beschreibung dürfte es keinen Unterschied machen, wenn man den Lightness-Wert der oberen Bitmap verändert - tut es aber. Geht man von 50% auf 20%, so ändert sich das Ergebnis, und das dürfte es nach der MDN-Beschreibung nicht, zumindest nicht nach dem wie ich sie verstehe. Ergo ist diese entweder missverständlich oder falsch - oder es gibt noch einen weiteren Faktor, den ich aktuell übersehe.

Grüße,

RIDER

[Camping_RIDER]

Aloha ;)

Hmja. Ich habe mir nochmal Gedanken gemacht. Es gibt mehrere Probleme. Und ich sag jetzt besser nicht wie lange ich für die Recherche gebraucht habe.

---

Ich fang mal mit dem unwichtigsten an:

Links ein Farbkreis mit grauem Zentrum

Das ist streng genommen Quatsch. Was soll das graue Zentrum dort? Ich hab mittlerweile den verlinkten Thread auch angelesen und verstehe, dass da die „lightness“-Stange durch soll in der Visualisierung, aber das ist eigentlich ziemlich egal. Man müsste das, was du suchst, auch ohne diesen fixierten grauen Kreis hinbekommen, denn innendrin müssts ja grau sein wegen konstant geringem „saturation“-Wert und das liefert ja die Maske, also muss dein Problem auch ohne den Kreis in der Mitte im Source-Bild lösbar sein.

---

Dann das andere, was ich hier schon angeschnitten habe. Eigentlich dürfte laut der Beschreibung in der MDN (und übrigens auch laut der Beschreibung in der Spec!) eine Veränderung des lightness-Wert in der Maske genau so keine Rolle spielen wie es eine Veränderung des hue-Wert tatsächlich auch nicht tut.

Die Spec schreibt:

Creates a color with the saturation of the source color and the hue and luminosity of the backdrop color. Painting with this mode in an area of the backdrop that is a pure gray (no saturation) produces no change.

Und da stolpere ich über den Begriff „luminosity“. „Luminosity“? Ist das synonym zu lightness, oder eben genau nicht? Ich weiß es nicht, ich kenne mich ehrlich nicht gut genug aus, aber mir schwant da übles. Oder, wie es die englische Wikipedia schreibt:

While the definition of hue is relatively uncontroversial – it roughly satisfies the criterion that colors of the same perceived hue should have the same numerical hue – the definition of a lightness or value dimension is less obvious: there are several possibilities depending on the purpose and goals of the representation.

Und zack - damit wäre mein Missverständnis gelöst. Das L in HSL ist, da bin ich mir mittlerweile zu 90% sicher, nicht das L, das die Spec mit Luminosity meint.

Ich argwöhne mittlerweile ziemlich sicher, dass der Saturation Blendmode durchaus das tut was er soll, dass die Maske dafür aber eben nicht im hsl-Modell zu denken ist.

Und nachdem ich jetzt wusste was vermutlich das Problem ist, habe ich dann auch einen Stackoverflow-Thread gefunden, der mich darin bestätigt.

Money Quote:

The name of the function and it's usage might have you assume that they're referring to the Luminance that is sometimes ascribed to the L in HSL, or the B or V in HSB/HSV. They're not. This function is used to determine the relative brightness of a color to the human eye. It comes from the YIQ colorspace

Brainfuck.

Also: die color-blend-modes sind effektiv für den Popo (zumindest meiner Schlussfolgerung nach. Nicht, weil sie nicht funktionieren, sondern weil sie so funktionieren wie sie funktionieren sollen und weil das wie sie funktionieren sollen überhaupt nicht mit allem anderem zusammenpasst was im Web so passiert.

Irgendwo auf dem Weg in meiner Recherche habe ich gelesen (zumindest meine ich das gelesen zu haben, finden tu ich es aktuell nicht), dass Adobe in die Entwicklung der Blend-Modes für die CSS-Spec involviert war.

Sicher eine gute Idee, wenn man sich mal klar macht, dass Adobe z.B. in Photoshop HSV verwendet während man sich in CSS für HSL entschieden hat.

Ich kann nur vermuten, dass dieser Irrsinn daher kommt, dass Adobes Photoshop so weit verbreitet ist und man nun wollte, dass die CSS Blend Modes genauso funktionieren wie Blend Modes in Photoshop. Man hat also die Photoshop-User priorisiert gegenüber Webentwicklern, die jetzt irgendwie mit dem Scherbenhaufen umgehen müssen, statt direkt ein blendmode-System zu entwickeln, das im HSL-Farbraum arbeitet und den Webentwicklern entgegenkommen würde.

---

Zusammenfassung: Blend-Mode Saturation funktioniert „as intended“, ist aber völlig ungeeignet um damit HSL-Farben zu manipulieren.

Für den Zusammenbau für deine Zwecke sollte das, was ich oben gepostet habe aber trotzdem funktionieren. Die Überlagerung mit einem teiltransparenten Radialgradienten erzeugt ja letztlich genau das was du für die Visualisierung brauchst - oder übersehe ich da was? Für höhere l-Werte musst du wahrscheinlich ein Grau mit höherem l-Wert nehmen, damit das alles noch zusammenpasst, aber das sollte ja machbar sein.

Wo genau und wie genau schreiben wir jetzt ins Wiki, dass die blend-modes hue/saturation/color/luminosity nicht das tun, was sie auf den ersten Blick versprechen? (Die Popo-Formulierung war vielleicht etwas harsch...)

Grüße,

RIDER

[Matthias Scharwies]

Servus!

Aloha ;)

Hmja. Ich habe mir nochmal Gedanken gemacht. Es gibt mehrere Probleme. Und ich sag jetzt besser nicht wie lange ich für die Recherche gebraucht habe.

---

Ich fang mal mit dem unwichtigsten an:

Links ein Farbkreis mit grauem Zentrum

Das ist streng genommen Quatsch. Was soll das graue Zentrum dort? Ich hab mittlerweile den verlinkten Thread auch angelesen und verstehe, dass da die „lightness“-Stange durch soll in der Visualisierung, aber das ist eigentlich ziemlich egal. Man müsste das, was du suchst, auch ohne diesen fixierten grauen Kreis hinbekommen, denn innendrin müssts ja grau sein wegen konstant geringem „saturation“-Wert und das liefert ja die Maske, also muss dein Problem auch ohne den Kreis in der Mitte im Source-Bild lösbar sein.

Ich schrub am 21.12.:

Ich denke aber trotzdem, dass die Scheibe nicht zwei Parameter visualisieren sollte. Sie ist für den hueda - für die Sättigung sollte man meiner Meinung nach eine weitere Achse oder eben eine „Lupe“ haben.

Das würde ich gerne am Stammtisch am 03.01. (morgen) mit allen Interessierten besprechen.

Wo genau und wie genau schreiben wir jetzt ins Wiki, dass die blend-modes hue/saturation/color/luminosity nicht das tun, was sie auf den ersten Blick versprechen? (Die Popo-Formulierung war vielleicht etwas harsch...)

Das ist auch unsere Frage. hwb() ist bis jetzt noch nirgendwo erwähnt. Der Vollständigkeit halber wohl am Besten in einer Unterseite von CSS/Funktionen/hwb(), Farbe/Farbmodelle sollte wohl eher nur die gängigen Farbmodelle und Noierungen beschreiben; rgb(), HEX und hsl(), sowie dann oklch().

Da müssen wir einen Konsens finden.

Herzliche Grüße

Matthias Scharwies

[Camping_RIDER]

Aloha ;)

Ich schrub am 21.12.:

Ich denke aber trotzdem, dass die Scheibe nicht zwei Parameter visualisieren sollte. Sie ist für den hueda - für die Sättigung sollte man meiner Meinung nach eine weitere Achse oder eben eine „Lupe“ haben.

Das würde ich gerne am Stammtisch am 03.01. (morgen) mit allen Interessierten besprechen.

Das sehe ich allerdings schon so wie Rolf - Ich denke, dass die Scheibe mit zwei Parametern einen Sinn hat. Die Idee mit der weiteren Achse bzw. der Lupe kann ich mir jetzt nicht so richtig vorstellen. Ich denke im interaktiven Beispiel fehlt eigentlich nur ein Punkt innerhalb der markierten Halbgerade auf der Scheibe, der mit Saturation nach innen oder außen wandert.

@Edit: Keine Ahnung ob das schon jemand vorgeschlagen hat, aber so wie der Saturation-Schieberegler eine Vorschau mit den aktuellen hue/lightness-Werten zeigt, sollte auch der hue-Schieber eine Vorschau mit dem aktuellen Saturation/Lightness zeigen, und entsprechend der Lightness-Schieber auch... Dann hat man nämlich zwei vollständige Visualisierungen in einem - die Schieber und die grafische Darstellung, und kann genau nachvollziehen wie das eine das andere verändert...

Wenn die Scheibe nur noch einen Parameter zeigen soll, dann hat sie als Scheibe keine richtige Berechtigung. Eine Scheibe ist ja ein zweidimensionales Objekt, hat also zwei Achsen, warum soll sie dann keine zwei Parameter visualisieren? Außerdem geht die Darstellung durchaus Hand in Hand mit anderen populären Visualisierungen, z.B. hier.

Was ich mir da alternativ noch vorstellen könnte ist, statt der Scheibe einen dünnen Ring zu zeigen, der je nach Saturation einen größeren oder kleineren Durchmesser hat. Das ist aber nichts anderes als die zweidimensionale Scheibe mit zwei Parametern, nur, dass man sie nicht mehr komplett sondern nur noch ausschnittsweise sieht.

Ich bin leider morgen bereits anderweitig terminlich gebunden (zusammen mit @Felix Riesterer in Aventurien), so dass ich zum Stammtisch nicht da sein kann um das live zu diskutieren.

Wo genau und wie genau schreiben wir jetzt ins Wiki, dass die blend-modes hue/saturation/color/luminosity nicht das tun, was sie auf den ersten Blick versprechen? (Die Popo-Formulierung war vielleicht etwas harsch...)

Das ist auch unsere Frage. hwb() ist bis jetzt noch nirgendwo erwähnt.

Es ist ja noch schlimmer: Die blend-modes sind ja weder hsl noch hwb, zumindest wenn ich die Berechnungen richtig verstanden habe... hwb ist zwar intuitiver als hsl, aber die luminosity aus den blend-modes ist weder das white noch das black aus hwb, und auch nicht das s und l aus hsl. Das ist ja der Murks. Die Blend-Modes funktionieren wie in Photoshop, aber nicht wie sonst was.

Da müssen wir einen Konsens finden.

Ja.

Der Vollständigkeit halber wohl am Besten in einer Unterseite von CSS/Funktionen/hwb(), Farbe/Farbmodelle sollte wohl eher nur die gängigen Farbmodelle und Noierungen beschreiben; rgb(), HEX und hsl(), sowie dann oklch().

Hm. Wenn man aus der Bildbearbeitung kommt oder mit GIMP aufgewachsen ist, dann ist hwb intuitiver und viel bekannter als hsl. Insofern wird das wohl noch zu besprechen sein, welches denn die gängigen Farbmodelle sind (das bemisst sich ja nicht nur daran, was häufig verwendet wird, sondern auch daran, wie eingängig die Notation ist). Ich könnte mir vorstellen, dass Leser sich freuen, wenn sie direkt auf der Übersichtsseite erfahren, dass es das, was sie aus ihrem Grafikbearbeitungs-Colorpicker kennen, auch auf CSS-Ebene gibt…

Und: die blend-modes passen da in keine Kategorie - leider. Ich denke diesbezüglich wird man auf jeden Fall hier auf die missverständlichen Bezeichnungen "Sättigung"/"Helligkeit" hinweisen müssen, um zu vermeiden, dass anderen die selbe Verwechslung passiert wie hier Rolf (und mir anfangs natürlich auch).

Grüße,

RIDER

[Camping_RIDER]

Aloha ;)

Ich denke aber trotzdem, dass die Scheibe nicht zwei Parameter visualisieren sollte. Sie ist für den hueda - für die Sättigung sollte man meiner Meinung nach eine weitere Achse oder eben eine „Lupe“ haben.

Die Idee mit der weiteren Achse bzw. der Lupe kann ich mir jetzt nicht so richtig vorstellen. Ich denke im interaktiven Beispiel fehlt eigentlich nur ein Punkt innerhalb der markierten Halbgerade auf der Scheibe, der mit Saturation nach innen oder außen wandert.

Jetzt bin ich eben doch dabei den Ursprungsthread komplett zu lesen und verstehe mittlerweile wie das mit der Lupe gemeint war. Okay, dann haben wir ja quasi vom selben Ding gesprochen, du von Lupe, ich von Punkt, aber inhaltlich quasi gleich...

Wobei ich immer noch nicht sehe, inwiefern das die Scheibe von der Saturation befreit? Das ist für mich noch nicht schlüssig. Ich denke schon, dass die Scheibe bleiben sollte wie sie ist (oder eben nur Ringe)…

Grüße,

RIDER

[Matthias Scharwies]

Guten Morgen,

Das würde ich gerne am Stammtisch am 03.01. (morgen) mit allen Interessierten besprechen.

Das sehe ich allerdings schon so wie Rolf - Ich denke, dass die Scheibe mit zwei Parametern einen Sinn hat. Die Idee mit der weiteren Achse bzw. der Lupe kann ich mir jetzt nicht so richtig vorstellen. Ich denke im interaktiven Beispiel fehlt eigentlich nur ein Punkt innerhalb der markierten Halbgerade auf der Scheibe, der mit Saturation nach innen oder außen wandert.

@Edit: Keine Ahnung ob das schon jemand vorgeschlagen hat, aber so wie der Saturation-Schieberegler eine Vorschau mit den aktuellen hue/lightness-Werten zeigt, sollte auch der hue-Schieber eine Vorschau mit dem aktuellen Saturation/Lightness zeigen, und entsprechend der Lightness-Schieber auch... Dann hat man nämlich zwei vollständige Visualisierungen in einem - die Schieber und die grafische Darstellung, und kann genau nachvollziehen wie das eine das andere verändert...

Ja, so war's im Farbwähler und so kommt's auch wieder hin. Evtl. nur mit accent-color im Schieberegler selbst.

Wenn die Scheibe nur noch einen Parameter zeigen soll, dann hat sie als Scheibe keine richtige Berechtigung. Eine Scheibe ist ja ein zweidimensionales Objekt, hat also zwei Achsen, warum soll sie dann keine zwei Parameter visualisieren? Außerdem geht die Darstellung durchaus Hand in Hand mit anderen populären Visualisierungen, z.B. hier.

Dort hast du die drei Achsen visualisiert und in der jetzigen Scheibe nicht.

Welcher Punkt ist ausgewählt? (Das hast Du im nächsten Post ja festgestellt.) Beim Farbwähler sind die drei Achsen die Vorschau und das Viereck das Ergebnis; Stand jetzt dreht sich etwas und man sieht aber nicht, was das Farbergebnis der drei Parameter ist.

Nächstes Problem: hsl() hat Probleme mit der Mischung von Farben - viele wirken sehr dunkel. Deshalb hat das HSL-SVG ja auch einen Ring und keinen Kreis.

Was ich mir da alternativ noch vorstellen könnte ist, statt der Scheibe einen dünnen Ring zu zeigen, der je nach Saturation einen größeren oder kleineren Durchmesser hat. Das ist aber nichts anderes als die zweidimensionale Scheibe mit zwei Parametern, nur, dass man sie nicht mehr komplett sondern nur noch ausschnittsweise sieht.

Wäre besser.

Ich bin leider morgen bereits anderweitig terminlich gebunden (zusammen mit @Felix Riesterer in Aventurien), so dass ich zum Stammtisch nicht da sein kann um das live zu diskutieren.

Schade!

Das ist auch unsere Frage. hwb() ist bis jetzt noch nirgendwo erwähnt.

Der Vollständigkeit halber wohl am Besten in einer Unterseite von CSS/Funktionen/hwb(), Farbe/Farbmodelle sollte wohl eher nur die gängigen Farbmodelle und Notierungen beschreiben; rgb(), HEX und hsl(), sowie dann oklch().

Hm. Wenn man aus der Bildbearbeitung kommt oder mit GIMP aufgewachsen ist, dann ist hwb intuitiver und viel bekannter als hsl. Insofern wird das wohl noch zu besprechen sein, welches denn die gängigen Farbmodelle sind (das bemisst sich ja nicht nur daran, was häufig verwendet wird, sondern auch daran, wie eingängig die Notation ist). Ich könnte mir vorstellen, dass Leser sich freuen, wenn sie direkt auf der Übersichtsseite erfahren, dass es das, was sie aus ihrem Grafikbearbeitungs-Colorpicker kennen, auch auf CSS-Ebene gibt…

Ich hab's mal eingefügt: HSV, HSB bzw hwb()/wiki/Farbe/Farbmodelle#HSV.2C_HSB_bzw_hwb.28.29

Diese Grafik mach ich bis Ende der Woche fertig:

Problem ist hier wieder die Quadratur des Kreises:

• Anfänger sollen einen schnellen Überblick (zuerst RGB, hsl() ) erhalten;
• Fortgeschrittene sollen die neuen Möglichkeiten (bes. oklch() ) kennenlernen.

Der Artikel wird jetzt ziemlich lang und unübersichtlich. Wo sollte unser Fazit stehen? - Am Schluss, zu dem sich die Fleißigsten durchgekämpft haben oder doch eher jeweils nach RGB, hsl() und dann bei oklch()?

Mein Eindruck aus mittlerweile 5 Wochen Recherche: oklch() ist das kommende Ding bei den Blog-Autoren, der Rest wird beiläufig erwähnt.

Letztendlich kann man so ein Farbmodell nur über die entsprechenden Beispiele pushen. Sobald der Firefox die relative Syntax kann, sollte man über die Seiten zu linear-gradient() etc rüber.

Und: die blend-modes passen da in keine Kategorie - leider. Ich denke diesbezüglich wird man auf jeden Fall hier auf die missverständlichen Bezeichnungen "Sättigung"/"Helligkeit" hinweisen müssen, um zu vermeiden, dass anderen die selbe Verwechslung passiert wie hier Rolf (und mir anfangs natürlich auch).

Machst du's?

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Janosch,

Nachdem ich versucht habe, die Formeln in der Spec zu verstehen und nachzuprogrammieren (ich habe es abgebrochen), bin ich auf ein ähnliches Ergebnis gekommen. Der Saturation-Blendmode ist nicht HSL kompatibel. Er operiert auf RGB Werten, die er on the fly in physiologisch „richtige“ Werte übersetzt, also eher LCH als HSL. Dass Adobe das „verbockt“ hat, war mir neu.

Aber die physiologische Helligkeit erklärt das Sternmuster. Deine Idee mit der Transparenz schau ich mir noch an.

Was ganz schlecht geht, ist eine Farbscheibe auf LCH oder OKLCH Basis. Wenn ich die Scheibe mit Ringen aus konischen Gradienten berechne, bleibt entlang eines Radius der Farbton nicht konstant. Mal gucken, was bei einer pixelweisen Berechnung herauskommt.

Das graue Zentrum der Farbscheibe ist meiner Meinung nach überhaupt kein Quatsch. Der Sättigungsverlauf darf erst außerhalb der Helligkeits„stange“ beginnen. Ob das Zentrum nun grau ist oder transparent, ist dafür egal, aber man sieht es eh nicht und für den Gradienten ist grau einfacher. Dachte ich.

Matthias, wenn die fehlende Darstellung der ausgewählten Farbe dein Argument gegen den Sättigungsverlauf ist – das ist ja nun das kleinste Problem. Die ist fix ergänzt. Mir ging es darum, mit einer Stellschraube (L) den ganzen Farbraum durchlaufen zu können.

Rolf

[Matthias Scharwies]

Servus!

Das graue Zentrum der Farbscheibe ist meiner Meinung nach überhaupt kein Quatsch. Der Sättigungsverlauf darf erst außerhalb der Helligkeits„stange“ beginnen. Ob das Zentrum nun grau ist oder transparent, ist dafür egal, aber man sieht es eh nicht und für den Gradienten ist grau einfacher. Dachte ich.

Wenn man bei hsl() unten in das Diagramm schaut, ist auch alles grau, soll also so sein! (Deshalb wird ja auch oklch() gepusht, da gibt's keine dead grey zones.

Matthias, wenn die fehlende Darstellung der ausgewählten Farbe dein Argument gegen den Sättigungsverlauf ist – das ist ja nun das kleinste Problem. Die ist fix ergänzt. Mir ging es darum, mit einer Stellschraube (L) den ganzen Farbraum durchlaufen zu können.

Perfekt!

Herzliche Grüße und bis heut' Abend!

Matthias Scharwies