Hallo, ich bin gerade dabei ein RGB Projekt umzusetzen. Die idee war eigentlich einen Poti je Farbkanal einzusetze und einen für die Helligkeit. Der Fader soll die Helligkeit konstant halten damit kein pulsierendes unruhiges Licht entsteht. Ich fände es daher unintuitiv, die drei Potis für die Temperatur zu nutzen, da man mit Potis auch eine Leistungsregelung verbindet. Die Farben würden dann redundant erseugt werden (zB 10/10/50) würde relativ derglsichen Farbe wie (20/20/100) entsprechen. Nun frage ich mich, wie ich eine Trennung von Helligkeit und Temperatur umsetzen kann. Ich hatte überlegt einen einzigen Poti als Farbwähler zu nutzen. Wie bei diesen RGB RC Modulen würde er einfach Durch die Farben des Ringes "drehen". Nur wie ist solch ein Ring aufgebaut? Ich verstehe nicht wie man von ei er RGB Darstellung auf eine 2D Ansicht umrechnen kann um auf eine Darstellung eines Regenbogen-Farbpickers zu kommen. Vielleicht hat jemand Rat (insb zur Umsetzung auf einem 8 Bit uC )? LG, doppio
Beschäftige dich noch ein mal mit dem Farbraum. http://de.wikipedia.org/wiki/Farbraum Er hat 3 Dimensionen, also kannst du mit nur 2 Potis (Farbe und Helligkeit) nicht alle Farben herausholen. Natürlich kannst du dich einschränken und die Farben nur aus einem 2-dimensionalen Schnitt des Farbraumes holen.
Das hier ist mal eine VB.NET Funktion um einen Farbgradienten zu generieren
1 | Private Function MakeGradient() As Drawing.Image |
2 | Dim img As New Drawing.Bitmap(30, 1536) 'Deklaration des Bitmaps, auf welches der Farbverlauf gezeichnet wird. |
3 | Dim red As Integer = 255 'Anteil an Rot |
4 | Dim green As Integer = 0 'Anteil an Grün |
5 | Dim blue As Integer = 0 'Anteil an Blau |
6 | Dim count As Integer = 0 'Die Schleife muss 6 * 256 durchgegangen werden. Jedoch ist es wichtig zu wissen, das wie vielte Mal di eSchleife die 256 überschritten hat. Deshalb die Variable 'count' |
7 | For i As Integer = 0 To 1535 'Die Schleife muss 6 Mal 256 Mal durchgehen. 6*256 = 1536. Da die Schleife bei 0 beignnt, nur 1535 |
8 | For k As Integer = 0 To 29 'Mein Bild ist jetz z.B. 30 Pixel hoch. |
9 | img.SetPixel((k), i, Drawing.Color.FromArgb(red, green, blue)) 'i und k machen zusammen die virtuellen Koordinaten auf dem Bild aus. So weisen wir dem aktuellen Pixel die Farbwerte aus den Variablen zu. |
10 | Next |
11 | Select Case count 'Da wird überprüft, das wie vielte Mal die Schleife 256 überschritten hat. Jenachdem werden die RGB-Werte verändert |
12 | Case 0 |
13 | If Not green = 255 Then |
14 | green += 1 |
15 | End If |
16 | Case 1 |
17 | If Not red = 0 Then |
18 | red -= 1 |
19 | End If |
20 | Case 2 |
21 | If Not blue = 255 Then |
22 | blue += 1 |
23 | End If |
24 | Case 3 |
25 | If Not green = 0 Then |
26 | green -= 1 |
27 | End If |
28 | Case 4 |
29 | If Not red = 255 Then |
30 | red += 1 |
31 | End If |
32 | Case 5 |
33 | If Not blue = 0 Then |
34 | blue -= 1 |
35 | End If |
36 | End Select |
37 | If ((i + 1) Mod 256 = 0) Then 'Wenn sich i + 1, also der aktuelle Schleifendurchgang + 1, ohne Rest durch 256 teilen lässt, kann die Variable count um 1 erhöht werden. |
38 | count += 1 |
39 | End If |
40 | Next |
41 | Return img 'Das Bitmap mit dem Farbverlauf wird zurückgegeben |
42 | End Function |
Ich glaube man sieht gut wie der Gradient gemacht wird.
@MaWin: Dann hast du mich falsch verstanden! Der eine Poti soll nur durch einen Ausschnitt traversieren, also kein selber Mischen erlauben. @NoNever & B.Limer: Schaue ich mir in der dritten Halbzeit an :-)
-J VV schrieb: > Nun frage ich mich, wie ich eine Trennung von Helligkeit und Temperatur > umsetzen kann. Wenn du mit einem Regler die Farbtemperatur ändern möchtest, mußt du im CIE-System auf der "Black-Body-Kurve" entlangfahren. Damit das richtig in RGB transformiert werden kann, mußt man die CIE-Koordinaten der LEDs kennen. http://de.wikipedia.org/wiki/CIE-Normvalenzsystem
>> Beschäftige dich noch ein mal mit dem Farbraum. >> Er hat 3 Dimensionen, also kannst du mit nur 2 Potis (Farbe und >> Helligkeit) nicht alle Farben herausholen. na ja , nicht wirklich. CIExy ist 2 dimensional. Aber NoEver hat die brauchbare Lösung ja schon genannt. http://de.wikipedia.org/w/index.php?title=Datei:CIExy1931_AdobeRGB.png&filetimestamp=20070316183001 Stefan
Um bequem wirklich alle Farben zu "durchfahren" und die Helligkeit getrennt zu steuern, empfehle ich das HSV-Farbmodell. Am Ende benötigt man natürlich wieder RGB-Werte, aber zur Eingabe eignet sich HSV wirklich hervorragend. H = Hue = Farbton, wird im Kreis per Grad (Zahl von 0 bis 360) dargestellt, beginnt bei Rot und alle 60 Grad eine neue Grundfarbe (Rot, Gelb, Grün, Cyan, Blau, Magenta ... dann wieder Rot usw.). Lässt sich gut per Poti und ADC umsetzen. S = Saturation = Sättigung (0...1). Wenn Null, dann Weiss oder neutrales Grau (je nach Helligkeit), wenn 1 dann "reine" Farbe, dazwischen unterschiedlich blass V = Value = Helligkeit (0...1) Die Formel in Wikipedia für die Umrechnung HSV nach RGB ist genau die richtige. Aufpassen: Die Berechnung von hi=H/60 muss als Ganzzahl ohne Rest ausgeführt werden, während alle anderen Berechnungen mit Fliesskommazahlen zu machen sind. Die RGB-Werte am Schluss entstehen im Wertebereich von 0...1, müssen also noch mit 256 multipliziert werden. Ich kenne keine einfachere Berechnung, die so schöne Spektraldarstellungen liefert. Natürlich ginge auch CIEW Lab, aber da ist die Mathematik ein ganz alnderes Level ...
Hallo, ich habe mir jetzt mal die Ergebnisse der Formel angeschaut. Was ich ursprünglich vermeiden wollte war eine schwankende Helligkeit. Nun liefert aber die HSV->RGB Wandlung bei S=V=1.0, H [0,360] Werte, bei denen die Summe aller Kanäle >255 ist! zB liefert HSV(50,1,1) -> RGB(255,213,0).. Muss ich diese noch normieren oder wird einem das dann doch nicht auffallen? Mich wundert es, da der HSV Raum explizit eine V Komponente für die Helligkeit besitzt und ich mir erhoffte damit schwankende Helligkeiten im RGB Raum zu vermeiden!
Das muss auch so sein... Schau Dir nochmal die Umwandlung in Ruhe an und überlege mal, was z.B. herauskommen sollte wenn Du im HSV-Raum ein reines Weiss haben möchtest. Rechne das dann mal in RGB um... Und denke daran, dass die Umrechnung von HSV in RGB die Kennlinie des Auges nicht berücksichtigt. Dafür brauchst Du dann komplexere Modelle...
-J VV schrieb: > zB liefert HSV(50,1,1) -> RGB(255,213,0).. Muss ich diese noch normieren > oder wird einem das dann doch nicht auffallen? Du machst dir zuviele (unbegründete) Sorgen. Da schwankt keine Helligkeit, wenn auf dem 'Farbweg' von Rot nach Gelb, zu Rot-255 noch Grün von 0 bis 255 dazukommt.
Danke für die Antwort. Ich denke probieren geht über studieren. Melde mich, wenn das Ding läuft ;-)
Angehängte Dateien:
-
IMG_2655.jpg
220 KB -
IMG_2654.jpg
350 KB -
IMG_2659.jpg
190 KB
Das Projekt ist soweit abgeschlossen; Ich habe eine Implementierung gefunden, die auch die RGB Werte normalisiert. Jetzt gibt es summiert maximal die Helligkeit 255. Einziges Problem: Die LEDs falckern ab und zu. Die Helligkeit ist dabei offensichtlich maxima (PWM auf 255/255). Bei schnellen Farbübergängen tritt das Flackern sehr viel häufiger auf (ca 1 mal alle 2 Sekunden)... Bei konstanter Farbe tritt das Phänomen eigentlich garnicht auf. Ich habe schon alles möglich probiert: ADC mittelwerte, median und Begrenzung der Änderungsrate Minimale Helligkeit auf 1 gesetzt, sodass die LEDs nicht nur glimmen und dann plötzlich auf höhere Helligkeiten springen. Ich weiss nicht, woher das Flackern kommt. Interessant allerdings, dass es bei schnellen Farbwechselroutinen häufiger auftritt. Ich habe mal den Code auf github gepusht: https://github.com/kreuzUndQwertz/hsv2rgb Vielleicht hat jemand eine Idee?
Kann es sein, das der Timer Compare Wert sich nahe des Wertes nach unten ändern kann und so verpasst wird? So läuft ein Zyklus voll durch und es blitzt ...
Meinst du, dass sich die Farben nach unten ändern und die Abfrage count
== RGB[x] übergangen wird?! Das könnte natürlich passieren. Dazu müsste
ich vor dem setzen der neuen Farbe schauen, ob die neue Farbe den
aktuellen count unterschreitet.
Ich probier's mal so in der Farbberechnung:
cli();
//setzen der neuen Farbe
color[0] = temp[n + 2];
color[1] = temp[n + 1];
color[2] = temp[n ];
//verhindern, dass neue Farbe aktuellen PWM count unterschreitet und
somit eine periode lang volle helligkeit entsteht
if (count >= color[0])//rot aus machen
PORTD &= ~(1<<redPort);
if(count >= color[1])//grün ausmachen
PORTD &= ~(1<<greenPort);
if(count >= color[2] )//blau ausmachen
PORTD &= ~(1<<bluePort);
sei();
cli(); sei() sind (wahrscheinlich) überflüssig.
Dein Programm hab ich mir nicht angeschaut... Ich hatte mal ein ähnliches Problem. Nachdem ich den Comparewert nur zu Beginn eines PWM Zyklus gesetzt habe war das Flackern weg. Die Schritte sind für lineare Helligkeit ja ziemlich grob.
Ich danke Dir von herzen :D Die Lampe ist ein Geschenk an meine Freundin und jetzt läuft's wie eine Eins! Vielen Dank für den Tipp! PS: Zu beginn setzen ist bei mir nicht wirklich möglich, da meine Farbberechnung asynchron zum ISR läuft. So geht's aber!
Ich habe Eines nicht verstanden, bitte erläutern: Wieso darf die Summe der Steuersignale nicht 255 übersteigen? Natürlich darf sich der Wert für JEDEN der drei LED-Chips/Kanäle im Bereich von 0 ... 255 bewegen. Die Summe beträgt dann maximal 765, was aber einigermaßen uninteressant ist, weil die drei Kanäle "nach Hinten raus" ja sowieso voneinander unabhängig sind ... Bitte nochmal erklären.
Frank schrieb: > Wieso darf die Summe der Steuersignale nicht 255 übersteigen? Weil dann Mischfarben heller wären als reine Farben - Rot kann halt nicht heller werden als R=255 G=0 B=0. Weiss ist üblicherweise 255 255 255, aber das ist dann viel heller als reines Rot, was ja bei einer Steuerung nach Farbe/Sättigung/Helligkeit nicht erwünscht ist. In Wirklichkeit ist die Sache komplizierter, weil die Farben im Auge nicht als gleich hell empfunden werden, bzw. man müsste die Anzeige erstmal so kalibirieren, dass volles Rot, Grün und Blau gleich hell erscheinen (die ganze Wahrheit ist das immer noch nicht). Gruss Reinhard
Und als praktisches Beispiel: Du willst reines Rot in maximaler Helligkeit darstellen ->(255,0,0); Bei einem Wechsel zu der Farbe Gelb (255,255,0) würde die Helligkeit bzw. die Leistung der LEDs verdoppelt werden. Daher würde man hier zB den Farbwert (127,127,0) wählen um die Leistung konstant zu halten. Allerdings, wie oben schon erwähnt, nimmt das Auge unterschiedliche Farben unterschiedlich stark wahr. Deshalb kann durchaus die Gesamtleistung bei unterschiedlichen Farben variieren (Summe der RGB Komponenten > 255), gleichzeitig der subjektive Eindruck der Farbhelligkeit aber konstant bleiben.
Reinhard Kern schrieb: > Weil dann Mischfarben heller wären als reine Farben - Rot kann halt > nicht heller werden als R=255 G=0 B=0. Weiss ist üblicherweise 255 255 > 255, aber das ist dann viel heller als reines Rot, was ja bei einer > Steuerung nach Farbe/Sättigung/Helligkeit nicht erwünscht ist. Ich kann die Überlegung jetzt nachvollziehen, glaube aber die Schlussfolgerung daraus nicht. Das würde ja bedeuten, das z.B. auf einem Monitor, der auch nach dem RGB-Prinzip funktioniert, die Werte für ein TFT-Tripel nie zusammen mehr als 255 sein dürften - so ist es aber definitiv nicht. Die Farbreize werden von den verschieden sensiblen Zapfen auf der Netzhaut aufgenommen und addieren sich zwar hinsichtlich des Farbempfindens, aber nicht (oder nicht so extrem bzw. so einfach, wie befürchtet) im Helligkeitsempfinden ... die befürchtete Zunahme des Helligkeitsempfindens wird bereits sehphysiologisch ausgeglichen. Ich halte die technische Berücksichtigung deshalb für unangebracht, ja sogar falsch ...
Nachtrag: Für vernünftig würde ich es dagegen halten, bei maximaler Leistung aller drei LEDs einen Abgleich hinsichtlich der Neutral-Empfindung vorzunehmen und so evtl. den Stellbreich der jeweils beiden "unterlegenen" Kanäle ggf. einzuschränken.
Nachtrag zum Nachtrag: Ist natürlich Quark, ich meine die beiden dominierenden Kanäle ... ist schon spät, hier in Finnland (Urlaub) sogar noch ein Stunde später ...
Frank schrieb: > die Werte für ein > TFT-Tripel nie zusammen mehr als 255 sein dürften - so ist es aber > definitiv nicht. Doch, jedenfalls ungefähr ist es so, wenn du den Monitor kalibrieren willst, um z.B. Bildverarbeitung damit zu machen. Dann must du ALLE Farben auf gleiche Helligkeit abgleichen. Wenn du von Weiss = 255 255 255 als Fixpunkt ausgehst ist keine Kalibirierung möglich, das geht nur, wenn die einzelnen Farbkanäle nicht voll ausgesteuert werden. Die maximale Helligkeit eines kalibrierten Monitors ist dann erreicht, wenn bei irgendeiner Farbe irgendein Kanal 255 ist. Über die Farben eines nichtkalibrierten Monitors zu reden ist Zeitverschwendung. Gruss Reinhard
-J VV schrieb: > PS: Zu beginn setzen ist bei mir nicht wirklich möglich, da meine > Farbberechnung asynchron zum ISR läuft. So geht's aber! Du kannst genau das gleiche auch machen, was die Hardware Timer machen. Du legst deine Rechenergebnisse erst mal in anderen Variablen ab. Und nur dann, wenn der count 0 ist, kopierst du sie auf die PWM Vergleichsregister um.
1 | cli(); |
2 | |
3 | if( count == 0 ) |
4 | {
|
5 | //setzen der neuen Farbe
|
6 | color[0] = temp[n + 2]; |
7 | color[1] = temp[n + 1]; |
8 | color[2] = temp[n ]; |
9 | }
|
10 | |
11 | ...
|
Du kannst das zb in dem Teil machen, in dem du deine LED beim Zählerstand 0 ein (bzw. ausschaltest)
Reinhard Kern schrieb: > Doch, jedenfalls ungefähr ist es so, wenn du den Monitor kalibrieren > willst, um z.B. Bildverarbeitung damit zu machen. Dann must du ALLE > Farben auf gleiche Helligkeit abgleichen. Wenn du von Weiss = 255 255 > 255 als Fixpunkt ausgehst ist keine Kalibirierung möglich, das geht nur, > wenn die einzelnen Farbkanäle nicht voll ausgesteuert werden. Die > maximale Helligkeit eines kalibrierten Monitors ist dann erreicht, wenn > bei irgendeiner Farbe irgendein Kanal 255 ist. DAS sehe ich nicht als Widerspruch zu meiner Aussage (Nachtrag vom Nachtrag), dem stimme ich vollkommen zu. Weiter Oben war aber die Rede davon, dass die SUMME aller Signale nie 255 überstegen solle und das ist nicht richtig ...
Karl Heinz Buchegger schrieb: > Du kannst das zb in dem Teil machen, in dem du deine LED beim > Zählerstand 0 ein (bzw. ausschaltest) Ja, du hast Recht! Aber bisher wurde die Farbe außerhalb der ISR berechnet. Wenn ich dann außerhalb, asynchron (Farbe neu berechnen) auf cnt==0 abfrage, ist es wahrscheinlich diesen Zeitpunkt nur sehr selten zu treffen! Ich werde deinen Ansatz mit der temporären Variable umsetzen und dann innerhalb der ISR die Farbe updaten. Ist für die Zukunft eine schönere Lösung.
Hallo, zum Seh-Empfinden des Auges fällt mir da meine Farbfernsehzeit ein: http://de.wikipedia.org/wiki/YUV-Farbmodell Irgendwie scheint es mir, als ob da was hilfreiches sein könnte, was die Faktoren betrifft, um gleiche Helligkeit bei verscheidenen Farben zu empfinden. Ist ja irgendwie die Wandlung von Farben in Graustufen mit gleicher Helligkeitsempfindung, oder? Gruß aus Berlin Michael
Michael U. schrieb: > Ist ja irgendwie die Wandlung von Farben in Graustufen mit > gleicher Helligkeitsempfindung Nein, das gibt es nämlich garnicht, weil wir ja nicht schwarzweiss sehen - was es gibt, sind Umrechnungsformeln, die die Charakteristik üblicher SW-Filme oder Fernsehaufnahmeröhren nachbilden. Die sind z.B. relativ unempfindlich bei rot. Ein roter Notstopp hebt sich auf einem SW-Foto kaum ab von einem dunkelgrauen Hintergrund, das sieht das Auge aber deutlich anders. Wahrscheinlich ist bei SW-Fotos und SW-Fernsehen viel Gewöhnung dabei. Farben sind allgemein keine exakte Physik, so hat etwa jeder Film, SW oder Farbe, seine eigene Charakteristik und erfahrene Fotografen können sagen, mit welchem Film eine Aufnahme gemacht wurde (heute kann man in der Nachbearbeitung der digitalen Daten einstellen, ob Kodak, Fuji usw.). Es weiss ja sowieso niemand, wie jemand anders eine Farbe sieht, man hat nur als Kind gelernt, rot als rot zu bezeichnen. Gruss Reinhard
Frank schrieb: > Weiter Oben war aber die Rede > davon, dass die SUMME aller Signale nie 255 überstegen solle und das ist > nicht richtig ... Wenn man als Voraussetzung nimmt, dass R,G und B gleiche maximale Helligkeit haben (so sollte man das einstellen) und sich die Helligkeiten addieren, dann ist das GENAU das Gleiche. Gruss Reinhard
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.