2 Bytes zu einem komprimieren

[schwa226]

Hi,

ich möchte gerne 2 Bytes in 1 Byte komprimieren.
Geht das? Oder besser gefragt, geht das einfach?

Ohne das man ZLib verwenden muss. Also einfach ein kleiner Algo?

Danke!

[Sir Rufo]

Zitat:

Zitat von schwa226 (Beitrag 1094995)

Hi,

ich möchte gerne 2 Bytes in 1 Byte komprimieren.
Geht das? Oder besser gefragt, geht das einfach?

Ohne das man ZLib verwenden muss. Also einfach ein kleiner Algo?

Danke!

Nein :)

Um es mal sehr vereinfacht darzustellen, wie das mit dem Komprimieren funktioniert:

Code:

aa aa aa aa aa aa aa aa aa ff ff ff ff ff cc cc cc cc cc

Komprimiert

Code:

09 aa 05 ff 05 cc

[mleyen]

50% Kompression in 100% aller Zustände? Unmöglich.
Das wäre ja als wenn man versucht 2 Bit in eins zu quetschen.:lol:

[schwa226]

Ok, Danke!

Ich habe nähmlich nur eine begrenzte Anzahl an Bytes die ich übergebe und ich wollte sie besser Ausnützen. Schade...

[Satty67]

Der RunLength Algorithmus wie ihn SirRufio gezeigt hat, ist wohl der einfachste verfügbare, der aber bei kleinen gemischen Daten eher mehr Output erzeugt.

Falls der Inhalt der Daten bekannt und veränderbar ist, wäre eine Möglichkeit Boolsche Bytes in Bits zu fassen und je nach Range Hi/Lo Nibble zu nutzen. Auch bei reinen reine ASCII-Texten lässt sich 30% sparen

[Bummi]

gibt es einen eingeschränkten Wertebereich für Deine Bytes?

[schwa226]

Es ist ein Array[0..7] of Byte.

Byte[6] und Byte[7] fallen schon einmal weg da dort eine Checksumme der ersten 6 Bytes drinnen ist.
Die 6 Bytes werden benutzt um die (unique) ID festzustellen.

Nun möchte ich die Informationen noch erweitern.
Also Byte[5] für andere Informationen nutzen.
Somit verkürzt sich die ID schon um 1 Byte.

Wenn ich es nicht komprimieren kann verkürzt sich die ID um 2 Bytes und es bleiben "nur noch" 4 Bytes übrig. (1 Byte Infos, 1 Byte Checksum)

Also von 2^48 verkürzt auf 2^32.

Ist noch nicht so dragisch, aber wenn ich noch mehr Informationen reinpacken will bleiben noch weniger Bytes für die ID.

Der Bereich der Bytes wird voll genützt, $00-$FF.

[Klaus01]

Guten Morgen,

wenn Du den Inhalt des Array beliebig bestimmen kannst, so scheint es wenigstens,
warum kannst Du dann nicht über die Größe des Arrays bestimmen
und das Array entsprechend erweitern um diese Zusatzinfos unterzubringen.

.. und die Checksumme weglassen - ist nicht die feine Art

Grüße
Klaus

[Uwe Raabe]

Wo kommt die Unique-ID denn her und wieviele verschiedene IDs sind denn so zu erwarten? Immerhin kann man mit vier Byte schon ca. zwei Milliarden IDs codieren.

[himitsu]

Zitat:

Zitat von schwa226 (Beitrag 1094995)

ich möchte gerne 2 Bytes in 1 Byte komprimieren.
Geht das?

ja eventuell

Also wenn die Bytes nicht vollständig ausgenutzt werden, dann ja.

Werden z.B. in jedem Byte nur Werte von 0 bis 15 gespeichert, dann kann man alle Zustände beider bytes in einem Byte abbilden.
Und das ist es, was komprimierungen versuchen ... sie suchen Gemeinsamkeiten/Abhängigkeiten von Bytes und brauchen so nicht alle Werte speichern, sondern nur die kleineren Informationen der Abhängigkeiten.

[BUG]

Klingt insgesammt irgendwie nach Seriennummer entwerfen oder so was in der Art.
Hab ich's getroffen? :stupid:

[schwa226]

So ähnlich.
Das Byte Array representiert eine Unique ID des Systems. Z.B per MAC oder Festplattenseriennummer.

Die Länge kann nicht geändert werden. Es müssen 8 Bytes bleiben damit man mit älteren Version kompatibel bleibt.

Ürsprünglich war gar keine Checksum oder Infos in den 8 Bytes.
Dann ist einmal eine 2 Byte Checksum dazu gekommen. (Dadurch ist die mindest App-Version feststellbar)

Nun möchte ich die Infos noch erweitern. Z.B. um eine Author ID.

Author ID ich selbst: $11
Author ID irgend ein anderer: $12
...
..
.

Will man die Erkennung nun hinzufügen ist ja eine zusätzliche Checksum erforderlich. Ansonsten kann es Zufall sein, dass genau in Byte[4] ein $11 steht und fälschlicherweise eine Author ID angenommen wird. Also eine z.B. XOR Checksum der Bytes[0..4] in Byte[5] speichern. Stimmt diese kann man sagen das Byte[4] eine Author ID ist.

Ich habe zuerst auch überlegt ob man mit 8 Bit auskommt.
Das würde aber nur z.B. 2^4 IDs und für die Checksum 2^4 Bits zulassen.
16 IDs sind mir zuwenig. 128 IDs sollten es schon sein. Dann bleibt aber nur mehr 1 Bit für die Checksum -> nicht sicher genug.

Somit werden 2 Bytes benötigt.

Man könnte aber auch 7 Bits ID und 5 Bits Checksum = 12Bits (1 1/2 Bytes) verwenden.
Liese sich das dann in 8 Bit komprimieren?

[Sir Rufo]

Um es nochmal ganz deutlich zu sagen:

Mit einem Byte kann man 256 Zustände beschreiben.
Wenn man auch genau 256 Zustände beschreiben möchte, dann kann man dieses nicht verkleinern, komprimieren, zusammendampfen, etc.
Es geht nicht, ohne Informationsverlust.

Transferleistung:

Wenn das bei einem Byte (8Bit) so ist, dann ist das bei 12Bit (mit voller Ausnutzung) genauso!

Möglicherweise wird das mit einem Quantencomputer gehen.
Dann hängt man die entsprechenden Nutzdaten an verschränkten Bits.
Somit könnte man die gesamte Lebensgeschichte mit 1Bit verschicken. :mrgreen:

[gammatester]

Zitat:

Zitat von schwa226 (Beitrag 1095340)

So ähnlich.
Das Byte Array representiert eine Unique ID des Systems. Z.B per MAC oder Festplattenseriennummer.

Die Länge kann nicht geändert werden. Es müssen 8 Bytes bleiben damit man mit älteren Version kompatibel bleibt.

Da Du ja nicht aus der Unique ID die Infos zurückrechnen willst, bietet es sich doch an, aus den Informationen ein auf 8 Bytes abgeschnittenes Hash (zB mit SHA256) zu erzeugen.