epdm schrieb:> ABER mit welchem Programm macht man diese Umwandlung am besten?
Mit dem, das du dir schreibst und dann für alle anderen hier
veröffentlichst.
Hopp, ran an den Speck, trau dich :-)
> ABER mit welchem Programm macht man diese Umwandlung am besten?
Programm?
Mit ein wenig improvisierter Skriptakrobatik aus dem Ärmel auf der
Kommandozeile!
(bash, Python, Perl, ...)
Wo kommen wir denn hin, wenn wir nur noch auf Mundgerechte
Fertigprogramme setzen?
Ausserdem: ist es nicht öde, den FLASH-Platz mit soviel monotonen Daten
zu verschwenden?
Hier ist das uC.net Forum (aka "Speicherknauserer"), also sollten doch
Vorschläge auftauchen, welche mit simplen Funktionen diese Pixeldaten
aus kürzeren, weniger redundanten const Daten wieder hervorzaubern...
:-) (Run length encoded oder so)
>also sollten doch>Vorschläge auftauchen, welche mit simplen Funktionen diese Pixeldaten>aus kürzeren, weniger redundanten const Daten wieder hervorzaubern...>:-) (Run length encoded oder so)
BMP mit RLE oder PNG oder GIF -> Hexeditor -> Export als C.
Für eine "interne" Resource würde ich aber auch kein komplettes BMP etc.
mit allen Headern ablegen. Das scheint der Ursprungspost aber auch nicht
zu machen, so wie die Hex-Werte aussehen.
epdm schrieb:> damit man Bilder mit embedded Systeme auslesen und ausgeben kann,> sollten diese meines Wissens wie folgt vorliegen:
Schwachsinn. Das Bild kann man doch binär direkt ins Flash laden! Danach
braucht man im Programm nur noch die Adresse wo's abgespeichert wurde.
... man kann doch einfach das Hex kopieren und dann mit jedem beliebigen
Texteditor " " durch ", 0x" ersetzen ... fertig. Dafür braucht's nun
wirklich keine extra-Software.
Du kannst es machen wie die Gründerväter, und dein Bild mit (vermutlich
fast jeder) Bildverarbeitungssoftware in das XPM-Dateiformat
konvertieren.
Lohnt natürlich nur, wenn du mit wenigen Farben auskommst.
https://de.wikipedia.org/wiki/X_PixMap
Kommandozeile vor dem Frühstück für Alle! schrieb:> Hier ist das uC.net Forum (aka "Speicherknauserer"), also sollten doch> Vorschläge auftauchen, welche mit simplen Funktionen diese Pixeldaten> aus kürzeren, weniger redundanten const Daten wieder hervorzaubern...> :-) (Run length encoded oder so)
Hatte da mal eine Modifikation von LZ77 geschrieben, optimiert für
mitkompilierte Daten auf Microcontrollern (sprich Daten sind readonly,
kein Puffer vorhanden, in dem man das Wörterbuch vorhalten kann, sondern
Daten werden direkt weg gestreamt). Vielleicht finde ich den Code ja
noch...
epdm schrieb:> damit man Bilder mit embedded Systeme auslesen und ausgeben kann,> sollten diese meines Wissens wie folgt vorliegen:>> const UG_U16 logo_bmp[] => {
Das ist ja nun eine ziemliche Weile her, aber offensichtlich sind all
diejenigen, die diesen alten Thread wieder ausgegraben haben, keinen
Deut klüger geworden. Als ob man durch simples Exportieren von Bytes
oder LongInts aus einem Hex-Editor und voranstellen von '0x' die Sache
lösen kann. Nein, mit sowas kann man sich den Speicherplatz zumüllen,
aber zum Handhaben von Bildern in einem µC ist all sowas noch nicht
einmal der Anfang.
In der Zwischenzeit hat es hier in diesem Forum bereits einige Beiträge
gegeben (ja, auch von mir), wo dieses Problem ordentlich abgehandelt
worden ist. Offenbar hat all das nichts genützt.
So, wer mit den beiden angehängten Bildern etwas anfangen will, sollte
die Forensuche benützen.
W.S.