Farbe HSI oder HQI?

Hallo,

Also: Die Eingabe der Werte und alle Effekte arbeiten auf RGB, da rein Physikalisch gesehen RGB den vollen Farbraum abbildet. Was sich in der 3.1 ändert ist, dass die einzelnen Komponenten (R, G, B) als Gleitkommazahl angegeben werden können, ergo sind wir nicht auf 24bit limitiert, sondern haben da viel mehr Freiraum.

Ein Problem in Realität ist, dass sich die "Hardware" natürlich unterschiedlich verhält. So ist es nicht nur ein Problem wenn ich unterschiedliche Technologien zur Lichterzeugung verwende (du hast Metalldampflampen angesprochen), sondern auch RGB Lampen unterschiedlicher Hersteller verhalten sich unterschiedlich.

Effektiv müsste man in der HAL zwischen Eingabe und Ausgabe eine Transformation einbauen, welche unter Berücksichtigung des Gerätes das Eingabemodel umrechnet und an die Ausgabe weiterleitet. Theoretisch Mathematisch ist das einfach zu lösen. Trotzdem ist es stand jetzt nicht allgemein implementiert. Was mit der 3.1 kommt ist eine Annäherung für RGB Zusatzkanäle (wie Amber, Cyan,...). Für diese Zusatzkanäle kann ich im HSV Model definieren, in welchem "Gradbereich" auf dem HSV Kreis der Kanal Aktiv ist. So kann ich im DDF definieren, dass der Amber Kanal bei 0° beginnt, bis 30° auf 255 linear einfaded (bei 15° also bei 127 ist). dann bis 45° bei 255 bleibt, und dann bis 60° wieder ausfaded. Dieser Automatismus kann durch die Angabe eines manuellen Wertes überschrieben werden.

Effektiv kann man auch darüber diskuttieren, in wieweit so eine Normung und ein allgemeines Transformationsmodel sinn macht, weil:

1. In Realität hat der User wenig Möglichkeiten das Farbverhalten seiner Geräte zu vermessen.
2. Die angezeigte Farbe ist nur auf einer Weißen Wand bzw. in Luft vorhanden. Sobald der Lichtstrahl auf eine andere Oberfläche trifft passt es schon nicht mehr.
3. In Realität programmieren die meisten User sowieso nach dem Motto: Ich drehe so lange am Farbregler bis es gut aussieht.

Das sind auch die Gründe, warum wir abgesehen von der relativ einfachen Umsetzung für RGB+ Kanäle noch nichts in der Richtung unternommen haben. Hauptaufgabe der HAL ist es auch eine vereinfachte Steuerung zu realisieren und weniger die Geräte zu 100% Physikalisch zu normieren.

ich hoffe das beantwortet deine Frage, ansonsten nachfragen

Gruß Arne

Quote from .rhavin

Rot, Amber, Gelb, Grün, Limette, Cyan, Blau, Indigo, Magenta, UV und 3 Weißtöne

Das sind genau die Kanäle die wir implementiert haben (siehe oben mein Beispiel mit Amber).

Aber wie gesagt. Es nützt alles nix das am PC zu 100% zu machen, weil die Hardware immer die Ausgabe verfälscht.

Das ganze funktioniert nur dann korrekt (egal welches Farbmodel man verwendet) wenn die z.B. Rot LED auch wirklich ROT ausgibt (also genau die Wellenlänge). In Realität hast du 2 Blaue LEDs und die haben ein unterschiedliches Blau weil die Unterschiedliche Wellenlängen generieren. Entsprechend verschieben sich die Farbmodelle. Das müsste man kompensieren, wenn überhaupt möglich.

Ergo, solange sich die Endgeräte nicht "korrekt" verhalten, können wir in der Software das Ergebnis eh nur annähern, und da ist die Frage, wieviel "Magic" will man investieren um am Ende doch nur ein ungefähres Ergebnis zu haben.

Die Eingabe mit RGB zu machen hat folgenden Hintergrund: Das kennt jeder und ist einfach. Außerdem sind normale Bildschirme nur in der Lage RGB darzustellen, ergo wenn wir ein anderes Farbmodell wählen würden, dann wäre die Darstellung am PC wieder ein Problem

Gruß Arne