Ideen für inen einfache, Verlustfreie komprimierung von 1Bit Bitmaps

[µluxx .. (uluxx)]

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

[Peter (Gast)]

schau dir mal die Fax4 Kompression von Tiff an.

[Stefan Salewski (Gast)]

http://en.wikipedia.org/wiki/Run-length_encoding

[Skua (Gast)]

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

[A. F. (artur-f)]

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/code/huffman/huffman.htm

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 
:)

[µluxx .. (uluxx)]

vielen dank leute, sowas hab ich gesucht!

[A. F. (artur-f)]

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

[Matthias L. (Gast)]

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

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

;-)

[Läubi .. (laeubi)]

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.

[Stefan Salewski (Gast)]

>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.

[Stefan Salewski (Gast)]

@Autor:  Läubi [e-mail]

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

[Skua C. (skua)]

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

[Läubi .. (laeubi)]

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.

[(prx) A. K. (prx)]

Läubi [e-mail] 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.