Hallo zusammen,
vllt. kennt ihr unter Gimp oder anderen Programmen die Funktion
"Färben" oder "Einfärben".
Mit dieser kann man ein Pixel in eine andere Farbe umfärben.
Diese Funktion benötige ich für mein µC Projekt um ein Bild (Graustufen)
dynamisch mit einer Farbe einzufärben.
Ich benötige zwar nur den Farbverlauf von Rot über Gelb nach Grün,
aber das Verfahren sollte ja gleich sein.
Für eine Vollfarbe (z.B. Grün = 0x00ff00) habe ich es hinbekommen,
mit (Gelb = 0xffff00) funktioniert es auch...
aber für 0xff6400 sieht die Geschichte schon etwas schwerer aus, da hat
das Grün auch noch ein eigenes Intervall.
Was ich bis jetzt habe (für Vollfarbe)
hier lediglich am Bsp. mit Grün:
1
uint32_tcolor=0x00ff00;// mit dieser Farbe einfärben
2
uint32_tpixel=0x969696;// diesen Grauton einfärben
3
uint32_ttmp;
4
5
// Grauwert Grenze = 128, hier mit Blau geprüft
6
// da bei Grau immer alle Werte gleich sind.
7
if(pixel&0x80)
8
{
9
// Neuen Wert für R, B berechnen
10
tmp=(pixel&0xff);
11
tmp=tmp-(255-tmp);
12
13
// Neue Farbe zusammensetzen
14
pixel=color;
15
pixel|=(tmp<<16)|tmp;
16
}
17
else
18
{
19
tmp=(pixel&0xff);
20
pixel=(tmp*2)<<8;
21
}
Im oberen Bereich (hell) stimmen die Werte mit der Grafik überein,
für den unteren Bereich (RGB < 127) ist das Grün angenährt +- 2 ca.
Habt ihr evtl. eine Idee wo ich was finden könnte?
Hab nach verschiedenen Wörtern gesucht, aber das große G liefert nicht
wirklich was brauchbares zu diesem Thema.
Falls es doch eher unter Mikrocontroller / Display fällt, dann gerne
verschieben.
Wenn Helligkeit zu Farbe konvertiert werden soll ist die Verwendung des
HSV-Farbmodelles nicht ganz unclever, weil man dort Farbe (Hue),
Sättigung (Saturation) und Helligkeit (Value) zunächt getrennt vorliegen
hat und getrennt beeinflussen kann. Erst für die Ausgabe wird dann nach
RGB konvertiert, weil die allermeisten Geräte RGB-Werte brauchen.
Für dein eingefärbtes Graustufenbild belegst du H und S mit festen
Werten und V übernimmst du direkt (bzw. skaliert/gemapt) aus den
Grauwerten des Bildes. Durch eine Änderung von H kannst du beliebige
Farbskalen einstellen, auch kannst du ja anteilig den V-Wert auch auf H
wirken lassen und du erhältst "Falschfarbenbilder" wie z.B. aus einer
Thermokamera ...
Frank E. schrieb:> Wenn Helligkeit zu Farbe konvertiert werden soll ist die Verwendung des> HSV-Farbmodelles nicht ganz unclever, weil man dort Farbe (Hue),> Sättigung (Saturation) und Helligkeit (Value) zunächt getrennt vorliegen> hat und getrennt beeinflussen kann.
ja das war auch erst meine idee....
problem war, das "ulead photoimpact" hat meine vorlage falsch gefärbt
und ich kam zu keinem ergebnis.
kaum hab ich es mit gimp probiert, stimmte die vorlage mit der theorie,
aber dann hab ich es gar net mehr mit HSV probiert.
aber werd ich gleich mal ausprobieren.
ich nutze zum OLED halt RGB565 und da muss ich jeden pixel jetz schon in
RGB888
umrechnen und verarbeiten, wollte mir die Umrechnung in HSV sparen.
Aber ich werd es probieren... Die 1 ms mehr oder weniger 😉
danke erstmal.
Adam P. schrieb:> was mir jedoch aufgefallen ist,> ein HSV wert kann bis zu 2-3 unterschiedliche RGB werte beinhalten.> das wäre ja etwas ungenau.
HSV ist ein Farbmodell, kein Farbraum, deshalb theoretisch unbegrenzt.
Hue wird in Grad angegeben (wegen des Farbkreises, alle 60 Grad eine der
Grundfarben), S und V entweder in Prozent oder 0...255. Diese
"Auflösung" hängt von der konkreten Implementierung ab, z.B. ob Int oder
Double und welche interne Bitbreite/Genauigkeit.
Frank E. schrieb:> Hue wird in Grad angegeben (wegen des Farbkreises, alle 60 Grad eine der> Grundfarben), S und V entweder in Prozent oder 0...255.
Das war mir bewusst.... nur der zusammenhang der umrechnung nicht.
die infos helfen mir erstmal, ich werd mal versuchen eine funktion zu
erstellen.
... ich meld mich.
Adam P. schrieb:> Diese Funktion benötige ich für mein µC Projekt um ein Bild (Graustufen)> dynamisch mit einer Farbe einzufärben.> Ich benötige zwar nur den Farbverlauf von Rot über Gelb nach Grün,> aber das Verfahren sollte ja gleich sein.
Für mich liest sich das so:
- Vorlage ein Graustufenbild
- Ergebnis weiß-> rot, schwarz -> grün, grau -> je nach Helligkeit von
orange über gelb nach lindgrün
Ist das so richtig? - Da wäre dann allerdings nicht das, was dein Bild
im Eingangspost aussagt.
Adam P. schrieb:> "ulead photoimpact" hat meine vorlage falsch gefärbt
Das ist schon richtig gefärbt ;-) Eventuell hast du einen falschen
Filter ausgewählt. Falls meine obige Annahme richtig ist, dann ist das
so speziell, da gibt's dann wahrscheinlich keinen fertigen Filter in
einem Bildbearbeitungsprogramm.
(HSV-Modell an der Stelle ist eine Sackgasse.)
Ralf G. schrieb:> (HSV-Modell an der Stelle ist eine Sackgasse.)
Kommt drauf an, was genau als Ziel gewünscht ist. So richtig klar konnte
der TO sich da ja bisher nicht ausdrücken...
Das Übliche wäre: Mapping von Graustufen auf einen möglichst
kontrastreichen Farbverlauf konstanter Helligkeit. Dafür ist NATÜRLICH
HSV das am Besten passende Modell, sowohl für die Quelle als auch für
das Ziel. Das Mapping ist sehr simpel: Map(Quelle.V)->Ziel.H (mit
Ziel.S=max, Ziel.V=const)
Generell arbeitet es sich bei der Bildbearbeitung im HSV-Modell
praktisch immer sehr viel einfacher als im RGB-Modell.
Ralf G. schrieb:> Adam P. schrieb:>> "ulead photoimpact" hat meine vorlage falsch gefärbt>> Das ist schon richtig gefärbt ;-)
ich schick dir ein Bsp., weil es linear abnehmen sollte, und ich extra
ein 255 pixel breites fenster genommen habe...... da war mit photoimpact
bei 106 pixel schluss... obwohl es 127 sein sollten, so wie es gimp
gemacht hat.
ich schreib morgen mal meine vorgehensweise auf, aber es gab ein
unterschied und gimp hat es der theorie nach richrig gemacht, wie im
anhang zu sehen....
max farbe von grün bis pixel von graustufe 128/127
c-hater schrieb:> Kommt drauf an, was genau als Ziel gewünscht ist. So richtig klar konnte> der TO sich da ja bisher nicht ausdrücken...
Also anbei eine kleine Erklärung...
hoffe es hilft, sonst einfach fragen!
Aber es geht echt nur um die "Einfärbung" von Grauabstufungen.
Werde die vorgeschlagenen Methoden morgen probieren, habe jetz
erstmal die PDF für euch erstellt.
Gruß
Adam P. schrieb:> Also anbei eine kleine Erklärung...>> hoffe es hilft, sonst einfach fragen!
Ja, hat geholfen. Ganz klar: Hausaufgabe. Lös' sie selber, ist trivial.
Solche Hausaufgaben werden Leuten gestellt, die sie lösen können müßten.
Aber eins möchte ich noch sagen: für genau diese Aufgabe bringt der
Ausflug in's HSV-System wirklich keinen Vorteil, da hatte Ralf G. schon
Recht.
Vermutlich hat er die Aufgabe trotz der unvollständigen Angaben schon
"vorzeitig" erkannt. Könnte sein, dass er sogar der Aufgabensteller war
und gezielt nach solche Anfragen in den einschlägigen Foren sucht ;o)
Ja, es wird schwieriger, zu bescheißen. Und da ist auch sehr gut so...
c-hater schrieb:> Solche Hausaufgaben werden Leuten gestellt, die sie lösen können müßten.
hausaufgaben?
ja ganz ernsthaft.... vergisst es einfach, wie so oft werde ich diesen
Post wohl mit meiner eigenen antwort schliessen, weil keiner helfen
kann.
aber wie schön das c-hater, allwissend ist und trotzdem kein algo.
liefern kann.....
ich dacht er hätte echt ahnung, durch seine qualifizierten aussagen (ab
und zu).
ich werds machen, denn
open source 4 life
... keine hausaufgabe..... bin alt genug und will es einfach nur
wissen..... da wissen einem keiner nehmen kann!
Adam P. schrieb:> aber wie schön das c-hater, allwissend ist und trotzdem kein algo.> liefern kann.....
Der "Algo" nennt sich "Verhältnisgleich" AKA "Dreisatz". Superprimitiver
Scheiß, den eigentlich jeder so ca. ab 6. Klasse vollständig beherrschen
sollte.
Der Trick ist für eine beliebige Zielfarbe (also abseits der reinen
Farben), dass du drei dieser Gleichungen mit drei verschiedenen
Scaling-Faktoren für die Transformation brauchst. Das ist schon alles.
Tipp: alle üblichen Bildverarbeitungsprogramme können sowas. Nur die
Namen der entsprechenden Filter unterscheiden sich...
c-hater schrieb:> Dreisatz
leider ist es nicht nur ein dreisatz.... wenn du es dir mal genau
anschaust.
ja es ist linear, aber 2 geteilt.
je nach ausgangswert verhält es sich anders.
ich hab es schon erkannt, aber nen dreisatz ist es nicht.
und das es jedes prog. kann weiß ich auch.... aber ich brauch halt das
verfahren.
und wenn es nur nen dreisatz ist... dann hau mal raus die funktion in
C.....
Jetzt verstehe ich, was du meinst. (Glaube ich.)
Adam P. schrieb:> und wenn es nur nen dreisatz ist... dann hau mal raus die funktion in> C.....
Das ist ja wirklich nur (ein) Dreisatz.
'Helligkeit * Farbanteil(r,g,b) / 256 -> angezeigte Farbe(r,g,b)'
Hier läuft das erstmal von schwarz nach 'Farbe'!
Nun willst du ja noch den Glanz berücksichtigen. Dazu legst du einen
Schwellwert fest, bis zu dem die Farbe gerechnet werden soll (das ist
vielleicht nicht einmal genau die Mitte, wie in deinem Versuch).
Für Werte <= Schwelle:
'Helligkeit * Farbanteil(r,g,b) / Schwellwert -> angezeigte
Farbe(r,g,b)'
Ist die Schwelle überschritten, rechnest du den Rest von 'Farbe' nach
'weiß'.
------------------------------
Schwellwert ist wahrscheinlich doch in der Mitte, da der nichtlineare
Helligkeitsverlauf, der bei der Beleuchtung des Zylinders entsteht, ja
schon in den Grauwerten 'codiert' ist.
Adam P. schrieb:> Also anbei eine kleine Erklärung...>> hoffe es hilft, sonst einfach fragen!
Dein PDF passt nicht zu dem Bild aus dem Ursprungsposting. In ersterem
wird nämlich aus schwarz grün, während im anderen schwarz so bleibt.
Adam P. schrieb:> leider ist es nicht nur ein dreisatz.... wenn du es dir mal genau> anschaust.
Nö, es sind drei, wie schon gesagt.
> ja es ist linear, aber 2 geteilt.
Unsinn. Es sind einfach drei superprimitive Dreisatze (also ihne
irgendwelche Offsets), nur mit jeweils einem anderen Faktor für die
Steigung.
> ich hab es schon erkannt, aber nen dreisatz ist es nicht.
Ja, es ist nicht einer, sondern es sind drei. Wie oft muss das noch
wiederholt werden, bis du es kapierst?
> und das es jedes prog. kann weiß ich auch.... aber ich brauch halt das> verfahren.
Einfach mal darüber nachdenken, was diese Programme tun? Oder sogar in
die Quellen schauen, denn einige davon sind ja OpenSource?
> und wenn es nur nen dreisatz ist... dann hau mal raus die funktion in> C.....
Das findest du dann im Quelltext eben dieser Programme, wenn du zu blöd
bist, selber drei einfache lineare Mappings in C umzusetzen. Naja,
vielleicht nicht unbedingt in C, aber der Scheiß ist so primitiv, dass
er in jeder Hochsprache doch sehr, sehr ähnlich aussieht...
Aus der Frage wird nicht ganz klar, ob nun nur das Graustufen-Bild
dynamisch ist, oder ob auch der Farbverlauf dynamisch geändert werden
soll...
Wenn der Farbverlauf fix ist, mach eine schnöde Lookup-Tabelle
8Bit Graustufe -> 16Bit RGB565 Farbwert.
Kannst du meinetwegen mit Gimp anlegen (als 1px × 256px Bild, und im
build-Prozess dann in dein Projekt mit reinkompilieren)
ist schnell gebaut, in der Laufzeit unschlagbar, und braucht vermutlich
trotz 512 Byte Table weniger Flash als eine Umrechung über HSV mit
Double-Precision-Komponenten.
Wenn der Farbverlauf dynamisch wechselbar sein muss, hängt's von der
Bildgröße und verfügbaren RAM ab. Kann gut sein dass sich dann das
Vorberechnen einer solchen Tabelle im Arbeitspeicher immer noch lohnt.
Hallo zusammen,
danke für die Ideen mit dem HSV Farbraum, damit hat es funktioniert.
H = 120° * Ladezustand_in Prozent / 100;
S & V ergeben sich aus dem Grauwert.
HSV -> RGB konvertieren.
Ja mit HSV ist es wirklich ein Dreisatz.
Danke & Gruß.
Thread beobachten
Seitenaufteilung abschalten