mikrocontroller.net

Forum: Projekte & Code BMP/JPEG/GIF/PNG nach C-Code konvertieren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Marco G. (mg-programmer)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Bei der Anzeige von Bildern auf Display am Mikrocontroller kommt es 
immer wieder vor, dass man die entsprechenden Bilder erst einmal in ein 
compiler-verträgliches Format konvertieren muss.
Da ich (und auch andere Forenbenutzer) keine akzeptable Lösung für 
dieses Problem fand habe ich mich dazu entschlossen, selbst einen 
Konverter dafür zu schreiben.
Diesen möchte ich euch nicht vorenthalten und stelle ihn euch zur 
Verfügung.

Er kommt mit folgenden Bildformaten zurecht:
- bmp
- png
- gif
- jpeg

Als Ausgabeformat kann man wählen zwischen
- Schwarz/weis (1Bit/Pixel)
- 8Bit Graustufen (8Bit/Pixel)
- RGB444 (12Bit/Pixel)
- RGB565 (16Bit/Pixel)
- RGB666 (18Bit/Pixel)
- RGB888 (24Bit/Pixel)

Beim auszugebenden Array kann man vorgeben, wieviele Werte pro Zeile 
angezeigt werden sollen.
Je nach Koordinatensystem des Displays am Mikrocontroller kann das Bild 
an x- und y-Achse gespiegelt werden.

Falls jemand noch Verbesserungsvorschläge zu dem Konverter hat darf er 
sie mir gerne mitteilen. Ich bin gespannt auf eure Kritik

