Tutorial Arbeiten mit Dateien auf binärer Ebene

[Furtbichler]

Zitat:

Zitat von Aphton (Beitrag 1201553)

Inhalt nach einer "Übersetzung in binär"
"01000001010000100100001101000100"

Die Länge ist von 4 auf 4 * 8 gestiegn, also um 800%.

Na und? Dafür lässt sich das dann u.U. viel besser komprimieren, weil ja in der binären Darstellung z.B. Wiederholungen viel wahrscheinlicher sind. Fragt sich nur, ob man die Komprimierung dann auf weniger als 4 Bytes bringt. Zudem widersprichst Du dir hier selbst, denn Du behauptest, das sich die Entropie bei unterschiedlicher Darstellung nicht ändert.

[Aphton]

Edit: Blödsinn

[Furtbichler]

Na, nee, eigentlich ist deine Begründung 'falsch', weil sie nur zwei Beispiele nennt.
Und auch noch davon ausgeht, das die 'binäre Darstellung' als 8-bit ASCII erfolgt. Under Delphi > 2007 wären das ja eh 2-Byte pro Char :stupid:

Die Frage ist, wie man komprimiert? Indem man die Bytes verdichtet oder die Bits.

Aber ist egal und Thema für einen anderen Thread.

[Aphton]

Edit: @Furchtbichler.. du könntest recht haben :stupid:

[Popov]

Zitat:

Zitat von Fehlersucher (Beitrag 1201561)

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:

Zitat von Popov (Beitrag 1201578)

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:

Zitat von Popov (Beitrag 1201588)

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.

[MeierZwoo]

Zitat:

Zitat von Popov (Beitrag 1201592)

Du gibst doch zu, dass man Bitmaps in der Regel gut komprimieren kann, oder?

In der Regel eben nicht!

Meine Anmerkungen bezogen sich auf Deine Erklärung zur Kompression von BitMaps per 1en und 0en. Und das führt eben nur bei Sonderfällen zur Verkleinerung, nicht im Allgemeinfall. Und der Allgemeinfall (die Regel) ist nunmal alles Mögliche, bloß keine Simpel-Grafik.

Zitat:

Zitat von Popov (Beitrag 1201592)

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

Du mußt mir nicht erkären, wie eine BitMap aufgebaut ist. Dazu brauche ich auch keinen HexEditor, die Syntax des Dateiformats kenne ich (fast) auswendig. Verwechsele mich nicht mit dem trollenden TE.

Zitat:

Zitat von Popov (Beitrag 1201592)

wer speichert schon eine bunte Herbstlandschaft als Bitmap?

Ich!

Daß man allgemeine Bilder nicht als BitMap speichert, sondern als JPG oder GIF oder .. stimmt nun evtl. nur für Leute, denen es egal ist, ob das Original erhalten bleibt. Deshalb speichern Leute, denen das NICHT egal ist, eben weiter als BitMap oder als TIFF (weil TIF-Encoding eben keine Veränderung bedeutet, sondern eine Archivierung mit exakter Reproduktions-Möglichkeit des Originals).