Bild komprimieren

Übersicht

BlitzBasic

Allgemein

	girgl Betreff: Bild komprimieren	Sa, Feb 28, 2004 17:33 Antworten mit Zitat
Servus,wie schafft mans,ein bild zu komprimieren?Also ohne tools,nur mit code

girgl

Betreff: Bild komprimieren

Sa, Feb 28, 2004 17:33
Antworten mit Zitat

Servus,wie schafft mans,ein bild zu komprimieren?Also ohne tools,nur mit code

	Edlothiol	Sa, Feb 28, 2004 18:50 Antworten mit Zitat
1. Möglichkeit: Benutz den zlib - Wrapper, der hier im Userlib - Teil ist. https://www.blitzforum.de/viewtopic.php?t=612 2. Möglichkeit: Schreib deine eigene Komprimierungsfunktion. Schau dir z.B. mal das an: http://wwwbrauer.in.tum.de/sem...rag06.html

Edlothiol

Sa, Feb 28, 2004 18:50
Antworten mit Zitat

1. Möglichkeit: Benutz den zlib - Wrapper, der hier im Userlib - Teil ist.
https://www.blitzforum.de/viewtopic.php?t=612
2. Möglichkeit: Schreib deine eigene Komprimierungsfunktion.
Schau dir z.B. mal das an:
http://wwwbrauer.in.tum.de/sem...rag06.html

	Travis	Sa, Feb 28, 2004 20:22 Antworten mit Zitat
Zitat: Die RLE-Komprimierung (engl. Run-Length-Encoding) ist die einfachste Art der Datenkompression. Kommen in dem zu komprimierendem Datenblock mehrere gleiche Zeichen hintereinander vor, wird das Zeichen nur einmal gespeichert, gefolgt von der Anzahl der Vorkommnisse. Um zu erkennen, ob das nächste Zeichen komprimiert ist, muß vor jedem Zeichen eine Art Kontrollbit stehen, welches angibt, ob das nächste Zeichen komprimiert ist oder nicht. Besonders gute Ergebnisse werden meist bei Bildern erreicht, die große einfarbige Flächen aufweisen. Im ungünstigsten Fall ist aufgrund dem Kontrollbit die komprimierte Datei größer als die Ausgangsdatei. Das müßte in BB noch relativ einfach zu coden sein. Alles was darüber hinausgeht, wäre ja schon ziemlich professionell. Da haben sich schon so manche profis den Kopf drüber zerbrochen (und anschließend wohl gut verdient).
www.funforge.org Ich hasse WASD-Steuerung. Man kann alles sagen, man muss es nur vernünftig begründen können.

Travis

Sa, Feb 28, 2004 20:22
Antworten mit Zitat

Zitat:

Die RLE-Komprimierung (engl. Run-Length-Encoding) ist die einfachste Art der Datenkompression. Kommen in dem zu komprimierendem Datenblock mehrere gleiche Zeichen hintereinander vor, wird das Zeichen nur einmal gespeichert, gefolgt von der Anzahl der Vorkommnisse. Um zu erkennen, ob das nächste Zeichen komprimiert ist, muß vor jedem Zeichen eine Art Kontrollbit stehen, welches angibt, ob das nächste Zeichen komprimiert ist oder nicht. Besonders gute Ergebnisse werden meist bei Bildern erreicht, die große einfarbige Flächen aufweisen. Im ungünstigsten Fall ist aufgrund dem Kontrollbit die komprimierte Datei größer als die Ausgangsdatei.

Das müßte in BB noch relativ einfach zu coden sein. Alles was darüber hinausgeht, wäre ja schon ziemlich professionell. Da haben sich schon so manche profis den Kopf drüber zerbrochen (und anschließend wohl gut verdient).

www.funforge.org

Ich hasse WASD-Steuerung.

Man kann alles sagen, man muss es nur vernünftig begründen können.

	TheShadow Moderator	Sa, Feb 28, 2004 20:42 Antworten mit Zitat
es gibt noch binäre bäume - aber ich habe nicht verstenden wie da die länge des codes ermittelt wird - ist irg. kompliziert Naja vor 2 jahren haben mathematiker eine 1:100 Kompression entwickelt - aber leider hört man nix mehr davon.... War wohl Marketing-Gag oder so...
AMD64 3500+ \| GeForce6600GT 128MB \| 1GB DDR \| WinXPsp2

