mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Poti -> RGB Farbrad


Autor: -J VV (doppio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: B. Limer (b8limer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hier ist mal eine VB.NET Funktion um einen Farbgradienten zu 
generieren
    Private Function MakeGradient() As Drawing.Image
        Dim img As New Drawing.Bitmap(30, 1536) 'Deklaration des Bitmaps, auf welches der Farbverlauf gezeichnet wird.
        Dim red As Integer = 255 'Anteil an Rot
        Dim green As Integer = 0 'Anteil an Grün
        Dim blue As Integer = 0 'Anteil an Blau
        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'
        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
            For k As Integer = 0 To 29 'Mein Bild ist jetz z.B. 30 Pixel hoch.
                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.
            Next
            Select Case count 'Da wird überprüft, das wie vielte Mal die Schleife 256 überschritten hat. Jenachdem werden die RGB-Werte verändert
                Case 0
                    If Not green = 255 Then
                        green += 1
                    End If
                Case 1
                    If Not red = 0 Then
                        red -= 1
                    End If
                Case 2
                    If Not blue = 255 Then
                        blue += 1
                    End If
                Case 3
                    If Not green = 0 Then
                        green -= 1
                    End If
                Case 4
                    If Not red = 255 Then
                        red += 1
                    End If
                Case 5
                    If Not blue = 0 Then
                        blue -= 1
                    End If
            End Select
            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.
                count += 1
            End If
        Next
        Return img 'Das Bitmap mit dem Farbverlauf wird zurückgegeben
    End Function

Ich glaube man sieht gut wie der Gradient gemacht wird.

Autor: NoNever (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Google mal nach HSV ferbraum, dass ist genau das was du suchsts.

Autor: -J VV (doppio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 :-)

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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:CI...

Stefan

Autor: -J VV (doppio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für eure Antworten, ich melde mich zurück ;-)

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: -J VV (doppio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: -J VV (doppio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jemand Erfahrungen diesbezüglich?

Autor: Shuzz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-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.

Autor: -J VV (doppio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antwort. Ich denke probieren geht über studieren. Melde 
mich, wenn das Ding läuft ;-)

Autor: -J VV (doppio)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: M. B. (Firma: TH Nürnberg) (ohmen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: -J VV (doppio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: M. B. (Firma: TH Nürnberg) (ohmen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: -J VV (doppio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: -J VV (doppio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-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.

    cli();

    if( count == 0 )
    {
      //setzen der neuen Farbe
      color[0] = temp[n + 2];
      color[1] = temp[n + 1];
      color[2] = temp[n    ];
    }

    ...


Du kannst das zb in dem Teil machen, in dem du deine LED beim 
Zählerstand 0  ein (bzw. ausschaltest)

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: -J VV (doppio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.