Tutorial Arbeiten mit Dateien auf binärer Ebene

[jfheins]

Zitat von Aphton:

Ich bin mir nicht sicher, aber intuitiv vermute ich (es gibt bestimmt iwelche Theorien dazu), dass die Entropie sich bei einer 1:1 Übersetzung nicht ändert.

Dafür gibt es sogar eine Einheit (habe ich aber auch gerade erst entdeckt...)

Wenn ich jetzt mal ein Alphabet ausschließlich aus A-Z Großbuchstaben annehme, dann hat die Nachricht "ABCD" einen Informationsgehalt von 4,7 Shannon pro Zeichen. man benötigt also 5 Bits um ein Zeichen zu übertragen, bzw. 5*4=20 bits für die ganze Nachricht.

Für die Alternative Nachricht wären das 1 bit pro Zeichen = 32bits für die ganze Nachricht.
Ich würde sagen, Ziel verfehlt

Wenn man das jetzt noch RLE codiert kommt da sowas raus:
10 11 40 10 11 10 11 40 11 20 11 40 21 10 11 30 11 20

Das könnte man schön speichern, man kommt pro Wiederholungseinheit mit 4 bits aus. (Die erst Zahl minus 1 speichern braucht 3 bits und das Datenbit)
das macht bei 36 Wiederholungseinheiten glatt 144 bits. Hört sich nach einer Klasse Idee an

Für die Originalnachricht wurden übrigens 4 Bytes = 32 bits verwendet. Die RLE hat die Nachricht also auf das 4,5 fache aufgebläht!

[Fehlersucher]

Sollte man bei dem Algorithmus lieber mit 0 und 1 arbeiten, oder doch lieber normale chars des Alphabets?

[jfheins]

Tja, das ist jetzt die Frage was du machen möchtest. Ein allgemein anwendbarer Algorithmus zur Datenkompression sollte mit Bytes arbeiten.

Falls du deine Eingabedaten kennst und weißt dass es sich nur um Zeichen des Alphabets handelt kannst du noch mehr machen: Kodiere die Buchstaben in 6 bits (also 64 verschiedene Zeichen) und danach kannst du einen allgemeinen Standardalgorithmus drüberlaufen lassen.

Verlustbehaftete Kompression ist nochmal ein anderes Thema, das braucht man dann hauptsächlich bei Audio und Video, eher nicht bei Text.

[Popov]

Zitat von Fehlersucher:

Sollte man bei dem Algorithmus lieber mit 0 und 1 arbeiten, oder doch lieber normale chars des Alphabets?

Selbst wenn, sowas kann man nicht direkt sagen, denn eine Textdatei komprimiert man anders als eine Bitmapdatei. Eine Jpeg Datei kann man sich gleich sparen zu komprimieren, die ist schon etwas komprimiert.

Nehmen wir man du hast einen 0815 Standard 7-Bit Ascii Text. Somit ist das 8 Bit immer 0, also kann man es löschen und schon spart man pro Byte 12,5%.

Nehmen wir man du hast einen 0815 Standard 8-Bit Ascii Text. Man könnte eine Wörterliste erstellen und dann die Wörter im Text durch Adressen auf die Wörter ersetzen. Im ersten Moment erhöht sich die Dateigröße, da man jetzt die Wörterliste plus Adressenliste hat, aber falls sich Wörter wiederholen, landen sie nur ein mal in der Wörterliste. Zum Schluß spart man Platz.

Bei einer Bitmap würde ich, wie du so schön sagst, lieber mit 1 und 0 arbeiten, denn eine Bitmap hat große sich wiederholende gleiche Flächen. Da kommen schon paar hundert Nullen am Stück.

Aber wenn das alles so einfach wäre, würde es jeder machen.

[MeierZwoo]

Zitat von Popov:

Bei einer Bitmap würde ich, wie du so schön sagst, lieber mit 1 und 0 arbeiten, denn eine Bitmap hat große sich wiederholende gleiche Flächen. Da kommen schon paar hundert Nullen am Stück.

Eine BitMap-Datei ist aber nicht Flächen-orientiert, sondern Zeilen-orientiert. Was dazu führt, das Flächen gleicher Farbwerte, die senkrecht orienentiert sind, eben pro Zeile nur ein paar gleiche Bits haben (Extremfall: Senkrechte dünne Streifen).

Was beim Standardverfahren, dem TIF-Encoding, wie es viele Druckertreiber zum encoden und Drucker zum decoden verwenden, dazu führt, daß die encodeten Daten wesentlich größer als das Original werden.

Und das ganze auch nur bei einer Farbtiefe von 2 Bit. Bei größeren Farbtiefen können kaum Folgen von „0en” oder „1en” entstehen.

[Popov]

Bei Flächen meinte ich optisch gesehen, z. B. weiße Flächen auf einem Bild, was aber natürlich Zeilen sind. Und die werden oft mit Nullen aufgefüllt. Bitmap hat also viele sich wiederholen Längen.

[MeierZwoo]

Zitat von Popov:

Bitmap hat also viele sich wiederholen Längen.

Wie kommst Du darauf? Gibt es nur eine einzige BitMap? Und nur nach Deinen Vorstellungen? Und nur mit 2 Bit Farbtiefe. Und nur mit großen Flächenanteilen gleicher Farbe?

Dann sähe die Welt aber zeimlich trostlos aus.

[Popov]

Du gibst doch zu, dass man Bitmaps in der Regel gut komprimieren kann, oder? Natürlich kann eine Bitmap alles enthalten, von einer bunten Herbstlandschaft, über grüne Idylle und Gesichter, oder jede Menge weitere Natur Motive. Ok, diese Bilder haben wenige gleichfarbige Flächen, somit wären sie nicht so gut nach dem Konzept zu komprimieren. Allerdings, wer speichert schon eine bunte Herbstlandschaft als Bitmap? Kaum einer, dafür gibt es z. B. Jpeg.

Im Grunde für alles zu verwenden, sind Bitmaps inzwischen eher Buttons, Screenshots oder sonstige technische Bilder. Und die haben doch viele gleichfarbige Bereiche.

Und solltest du mir nicht glauben, spare dir vorerst die Antwort, nimm einen Hexeditor und öffne paar typische Bitmaps auf deinem Rechner und sag mir was du siehst.