TheShadow

Moderator

Sa, Feb 28, 2004 20:42
Antworten mit Zitat

es gibt noch binäre bäume - aber ich habe nicht verstenden wie da die länge des codes ermittelt wird - ist irg. kompliziert

Naja vor 2 jahren haben mathematiker eine 1:100 Kompression entwickelt - aber leider hört man nix mehr davon.... War wohl Marketing-Gag oder so...

AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2

	Mike Nike	Mo, März 01, 2004 12:25 Antworten mit Zitat
g, eine ähnliche Kompressionsart habe ich selbst mal entwickelt/erfunden, Travis - aber die empfand ich als recht simple. Ansonsten, wenn du eine Codekompression haben willst, kannst du z.B. die Befehle, mit dem du das Bild entworfen hast, als Bildformat speichern. Ein Bild, was aus einer einfarbigen Fläche besteht, ist dann etwa so speichern: rect,x,y,width,height,color abgekürzt und konkret: r,0,0,FF,FF,2b0 2b0 steht für 2 byte, farbwert 0 Natürlich sollte das Bild aber dann aus bestimmten Malbefehlen bestehen und nicht per Hand gemalt sein, ein digit. Foto sein, oder Ähnliches :-/ Und zu dem beträgt die Generierungszeit des bildes evtl. sehr lange :-/ Abgesehen davon gibt es natürlich noch zahlreiche Möglichkeiten, ein Bild per Code zu komprimieren. Sagen wir mal z.B. durch Farbabstufungen (Qualitätsverlust) des Bildes entsteht eine kleinere Farbpalette (z.B. 4 Byte)...
..where the only limit is your imagination.

Mike Nike

Mo, März 01, 2004 12:25
Antworten mit Zitat

*g*, eine ähnliche Kompressionsart habe ich selbst mal entwickelt/erfunden, Travis - aber die empfand ich als recht simple.

Ansonsten, wenn du eine Codekompression haben willst, kannst du z.B. die Befehle, mit dem du das Bild entworfen hast, als Bildformat speichern.

Ein Bild, was aus einer einfarbigen Fläche besteht, ist dann etwa so speichern:

rect,x,y,width,height,color

abgekürzt und konkret: r,0,0,FF,FF,2b0

2b0 steht für 2 byte, farbwert 0

Natürlich sollte das Bild aber dann aus bestimmten Malbefehlen bestehen und nicht per Hand gemalt sein, ein digit. Foto sein, oder Ähnliches :-/

Und zu dem beträgt die Generierungszeit des bildes evtl. sehr lange :-/

Abgesehen davon gibt es natürlich noch zahlreiche Möglichkeiten, ein Bild per Code zu komprimieren. Sagen wir mal z.B. durch Farbabstufungen (Qualitätsverlust) des Bildes entsteht eine kleinere Farbpalette (z.B. 4 Byte)...

..where the only limit is your imagination.

	Merced	Mo, März 01, 2004 12:59 Antworten mit Zitat
