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
Gast
#1022403
schau dir mal die Fax4 Kompression von Tiff an.
Gast
#1022404
Gast
#1022409
Run Length Encoding ist gut und einfach. Wenn die Bilder viele senkrechte Elemente haben kann sich Zeilenweises XOR lohnen.
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 :)
vielen dank leute, sowas hab ich gesucht!
Och stimmt, Run-length encoding scheint echt easy zu sein und genau das Richtige :)
Gast
#1022426
Du hast ja nicht gesagt, wie groß das Bild voher ist: Lege einfach fest, dass das Bild nicht mehr 128..512Pixel groß sein darf ;-)
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.
Gast
#1022560
>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.
Gast
#1022573
@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
Evtl. vorher noch einen einfachen 1 pixel Entrauscher Laufen lassen. Zeig doch mal´n typisches Bild.
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.
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
Bitte melde dich an, um einen Beitrag zu schreiben.