Autor: Torsten R. (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
9 lesenswert
nicht lesenswert
Marco G. schrieb:

> Falls jemand noch Verbesserungsvorschläge zu dem Konverter hat darf er
> sie mir gerne mitteilen. Ich bin gespannt auf eure Kritik

Link zu einem Github-Repo würde ich mir angucken, aber eine exe-file? 
Warum das?

: Bearbeitet durch User
Autor: Zorg (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
> Link zu einem Github-Repo würde ich mir angucken, aber eine exe-file?

Die ist ganz harmlos. Verschlüsselt die Festplatte, versendet Spam, lädt 
KiPos herunter, DoS't ein paar andere Rechner, rechnet an einem 
verteilten Projekt für Biowaffen mit, attackiert Server im Internet, 
versucht deinen router zu knacken um 0900-Rufnummern anzuwählen - aber 
das alles ganz sauber im Hintergrund, du wirst es kaum bemerken!

Autor: Marco G. (mg-programmer)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Na das in Thread so schnell eskaliert hätte ich jetzt auch nicht 
erwartet...

Mir persönlich geht es eher gegen den Strich, wenn ich mir 
unvollständigen Quellcode runterladen, compilieren und dann feststellen 
muss, dass noch irgendwelche Abhängigkeiten fehlen die ich mir mühselig 
zusammensuchen muss.
Ich habe das Programm mit Qt geschrieben und aufgrund der vielen 
Abhängigkeiten gleich compiliert und als Installationsdatei zur 
Verfügung gestellt. Somit sollte es für jeden einfach handzuhaben sein.

Wem das nicht zusagt kann sich auch gerne selbst etwas schreiben

Autor: Harald W. (wilhelms)
Datum:

Bewertung
9 lesenswert
nicht lesenswert
Marco G. schrieb:

> Wem das nicht zusagt kann sich auch gerne selbst etwas schreiben

Du kannst aber schon zugeben, das das starten eines EXE-Files aus
unklarer Quelle ein ziemliches Risiko darstellt.

Autor: Torsten R. (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Hallo Marco,

Marco G. schrieb:

> Wem das nicht zusagt kann sich auch gerne selbst etwas schreiben

Schuldigung, aber Du hattest um Verbesserungsvorschläge und Kritik 
gebeten!

Zwei Antworten würde ich jetzt auch nicht "Eskalation" nennen ;-)

Ich finde so ein Tools nützlich. Allerdings, würde ich es mit einem 
command line interface bedienen wollen, um es in builds mit zu 
integrieren (ich gehe mal davon aus, dass Du Qt verwendest, weil das 
Tool eine GUI hat).

mfg Torsten

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marco G. schrieb:
> Als Ausgabeformat kann man wählen zwischen
> - Schwarz/weis (1Bit/Pixel)
> - 8Bit Graustufen (8Bit/Pixel)
> - RGB444 (12Bit/Pixel)
> - RGB565 (16Bit/Pixel)
> - RGB666 (18Bit/Pixel)
> - RGB888 (24Bit/Pixel)

Und das für eine Anwendung im Mikrocontroller?

Ach nö.

Ich hatte hier vor langer Zeit schon mal sowas Ähnliches vorgestellt, 
damals ging es mir um das Darstellen von Map-Kacheln (Google, OSM usw.) 
auf einem µC. Die gewöhnlichen PC-Formate (GIF, PNG, JPG) sind in ihrer 
Dekodierung viel zu aufwendig für einen kleinen µC und BMP ist viel zu 
platzfressend.

Deshalb hatte ich mir ein farbreduziertes Format ausgedacht, was zwar 16 
bis 24 Bit Farbe prinzipiell kann, aber davon eben nur 48 verschiedene 
Farben pro Bild. Dafür läßt es sich leicht dekomprimieren und liefert 
bei eher plakativen Bildern ne gute Qualität. Wenn überhaupt, würde ich 
nur sowas verwenden, aber keine BMP's in 565 oder noch breiter.

Auch die Gegenseite hatte ich hier schon mal gepostet, als Bildkonverter 
für die Lernbetty. Macht aus relativ beliebigen Bildern Graustufe mit 2 
Bit pro Pixel.

Nun, daß du hier ne EXE angeheftet hast, stört mich nicht (bin für sowas 
gerüstet), aber die EXE hättest du dir sparen können und stattdessen 
eine ordentliche Dokumentation deines Projektes als PDF posten können. 
Also was das soll, wie das im Detail funktioniert, welche Strukturen du 
vorgesehen hast, wie das zugehörige GDI aussehen soll und so weiter.

W.S.

Autor: Undank ist des.. (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
W.S. schrieb:
> Und das für eine Anwendung im Mikrocontroller?
>
> Ach nö.

Wenn man mit den Möglichkeiten nichts anzufangen weiß, ist das kein 
Grund, undankbar zu sein und in die "Verunglimpfung"-Posaune zu blasen.
Hier teilt einer völlig uneigennützig sein Wissen - und wird angemacht!

"Undank ist des ..."

Autor: Homer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daten unter Linux oder vielleicht auch Cygwin in C Header umwandeln:

xxd -i foo.bin > foo.h

Autor: flups (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Hi,

ich finde das Projekt super, allerdings hätte ich auch Ängste die .EXE 
auszuführen. Ohne ein gesichertes System, mache ich sowas grundsätzlich 
nicht und ich rate jedem dazu es ebenfalls niemals zu machen.

Hast du nicht vielleicht das ganze Projekt zum selber anschauen und 
kompilieren?

Autor: Micha H. (Firma: Dg3brb) (kanadakruemel)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Mit der .c/.h Export Funktionalität von Gimp kommt man auch recht weit. 
Allerdings deckt das wahrscheinlich nicht alle Funktionen des Programms 
vom TO ab. Eine Kommandozeilenversion würde ich allerdings auch 
hilfreich zwecks Build-Automatisierung finden.
Ansonsten: ein nützliches kleines Tool und Dank an den TO (mit der 
Hoffnung auf den Quellcode) für die Veröffentlichung.

Gruß,
kanadakruemel

Autor: Quarktasche (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als ich diese Funktion benoetigte,
habe ich Gimp verwendet.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Homer schrieb:
> oder vielleicht auch Cygwin

xxd lässt sich problemlos als native Win32-Anwendung übersetzen, so daß 
man keinen Linux-Emulationslayer braucht.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
6 lesenswert
nicht lesenswert
Marco G. schrieb:
> Ich habe das Programm mit Qt geschrieben

Falls du nicht gerade eine kommerzielle Qt-Lizenz hast, dann bist du
allerdings dadurch nun sogar verpflichtet, es zumindest unter
LGPL weiterzugeben.

Dass man parallel zum Sourcecode eine .exe-Datei für diejenigen
weitergibt, die 1.) damit überhaupt was anfangen können und 2.) keine
Lust haben, es sich selbst zu compilieren, dagegen spricht allerdings
nichts.

Grundsätzlich finde ich ansonsten die Idee nicht so schlecht.  Für
pure 1-Bit-Grafiken genügt mir auch Gimp oder ImageMagick mit Ausgabe
als XBM, aber gerade die gewichteten RGB-Grafiken brauchen immer
irgendeine Verarbeitung.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha H. schrieb:
> Eine Kommandozeilenversion würde ich allerdings auch hilfreich zwecks
> Build-Automatisierung finden.

+1

Ich baue sowas auch ganz gern ins Makefile des jeweiligen Projekts
ein.

Autor: Marco G. (mg-programmer)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Hallo zusammen,

vielen Dank für die vielen gut gemeinten Beiträge.
Ich habe mir die ersten Kritiken zu Herzen genommen und das Programm als 
Kommandozeilentool weiterentwickelt.
Zu einem späteren Zeitpunkt wird dann auch noch eine passende GUI dazu 
kommen, damit auch diejenigen, die mit Kommandozeilen nichts zu tun 
haben wollen auch auf ihre Kosten kommen.
Desweiteren habe ich das Projekt als Quellcode bei Github eingestellt, 
sodass sich jeder überzeugen kann, dass es nicht an geheimen 
Biowaffenprojekten mithilft ;-)
Hier der Link dazu:

https://github.com/MG-Programmer/imageConverter

Autor: Marco G. (mg-programmer)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Marco G. schrieb:
>> Ich habe das Programm mit Qt geschrieben
>
> Falls du nicht gerade eine kommerzielle Qt-Lizenz hast, dann bist du
> allerdings dadurch nun sogar verpflichtet, es zumindest unter
> LGPL weiterzugeben.
>
> Dass man parallel zum Sourcecode eine .exe-Datei für diejenigen
> weitergibt, die 1.) damit überhaupt was anfangen können und 2.) keine
> Lust haben, es sich selbst zu compilieren, dagegen spricht allerdings
> nichts.
>
> Grundsätzlich finde ich ansonsten die Idee nicht so schlecht.  Für
> pure 1-Bit-Grafiken genügt mir auch Gimp oder ImageMagick mit Ausgabe
> als XBM, aber gerade die gewichteten RGB-Grafiken brauchen immer
> irgendeine Verarbeitung.