Ich hab mal ein Komprimierungsprogramm gebastelt, das ganz brauchbare Raten erzielt hat - besonders bei Bitmap-Dateien. Leider fällt mir grad auf, dass ich das immer nur in DarkBasic gemacht hab, aber in Blitz müsste es genauso funktionieren. (Wenn allgemeines Interesse besteht kann ich es gerne mal versuchen nach Blitz zu portieren und die Funktionen hier zur Verfügung zu stellen. Vermutlich wird auf das Verfahren eh jemand ein Patent haben so dass man es eigentlich nicht verwenden dürfte. Wer erfindet eigentlich so einen Schwachsinn wie Patente???) Die Grundidee ist eigentlich ganz einfach: Tausche die häufigsten Zweierkombinationen gegen die seltensten 1er-Kombinationen und merk Dir was Du getauscht hast. Ein Beispiel: Angenommen in Deiner Datei kommt 1000 mal die Kombination AF vor, aber das Zeichen # kommt nur 5 mal vor. Wenn Du jetzt überall wo ein # steht AF hinschreibst und überall wo AF steht ein # hinschreibst ergibt sich folgendes: Vorher: 1000 x 2Byte(AF) + 5 x 1Byte(#) = 2005 Byte Nachher: 1000 x 1Byte(#) + 5 x 2Byte(AF) = 1010 Byte Das sind 995 Byte gespart, fast 50%. Natürlich kommen zu dem komprimierten noch die Informationen dazu was getauscht werden muss. Und natürlich lassen sich manche Dateien besser komprimieren als andere, manche sogar gar nicht. Ach ja: Und diese Methode ist sehr langsam. Aber sie erzielt mitunter gute Raten. Meine Packroutine in DB hat Kompressionen erreicht die zwischen 30 und 105% der Kompression von WinZip 8 bei Maximalkompression lagen - je nach Datei. Und diesen Packer hab ich innerhalb von ein paar Stunden gebaut gehabt. Man könnte ihn Beispielsweise durch die Einbeziehung von RLE noch verfeinern, gerade bei Bitmaps. Eine andere Möglichkeit wäre die Datei ein zweites Mal abzusuchen um von den häufigsten Zweierkombinationen ausgehend die häufigsten Dreierkombinationen zu finden - gerade bei TrueColor-Bitmaps vorteilhaft. (Von einem anlegen einer Tabelle für alle Dreier würd ich abraten, da 256x256x256 = 16.777.216 ergibt, womit alleine die Tabelle 16 MB (!) an Speicher belegen würde.) Naja, mach mal was draus
http://www.starship-battles.de.vu http://www.venture-interactive.de.vu

Merced

Mo, März 01, 2004 12:59
Antworten mit Zitat

Ich hab mal ein Komprimierungsprogramm gebastelt, das ganz brauchbare Raten erzielt hat - besonders bei Bitmap-Dateien. Leider fällt mir grad auf, dass ich das immer nur in DarkBasic gemacht hab, aber in Blitz müsste es genauso funktionieren. (Wenn allgemeines Interesse besteht kann ich es gerne mal versuchen nach Blitz zu portieren und die Funktionen hier zur Verfügung zu stellen. Vermutlich wird auf das Verfahren eh jemand ein Patent haben so dass man es eigentlich nicht verwenden dürfte. Wer erfindet eigentlich so einen Schwachsinn wie Patente???)

Die Grundidee ist eigentlich ganz einfach: Tausche die häufigsten Zweierkombinationen gegen die seltensten 1er-Kombinationen und merk Dir was Du getauscht hast.
Ein Beispiel: Angenommen in Deiner Datei kommt 1000 mal die Kombination AF vor, aber das Zeichen # kommt nur 5 mal vor. Wenn Du jetzt überall wo ein # steht AF hinschreibst und überall wo AF steht ein # hinschreibst ergibt sich folgendes:
Vorher: 1000 x 2Byte(AF) + 5 x 1Byte(#) = 2005 Byte
Nachher: 1000 x 1Byte(#) + 5 x 2Byte(AF) = 1010 Byte

Das sind 995 Byte gespart, fast 50%. Natürlich kommen zu dem komprimierten noch die Informationen dazu was getauscht werden muss. Und natürlich lassen sich manche Dateien besser komprimieren als andere, manche sogar gar nicht. Ach ja: Und diese Methode ist sehr langsam. Aber sie erzielt mitunter gute Raten. Meine Packroutine in DB hat Kompressionen erreicht die zwischen 30 und 105% der Kompression von WinZip 8 bei Maximalkompression lagen - je nach Datei. Und diesen Packer hab ich innerhalb von ein paar Stunden gebaut gehabt.
Man könnte ihn Beispielsweise durch die Einbeziehung von RLE noch verfeinern, gerade bei Bitmaps.
Eine andere Möglichkeit wäre die Datei ein zweites Mal abzusuchen um von den häufigsten Zweierkombinationen ausgehend die häufigsten Dreierkombinationen zu finden - gerade bei TrueColor-Bitmaps vorteilhaft. (Von einem anlegen einer Tabelle für alle Dreier würd ich abraten, da 256x256x256 = 16.777.216 ergibt, womit alleine die Tabelle 16 MB (!) an Speicher belegen würde.)

Naja, mach mal was draus Wink

http://www.starship-battles.de.vu
http://www.venture-interactive.de.vu