Announcement: there is an English version of this forum on Ich habe nicht im Internet gesucht da ich nicht weiss mit welchen Kriterien und Begriffen ich suchen soll. Vielleicht kann mir jemand helfen und mich drauf stossen. Ausgangslage: Durch Kodierung von 8 Pixeln in einem Byte erzeuge ich mir bereits kompakte Grafiken mit 1 Bit Farbtiefe die ich durch beliebige Wahl von Vordergrund- und Hintergrundfarbe auf einem Farbdisplay darstellen kann. Auf einem 320x240 Display sind das z.B. 76800 Pixels bzw 9600 Bytes. Diese Anzahl Bytes hätte ich gerne noch verlustfrei komprimiert um Speicherplatz im Flash zu sparen. Lässt sich da noch was machen ohne den Decodier-Aufwand im Mikrocontroller groß werden zu lassen? Die Software soll ja nicht so gross werden dass sie die Platzersparnis der Grafik(en) auffrisst. Habe leider keine Erfahrung damit und suche hiermit um Hilfe.
Wenn die Graphik menschenlesbar sein soll, hast du wahrscheinlich lange Bereiche gleicher Farbe. Dann kannst du eine Lauflängenkodierung ausprobieren.
wenn man vorher noch zeilenweise verXORt kann sich die datenmenge noch erheblich verkleinern.
Schau Dir mal den Fax-Kompressions Algorithmus an. Ansonsten: Huffmann - obwohl es für Bilder bessere gibt.
Byte Sparer schrieb: > Durch Kodierung von 8 Pixeln in einem Byte erzeuge ich mir > bereits kompakte Grafiken mit 1 Bit Farbtiefe > > Auf einem 320x240 Display sind das z.B. 76800 Pixels bzw 9600 > Bytes. Diese Anzahl Bytes hätte ich gerne noch verlustfrei > komprimiert um Speicherplatz im Flash zu sparen. > > Lässt sich da noch was machen ohne den Decodier-Aufwand im > Mikrocontroller groß werden zu lassen? Was du als "großen Aufwand" für den Decoder bezeichnest, ist natürlich Geschmackssache. Meine Empfehlung wäre, ein komprimiertes Bildformat aus dem PC-Bereich zu verwenden. Da kriegst du nämlich den Encoder frei Haus. Es muß ja nicht gerade DjVu oder PNG sein (obwohl die jeweils excellent komprimieren). Aber PCX ist bspw. hinreichend einfach aufgebaut und komprimiert ganz annehmbar.
Ein ziemlich primitiver, aber daher auch mit wenig Softwareaufwand zu implementierender Kompressionsalgorithmus wurde in *.pcx-Graphikdateien verwendet. http://www.fileformat.info/format/pcx/egff.htm Wenn Du das auf monochrome Bitmaps begrenzt, und auf den Header verzichtest (alle Bitmaps haben die gleiche Größe, Farbpalette etc. ist entbehrlich), sollte, sofern Deine Bilder kein "digitales Rauschen" enthalten, das schon einiges bringen.
Huffmann Kompression ist keine allzu komplexe Kompression :)
Rufus Τ. F. schrieb: > Wenn Du das auf monochrome Bitmaps begrenzt Also sowas? Yves Klein Blue Monochrome 1961 https://www.moma.org/collection/works/80103
Je nach Menge der Bilder koennte man sich auch an einem AT45DB041D, einem 512Kx8 Flasch im SO8 Gehause versuchen.
@Blaubär (Gast) >Yves Klein >Blue Monochrome >1961 >https://www.moma.org/collection/works/80103 Mein Herr, ich glaube nicht, daß moderne Kunst ein Betrug ist. Ich weiß es.
Sabberalot W. schrieb: > Je nach Menge der Bilder koennte man sich auch an einem AT45DB041D, > einem 512Kx8 Flasch im SO8 Gehause versuchen. Abgekündigt (EOL) laut Mouser. Es gibt noch viel größere Flash ICs in SO8 oder vergleichbaren Packages, denn die Multi-MB großen PC BIOS (UEFI) werden damit gespeichert. D.h. viele MB zu annehmbaren Preisen, allerdings mit 3,3V Betriebsspannung. Außerdem kann man über MicroSD Sockel nachdenken, dann hätte man GBytes Speicherplatz und könnte z.B. Animationen darstellen. Außerdem ließen sich darüber Firmware Updates leicht einspielen - einfach SDHC Karte wechseln. Die Software gibts mit FATFS praktisch fertich.
Thread beobachten
Seitenaufteilung abschalten