www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Ideen für inen einfache, Verlustfreie komprimierung von 1Bit Bitmaps


Autor: µluxx .. (uluxx) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich brauche ein paar Ideen/Ansätze zur komprimierung eines Bildes.
Dabei gelten folgende Vorgaben: Verlustfrei, möglichst wenig Ram 
verbrauch, wenn möglich 128Byte bis maximal(Schmerzgrenze) 512Byte.

ich will eine S/W-Bild, mit nur einem Bit Tiefe, also Schwarz oder Weiß, 
komprimieren, da ich nicht beliebig viel Speicher zur Verfügung habe.

Zeitverbrauch steht dabei nicht im Vordergrund.

Danke schonmal,
µluxx

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schau dir mal die Fax4 Kompression von Tiff an.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Skua (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Run Length Encoding ist gut und einfach.
Wenn die Bilder viele senkrechte Elemente haben kann sich Zeilenweises 
XOR lohnen.

Autor: A. F. (artur-f) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Empfängst du die Bilder oder sollen die fest gelagert werden? Wenn ja, 
reicht dir vielleicht auch Progmem. Sonst schaue dir die 
Huffman-Codierung an:
http://www.inf.fh-flensburg.de/lang/algorithmen/co...

Bringt einiges, wenn die Verteilung der S/W Pixel ungleich ist. Oder 
noch einfacher, wenn du extern einen I2C oder SPI FRAM/EEPROM anschließt 
:)

Autor: µluxx .. (uluxx) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielen dank leute, sowas hab ich gesucht!

Autor: A. F. (artur-f) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Och stimmt, Run-length encoding scheint echt easy zu sein und genau das 
Richtige :)

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast ja nicht gesagt, wie groß das Bild voher ist:

Lege einfach fest, dass das Bild nicht mehr 128..512Pixel groß sein darf

;-)

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beitrag "[AVR ASM] Huffman (de)kompression"

RLE ist (meiner Erfahrung nach) bei 1 bit Daten sehr schlecht anwendbar.
Okay wenn das Bild große schwarze Flächen enthält (schachbrett) aber 
alles was dadrüber hinausgeht, hat man meist durch den Overhed wieder 
ein größeres Bild.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Okay wenn das Bild große schwarze Flächen enthält

Wenn (horizontal) viele gleichfarbige Pixel aufeinander folgen.
Vertikal natürlich ebenso, mit etwas umdenken.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Autor:  Läubi Mail@laeubi.de

Du hast mich doch etwas nachdenklich gemacht, da ich RLE eher für 8-Bit 
Farbtiefe kenne.

Natürlich macht der Algorithmus für 8-Bit bei monochromen Grafiken nicht 
so viel Sinn, man sollte dann wohl einen passenden verwenden, siehe etwa

http://www.binaryessence.de/dct/de000057.htm

Autor: Skua C:\> (skua)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Evtl. vorher noch einen einfachen 1 pixel Entrauscher Laufen lassen.
Zeig doch mal´n typisches Bild.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Salewski wrote:
> Natürlich macht der Algorithmus für 8-Bit bei monochromen Grafiken nicht
> so viel Sinn, man sollte dann wohl einen passenden verwenden, siehe etwa
>
> http://www.binaryessence.de/dct/de000057.htm

Ja aber da hast du das Problem: es müssen mindestens 8 aufeiandefolgende 
Pixel gleich sein, damit sich das lohnt und man bei ner Rate von 1 ist.
Gerade bei kleinen Bildern (240x64 z.B.) ist das aber sehr schwer.
Vertikal müssen dann immer mind 8 pixel gleich sein, also immer 1/8 der 
Höhe, Vertikal 1/30... Und dann hat man noch immer ein Bild was genauso 
groß ist wie vorher!

Und klar kann man das auch horizontal, vertikal, wasweißich wie quer 
machen, wird dann aber nur für einige Bilder gehen.
Huffman funktiniert (zumindest bei mir) ganz gut, und man muß 
prinzipiell nur ein byte im SRAM halten, wenn man ein Device/Display hat 
wo man die Daten blockweise hintereinander hinschreiben kann.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läubi Mail@laeubi.de wrote:

> Ja aber da hast du das Problem: es müssen mindestens 8 aufeiandefolgende
> Pixel gleich sein, damit sich das lohnt und man bei ner Rate von 1 ist.

RLE muss man nicht byteweise durchführen. Als Bitstrom mit 
unterschiedlich langen Codewörtern in Huffman encoding klappt das 
besser. Ist allerdings langsam und braucht etwas mehr Code.

Dummerweise benötigen andere Komprimierer meist deutlich RAM.

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.