Ich habe das Tool hauptsächlich dafür gebraucht, um Pixel im RGB444 
Format platzsparend in einem byte-Array unterzubringen.
Es werden hier immer 2 Pixel in 3 Byte gespeichert. So etwas ist dann 
mit Gimp nicht mehr möglich und deshalb habe ich es auch ursprünglich 
geschrieben.
Da ich bestimmt nicht der einzige mit diesem Problem bin und auch schon 
viel Hilfe zu anderen Problemstellungen aus der Community bekommen habe 
dachte ich, dass man dieser auch mal etwas zurückgeben sollte.

Autor: Marco G. (mg-programmer)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
So. Jetzt sind beide Projekte (command line tool und gui) als separate 
Projekte auf Github verfügbar.
Ich freue mich auf weitere Anregungen und Kritik.

https://github.com/MG-Programmer/imageConverter

Autor: Mr. Claudius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es ein Ausgabeformat für 1 Bit, welches auf den KS0108 
Displaycontroller zugeschnitten ist, also pro Byte 1x8 Pixel?

Autor: Marco G. (mg-programmer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mr. Claudius schrieb:
> Gibt es ein Ausgabeformat für 1 Bit, welches auf den KS0108
> Displaycontroller zugeschnitten ist, also pro Byte 1x8 Pixel?

Ja das ist mit meinem Programm auch möglich. Das Ausgabeformat ist dann 
"Mono".
Ist dann schwarz/weiß und jedes Pixel benötigt 1 Bit => 8Pixel/byte

Autor: W.S. (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Undank ist des.. schrieb:
> Wenn man mit den Möglichkeiten nichts anzufangen weiß, ist das kein
> Grund, undankbar zu sein und in die "Verunglimpfung"-Posaune zu blasen.
> Hier teilt einer völlig uneigennützig sein Wissen - und wird angemacht!

Nee, mein Lieber, so ist das nicht, sondern: Wenn jemand sich was 
ausgedacht hat und dabei die Verhältnisse auf einem durchschnittlichen 
µC zu wenig bedacht hat, dann kommt dabei eben etwas heraus, was man nur 
schlecht gebrauchen kann, weil es einem den Speicher zustopft. Das ist 
der Kernpunkt und hier wird keiner "angemacht" (scheußliches Wort!), 
sondern in aller Ruhe auf diesen Punkt hingewiesen.

Dabei gibt's dafür eine deutlich bessere Lösung. Aber man muß das eben 
wollen und nicht wie du von Verunglimpfung reden.

W.S.

Autor: Torsten R. (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:

> Nee, mein Lieber, so ist das nicht, sondern: Wenn jemand sich was
> ausgedacht hat und dabei die Verhältnisse auf einem durchschnittlichen
> µC zu wenig bedacht hat, dann kommt dabei eben etwas heraus, was man nur
> schlecht gebrauchen kann, weil es einem den Speicher zustopft.

Ich glaube Du hast nicht ganz verstanden, was Marco da gemacht hat. Er 
extrahiert aus gängigen Grafik-Formaten die Daten, befreit sie von 
Meta-Daten und liefert die Rohdaten in für Mikrocontroller optimierter 
Form.

mfg Torsten

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marco G. schrieb:
> Desweiteren habe ich das Projekt als Quellcode bei Github eingestellt,

Ein Lob dafür. Sehr gut!

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
W.S. schrieb:
> Verhältnisse auf einem durchschnittlichen µC

Im Durchschnitt war der Dorfteich einen Meter tief …

Was auf einem ATmega8 völlig untragbar ist, ist auf einem
„durchschnittlichen“ ARM oft genug schon nur noch noise floor.

Wenn man an einem Controller überhaupt irgendwelche Grafik betreiben
will, dann wird man vermutlich nicht gerade die allerkleinsten dafür
nehmen.  Wenn man sich aber für eine Grafikausgabe entschieden hat,
dann muss man irgendwie auch in der Lage sein, die Daten dafür im
Programmcode unterzubringen.  Einzige Ausnahme: man will nur pure
Texte oder Linien zeichnen, dann braucht man natürlich keinerlei
Bilddaten im Code.  Bislang habe ich aber in allen Projekten, bei
denen ein Grafikdisplay im Spiel war, in der Tat auch Bilddaten mit
dabei gehabt.

Autor: Marco G. (mg-programmer)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> Nee, mein Lieber, so ist das nicht, sondern: Wenn jemand sich was
> ausgedacht hat und dabei die Verhältnisse auf einem durchschnittlichen
> µC zu wenig bedacht hat, dann kommt dabei eben etwas heraus, was man nur
> schlecht gebrauchen kann, weil es einem den Speicher zustopft.

Gerade weil mir die Verhältnisse auf einem Mikrocontroller bekannt 
sind habe ich das Programm geschrieben. Wie weiter oben beschrieben 
packt er die Pixeldaten beim RGB444 Format platzsparend in 1,5Byte/Pixel 
und nicht wie andere in 2Byte und verschwende bei jedem Pixel 25%(4Bit).

Ich habe es auch geschrieben, weil ich einen konkreten Anwendungsfall 
dafür habe und auf einem kleinen TFT mit 18Bit Farbtiefe Bilder ausgeben 
muss.
Das Projekt läuft allerdings auch mit einem STM32L4 (ARM), sodass ich 
dafür genügend Resourcen habe.

Dass Bilder den Speicher "zustopfen" liegt in der Natur der Sache.
Um die Bilder auch auf einem kleinen Mikrocontroller verfügbar zu machen 
habe ich die Möglichkeit der Skalierung eingebaut, wobei die Farbtiefe 
auf bis zu 1Bit pro Pixel reduziert werden kann. Somit können Bilder 
auch auf einfachen, monochromen Grafikdisplays ausgegeben werden. Die 
Bilder werden in jedem Fall speicherplatzsparend in einem Array 
hinterlegt.

Autor: Mr. Claudius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marco G. schrieb:
> Ja das ist mit meinem Programm auch möglich. Das Ausgabeformat ist dann
> "Mono".
> Ist dann schwarz/weiß und jedes Pixel benötigt 1 Bit => 8Pixel/byte

Ich habe mich unklar ausgedrückt: meine Frage bezog sich nicht auf die 
Farbtiefe, sondern auf die Organisation der Pixel.
Beim KS0108 werden immer 8 Pixel in Y-Richtung gleichzeit beschrieben, 
während der automatische Adressinkrement in X-Richtung geht, daher finde 
ich ein Format sinnvoll, bei dem die Bytes einfach der Reihe nach zum 
Display geschaufelt werden können (und alle 128 Bytes die Y-Adresse zu 
inkrementieren), ohne nach jedem Schreibvorgang X- und Y-Adresse neu 
setzen oder Pointer neu berechnen zu müssen.

Autor: Marco G. (mg-programmer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mr. Claudius schrieb:

> Ich habe mich unklar ausgedrückt: meine Frage bezog sich nicht auf die
> Farbtiefe, sondern auf die Organisation der Pixel.
> Beim KS0108 werden immer 8 Pixel in Y-Richtung gleichzeit beschrieben,
> während der automatische Adressinkrement in X-Richtung geht, daher finde
> ich ein Format sinnvoll, bei dem die Bytes einfach der Reihe nach zum
> Display geschaufelt werden können (und alle 128 Bytes die Y-Adresse zu
> inkrementieren), ohne nach jedem Schreibvorgang X- und Y-Adresse neu
> setzen oder Pointer neu berechnen zu müssen.

Ja, das ist auch möglich.
Das Tool verarbeitet die Pixel standardmäßig von link nach rechts und 
von oben nach unten und schreibt sie dementsprechend in das Array.
Es ist hierbei möglich, sowohl die X- als auch die Y-Richtung zu ändern 
und somit den vom KS0108 benötigten Pixelstrom von oben nach unten und 
von links nach rechts zu erzeugen.

Autor: W.S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mr. Claudius schrieb:
> Ich habe mich unklar ausgedrückt: meine Frage bezog sich nicht auf die
> Farbtiefe, sondern auf die Organisation der Pixel.
> Beim KS0108 werden immer 8 Pixel in Y-Richtung...

Nein, das ist nicht das Thema einer Bild- Text- oder Grafikdarstellung, 
sondern es ist das Thema eines GDI. Es ist mit Sicherheit falsch, sich 
mit Grafikformaten auf eine ganz bestimmte Display-Art festzulegen.

Stattdessen sollte man sich Gedanken machen über ein platzsparendes, 
also komprimiertes Format, das sich aber dann bittsehr ohne viel Aufwand 
zum Darstellen dekodieren läßt. Die üblichen Formate (JPG, PNG, GIF) 
sind für kleine µC ziemlich schlecht geeignet und BMP oder Artverwandtes 
ist einfach sehr platzaufwendig.

Deshalb der Gedanke an die Reduzierung der im Bild verwendeten Farben 
auf ein verträgliches Maß - so daß man das Ganze passabel komprimieren 
kann - und dann selbige per Palette in die reale Farbe umsetzen.



Marco G. schrieb:
> Gerade weil mir die Verhältnisse auf einem Mikrocontroller bekannt
> sind habe ich das Programm geschrieben. Wie weiter oben beschrieben
> packt er die Pixeldaten beim RGB444 Format platzsparend in 1,5Byte/Pixel
> und nicht wie andere in 2Byte und verschwende bei jedem Pixel 25%(4Bit).

Das verstehe ich noch nicht als platzsparend. Du speicherst pro Pixel 
eben soviel Bit, wie dessen gewünschte Farbauflösung. Das ist im Prinzip 
BMP und ungenutzte Bitmuster sind vergeigt - und das ist eben nicht 
platzsparend, weil unkomprimiert.

Wenn du tatsächlich echte Bilder in Echtfarbe darstellen mußt, dann sehe 
ich das ja ein, aber in den allermeisten Fällen hat man im konkreten 
Bild weniger als 2^Bitanzahl Farben - und wenn es denn doch so viele 
seien sollten, dann kann man ohne wirklich unerträgliche 
Qualitätseinbuße die Anzahl der Farben reduzieren. Ich häng dir mal was 
dran: Originalbild mit etwa 90000 Farben, dann als BMP, aber auf 200 
Farben reduziert, dann BMP und auf nur 100 Farben reduziert.

Es sind nur 8 Bit BMP's, also unkomprimiert und nicht in einem 
µC-gerechten Format.

Man kann aber erkennen, daß schon bei 200 tatsächlichen Farben das Bild 
für einfache Anzeigezwecke völlig ausreichend ist. Tja - und bei diesen 
200 Farben kann man das Ganze mit relativ einfachen Mitteln 
komprimieren. Ich hatte das damals so gemacht, daß ich mir eine 
Bitbreite ausgesucht habe, davon etwa 3/4 als mögliche Farben vorgesehen 
habe und den Rest für Wiederholungen vorgesehen habe. Bei den damaligen 
Kartenbildern waren das 6 Bit, davon 0..47 echte Farben 
(Paletteneinträge) und 48..63 für mögliche Wiederholungen. Bei 8 Bit und 
eher fotoartigen Bildern würde ich 0..240 für Farben vorsehen und 
241..255 für die Anzahl von Pixelwiederholungen. Das läßt sich 
ausgesprochen leicht dekodieren und schafft eine dezente Kompression, 
die bei relativ gleichförmigen Bildern bis zu Faktor 8 schafft.
Mal ein paar Zahlen (Karte vom gesamten Deutschland):
Zoomlevel  8 = 1.8 MB,
Zoomlevel  9 = 6.6 MB,
Zoomlevel 10 = 21 MB
bis hin zu Zoomlevel 13 = 701 MB
(Die Zoomlevel entsprechen denen von Googlemaps, da sieht man bei Level 
13 den Flughafen Tegel schon etwa drei Finger breit auf'm Laptop)

Das ist insgesamt fast genauso komprimiert wie JPG. Aber leichter zu 
dekodieren - zum Preis der Reduzierung der pro Kachel vorhandenen 
Farben, nicht jedoch der darstellbaren Farbtiefe.

W.S.

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werfe zum Vergleich mal das Image-Convert Tool von FTDI in die 
Runde:
http://www.ftdichip.com/Support/Utilities.htm#EVEImageConverters

Ja, okay, sicher, das ist erstmal für FT8xx, ist ja jetzt nur mal als 
Anregung gedacht was andere so machen.

Interessant ist an dem das die Bilder ZLIB komprimiert werden, das spart 
kräftig Platz bei Bildern mit homogenen Flächen die man vorher auch 
vorzugsweise nur in .png verarbeitet hat um Kompressions-Artefakte zu 
vermeiden, so etwa für Icons.
Mal abgesehen von den ganzen Formaten in die man noch 
runter-konvertieren kann.

Mit der aktuellen Version 0.9.1 muss man aufpassen, die hat per Default 
Dithering an, damit werden die Bilder dann mal eben doppelt so gross wie 
sie sein müssten.
So falls das jemand ausprobiert.

Wobei, Beispiel und so, in dem Fall wird das Bild vom Grafik-Chip wieder 
entpackt, ich weiss jetzt nicht wie aufwändig das auf dem Controller 
selber zu implementieren wäre.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten R. schrieb:
> Ich finde so ein Tools nützlich. Allerdings, würde ich es mit einem
> command line interface bedienen wollen, um es in builds mit zu
> integrieren

Gibt es alles bereits, z.B. convert aus dem ImageMagick Projekt:

http://imagemagick.org/script/index.php

Grafik-Format dann nach Gusto, z.B. XPM (C-Source).

Auf kleinen µC angenehmer ist evtl. sowas wie Portable Anymap, dann man 
direkt im Binärformat einbinden und einfach auswerten kann: Wozu den 
Umweg über enie C-Quelle, wenn das Formal dermaßen einfach ist :-))

https://de.wikipedia.org/wiki/Portable_Anymap

http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Wozu den Umweg über enie C-Quelle, wenn das Formal dermaßen einfach ist

Weil man Grafikformate schlecht in den Code linken kann?

Klar kann man das auch über objcopy aus reinen Binärdateien tun, aber 
wirklich einfacher finde ich das auch nicht unbedingt.

Außerdem ging es ihm ja auch und gerade um Sonderformate wie 12 
Bit/Pixel, da bist du mit den Standardtools dann wirklich 
aufgeschmissen.

Solange es ein XBM oder XPM tut, kann man natürlich auch 
Standarwerkzeuge nehmen.

Autor: Pelikan Fritz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo , wie kann ich die kon. Bilder speicher ? bin im Happylab Salzburg 
habe eine Einschulung für die cnc gemacht (totaler Anfäger)vielen Dank 
Fritz

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Marco,
habe dein Programm runtergeladen und benutze es aktuell in einem 
Projekt. Es funktioniert super und hat mir die aufwendige Einarbeitung 
in Grafikformate ersparrt. Vielen Dank dafür.

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Maco wäre der Aufwand groß eine Funktion für das asm Format 
einzufügen.
.db

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.