[Wettbewerb] String komprimieren

Pschhhhht, man postet doch nicht sein bestes Pferd vor dem Rennen

Bei der Länge von 3600 tippe ich mal auf einen statischen Huffman encoder, da kommen bei mir ähnliche Werte raus

PS: Da geht aber noch was... Benutze deine Fantasie

(auch wenn es verlockend ist, Algorithmen zu nutzen die weit verbreitet und erprobt sind. Wir sind hier ein Forschungsteam, wir brauchen den neuen Stuff )

Meine Aktuelle Idee ist (auch wenn sie leider viel viel viel zu langsam läuft):

- Adaptiver Huffman Encoder (soweit so gut)

- Der Tree startet gleichverteilt und wird nach jedem Zeichen aktualisiert (dann braucht man den Tree nicht in den Komprimierten Daten speichern)

- Der Tree wird außerdem mit Prognosen gefüttert und aktualisiert BEVOR er überhaupt das nächste Zeichen zu Gesicht bekommt. Damit ist die Kodierung noch besser, weil im Schnitt bessere Bitraten für zu kodierende Zeichen vorliegen, wenn die Prognosen korrekt waren (was bei einfachem Text zu 90%+ der Fall ist)

Probleme:

- Tree initialisierung ist Gleichverteilt (das ist ja gerade der Trick, damit man ihn nicht speichern muss), Presets könnte man aber erstellen (Häufigkeiten der Zeichen von "allem möglichen" wie "Text", "Win32PE", "Base64", etc. Diese Presets könnte man dann bequem mit z.B. einem einzigen Byte anwählen und hätte damit vorallem zu Beginn eine bessere Kompression... Diese Presets erstellen ist aber sehr aufwendig und dafür habe ich keine Kraft)

- Tree aktualisieren ist langsam

- Prognosen erstellen ist noch viel langsamer (dafür muss man eine halbwegs gute Auswertung von allem bisher Dekodiertem durchführen...)

Wenn man das alles macht schätze ich, dass locker 50%+ drin sind. Aber das werde ich nicht hinbekommen, weil es zu viel Arbeit ist. Vllt hat ja jemand Lust die Idee umzusetzen^^

Zitat von Mars

PS: Da geht aber noch was... Benutze deine Fantasie

(auch wenn es verlockend ist, Algorithmen zu nutzen die weit verbreitet und erprobt sind. Wir sind hier ein Forschungsteam, wir brauchen den neuen Stuff

GENAU SO sehe ich das auch....

Den Code von den entsprechenden Webseiten abklimpern oder Verfahren "kopieren" das sollen Leute machen, die Fingerübungen brauchen, denn mehr ist das imho nicht.

Zitat von Mars

Ich habe vor langer Zeit mal etwas gebastelt (ein adaptiver Huffman Codierer mit coolem Tree der sich dynamisch anpasst), der läuft aber mit ca. 1 BYTE pro Sekunde^^ Also vermute ich, dass der Algorithmus in nativem AutoIt (ohne Dllcalls) mit sagen wir mal: 128+Byte/s klarkommen muss

So etwas will ich hier sehen!

Übrigens ist es sehr produktiv, solche Gespräche in einer Kneipe zu führen und dabei die "dynamischen Bäume" hinten auf Bierdeckel zu kritzeln...das wäre übrigens mal wieder fällig

Ich bin aktuell schon bei ziemlich guten Kompressionsraten von Textdateien, einiges hatte ich allerdings schon im Deskstream-Script und auch in der Steganographie erstellt.

7-Bit-ASCII, Lauflängenkodierung und ein etwas abgefahrener "Baum" und natürlich wieder mal Gequetsche von mehr als 12 Bits in ein Byte , das ist mein aktueller Stand. Bei Textdateien liege ich "ziemlich gut" im Rennen, wenn auch langsam....aber wie üblich, habe ich, sobald alles läuft, auch eine Assemblerversion (SSE und AVX512)

Das aufwendigste ist aktuell, die Bits zusammenzuquetschen, d.h. an Bitadressen zu schreiben/zu lesen und nicht an Byteadressen!

In Assembler ist das ziemlich einfach und auch schnell. Naja, vielleicht schreibe ich in AutoIt die Bits einfach als 1 und 0-Char nacheinander in eine Bytestruct und lese von dort dann in 32er Paketen über eine LUT die DWORDS aus....schaumamal.

Zitat von Mars

Wenn man das alles macht schätze ich, dass locker 50%+ drin sind

Da ist jetzt schon wesentlich mehr drin^^

Aber in dem Dilemma stecke ich aktuell auch fest: Gebe ich den (dynamischen) Baum mit in den komprimierten String, dann tun bei kleinen Strings die 256/512 Bytes so richtig weh....bei sehr großen Strings fällt das dagegen kaum auf.

Das blöde dabei ist, dass bei großen Textdateien der statische Baum völlig ausreichend ist und ich nur ein Bit im komprimierten String brauche, um diesen zu aktivieren.

Wobei ich auch bei Nicht-Textdateien (*.EXE Bilddateien usw.) mittlerweile schon unter 50% gelandet bin (bei Verwendung von dynamisch erstelltem Baum)

Ich mache es gerade so:
- Adaptiver Huffman Encoder (dank Heap (Array[2*n][3]) um den Tree zu konstruieren auch nativ recht performant)

- Im Header steht eine ID, wobei

-> 0 = Default (einfach alle 256 möglichen Symbole Gleichverteilt, ohne Anhang)

-> 1 = Hex (16 Symbole Gleichverteilt, ohne Anhang, wird nicht verwendet, aber vllt braucht man das irgendwann irgendwo)

-> 2 = Byte (hier kommt dann der min/max/exist anhang)

-> 3 = unused.

-> Hier könnte man noch zahlreiche weitere Modi hinzufügen für z.B. Base64, oder auch Vorgefertigte Wahrscheinlichkeitstabellen.

- (wenn ID = 2) Im Header steht minSymbol & maxSymbol (z.B. bei Text wäre das sowas wie 20 und 170, frei erfundene Werte)

- (wenn ID = 2) Dann Binär 150 (maxSymbol - minSymbol) Mal eine 0 oder 1 speichern, je nachdem ob das Zeichen da ist oder nicht

- Tree wird mit den vorhandenen Symbolen aufgebaut (gleichverteilt, z.B. 70 Symbole)

- Tree wird alle X Zeichen neu aufgebaut (weil es einfach zu langsam ist es nach jedem Zeichen zu machen, obwohl das eigentlich besser wäre)

- Prediction fällt leider flach. Die Ansätze die ich da habe sind zu langsam. Dann kommt man wirklich wieder bei 1Byte/sek raus.

- Vorgefertigte Tabellen fallen auch flach. Ich hab keine Lust erstmal 3 Tage lang unterschiedlichste Daten zu crawlen um mir die Tables zu basteln...^^

-> Sehr kleiner Header

- für kurzen Text ist die ID = 0 -> Header = 2 Bit, Kompression ist nicht so gut (logisch), aber bei kurzem Text besser, als wenn der Table schon länger als der Text selbst ist^^

- für langen Text ist die ID = 2 -> Header im Bereich von 100-200 Bit (je nach Anzahl verwendeter Zeichen)

- für "Kauderwelsh" ist die ID = 0 (z.B. "Dateien" die kein Text sind -> Da sind normalerweise alle 256 Zeichen drin, da braucht man nicht zu selektieren)

-> Adaptiv?

- Bei jedem Neuaufbau KANN (dafür gibt es ne config) die Wahrscheinlichkeitstabelle mit einem Wert <1.0 multipliziert werden. Der Encoder "vergisst" also ein Stück weit was er bereits gesehen hat. (je nach Parameter mehr oder weniger agressiv). Dadurch ist es möglich sich an die Daten "anzuschmiegen" und im Idealfall (der nie eintritt) ist der Tree so immer optimal für die lokal vorhandenen Daten geeignet. (die 500 "a" Chars die man aus Spaß an den Anfang gesetzt hat erhöhen also nicht mehr die Länge der Bitmuster der Sachen die man eigentlich kodieren will).

- Steuersymbole (nur eine Idee). Man könnte z.B. ein Resetsymbol (resettet die Wahrscheinlichkeiten), oder ein Boostsymbol (boostet die Wahrscheinlichkeit des letzten dekodierten Zeichens), oder ähnliches untermischen. Damit müsste man sich nochmal besser an die Daten anpassen können. Das sieht mir aber auch kompliziert aus (nicht das implementieren, sondern das "herausfinden wo ein Steuersymbol die beste Wirkung hat") also fällt es auch erstmal Flach^^

Soweit der Plan. Umgesetzt ist etwa 50%^^

Vllt bastel ich da eine kleine UDF draus wenn es fertig ist. Nach dem Wettbewerb haben wir dann 5 verschiedene ordentliche KompressionsUDF's

PS: Ich hab auch noch einen ollen arithmetischen Entropiekodierer, leider frisst der sich recht schnell fest (z.B. wenn die Schranken 1.00000000 und 0.9999999 sind und die Double Genauigkeit nicht ausreicht um weiterzugehen bis 1.000000001 und 1.000000000 die Schranken sind und 1.00000000 abgeschnitten werden kann). Die Zahlen hier sind nur ein Beispiel, meiner rechnet im Hex System, damit der kodierte Inhalt Hex und nicht Dec ist. Das Problem ist aber dasselbe. Um den sinnvoll einsetzen zu können müsste ich also erst eine Hex-Float UDF basteln die beliebige Genauigkeit beim Rechnen hat. Das wird aber nicht passieren

Zitat von Oscar

Dann sieht es ganz danach aus, dass Dein Username nichts mit Deinen AutoIt-Kenntnissen zu tun hat.

Bei AutoIt passt der Name schon ganz gut, bin momentan eher in Java unterwegs...

Zitat von Mars

Bei der Länge von 3600 tippe ich mal auf einen statischen Huffman encoder, da kommen bei mir ähnliche Werte raus

Genau, habe mir den groben Ablauf von Huffman hier angeschaut und versucht umzusetzen. Neben den komprimierten Daten übergebe ich noch das Wörterbuch. Der Decoder erstellt daraus erneut den Baum um die Bits wieder zu entpacken. Das Wörterbuch ist in diesem Beispiel 192 Bytes groß, würde aber noch kleiner gehen.

Ich beschäftige mich erst seit Dienstag mit dem Thema, daher mal eine doofe Frage. Hat der adaptive Huffman Encoder neben einer schnelleren Laufzeit (nur ein Durchgang) noch weitere Vorteile? Der statische sollte ja eine bessere Komprimierung erreichen, oder bin ich falsch?

Hier mal eine kleine Übersicht von dem "was ich denke was gilt" (das heißt nicht, dass es tatsächlich so ist. Nur mein subjektiver Eindruck)

Edit Nummer 20: Oops, es sind 2 Seiten geworden. Viel Spaß beim Lesen meine fleißigen Schüler

Entropiekodierer allgemein:

- Alle Daten haben irgendeinen Informationsgehalt. Entropiekodierer versuchen möglichst wenige Bits zu verwenden um diesen Informationsgehalt wiederzugeben.

- Huffman: Ersetzt "Symbole" (wir nutzen hier oft 8Bit Chars, aber ansich kann das "alles" sein) durch Bitfolgen die in einem Baum in einem Blatt enden (weshalb der Kodierer weiß, wann das nächste Zeichen anfängt)

- Arithmetisch: Ersetzt alle Daten durch eine Kommazahl. Genaueres muss man nachlesen. Der Witz ist: Dieser Entropiekodierer ist "quasi optimal" im Sinne von "es gibt quasi keinen besseren Entropiekodierer". Jetzt kommt eine spannende Frage: Warum gibt es überhaupt irgendwelche anderen Kodierer bzw. Kompressionsalgorithmen, wenn ein arithmetischer Kodierer schon der Beste ist?

(Einfache) Statische Version:

- Das (Wikipedia) Vorzeigebeispiel. Kommt auch gerne in der Schule oder frühen Semestern mal dran.

- Sehr einfach implementierbar/Klar definiert was man wo zu tun hat.

- Baut den Baum aus "allen" Daten auf (daher ist der Baum automatisch "optimal" aufgebaut, "globaler Kontext")

- Speichert eine Wahrscheinlichkeitstabelle, oder den Baum selbst in den komprimierten Daten.

- Wendet denselben Baum auf alle Daten an (extrem schnell, wenn man einen LUT aus dem Baum aufbaut)

- Erzielt eigentlich immer gute Kompression (Abhängig von Symbolanzahl und davon wie gut die Entropien der einzelnen Zeichen durch ganze Bits dargestellt werden können)

(Einfache) Dynamische Version:

- Im Prinzip 95% äquivalent zur statischen Version.

- Die Wahrscheinlichkeitstabelle wird gleichverteilt initialisiert.

- Nach jedem dekodierten Zeichen wird die Wahrscheinlichkeitstabelle aktualisiert und der Baum neu aufgebaut (das wars schon)

- Tausendfach langsamer als die statische Version, da man hier quasi jedes Mal einen neuen Baum züchten muss, wärend die statische Version einen einzigen Lookup in einem Array machen muss.

- Erzielt etwas schlechtere Kompression als die statische Version (da gerade zu Beginn eine Gleichverteilung angenommen wird, was ja offensichtlich nicht stimmt)

- Tradeoff zwischen schlechterer Kompression und Platzeinsparung durch kleineren Header (keine Wahrscheinlichkeitstabelle in den Komprimierten Daten)

Jetzt kommt das Große Aber:

Das "dynamische" tritt dir die Tür zu unbegrenzten Möglichkeiten auf. Vorher warst du an ein starres Konstrukt an dem man nicht viel herumschrauben kann gebunden. Klar kann man z.B. den Input vorverarbeiten ("Wörter" statt "Zeichen" als Symbole verwenden erhöht die Kompression), aber am Prinzip selbst lässt sich nichts ändern. Eigentlich hat die dynamische Version schlechtere Kompression als die statische, aber... was wäre wenn man xyz einbaut, was passiert, wenn man den Baum durch Steuerzeichen beeinflusst (z.B. "die nächsten 1000 Zeichen haben eine andere Statistik als die bisherigen, danach geht es aber mit den bisherigen weiter", Beispiel für "lokalen Kontext"), was passiert, wenn man das Nächste Symbol vorhersagt und den Baum entsprechend trimmt (damit er für das vorhergesagte Zeichen weniger Bits braucht, "lokaler Kontext"), was passiert, wenn man den Baum "vergessen" lässt was er schon gesehen hat, sodass er lokal besser angepasst ist, usw usw. Dann wird aus "schlechter" plötzlich "besser". Kleine Warnung: Der Rechenaufwand geht dabei sehr schnell durch die Decke. Hier muss man ggf. optimierte Datenstrukturen (wie z.B. einen MinHeap für den Tree) benutzen, sonst kann man bis Morgen auf das Ergebnis warten

Spoiler für die Frage:
Weil jeder (einfache) Entropiekodierer die Entropie pro Symbol (Zeichen) kodiert und NICHT die Entropie zwischen den Zeichen.
Beispiel: "1111122222333334444455555" und "5235114223133414424535251" sehen für einen Entropiekodierer "gleich" aus. Global betrachtet stimmt das, beide Strings enthalten dieselben Zeichen mit derselben Häufigkeit, ABER der erste String hat eine deutlich niedrigere Entropie und kann viel besser komprimiert werden als der 2te. Zu einer guten Kompression gehören also beide Seiten der Medaille: lokale Muster und globale Muster. Lokal ist: Wie steht mein aktuelles Symbol im Verhältnis zu seinen Nachbarn, Global ist: Wie steht mein aktuelles Symbol insgesamt zum kompletten Datensatz. Nur das globale Problem wird vom statischen Huffman (und vom arithmetischen Kodierer) gelöst, für das lokale Problem muss man sich etwas ausdenken PS: Deshalb ist es auch doof, dass immer von "Entropie" gesprochen wird und nicht von "Shannon Entropie", würde man letzteres verwenden könnte man (durch nachlesen) herausfinden, dass diese Definition nur für stochastisch unabhängige Zeichen gilt (was ja im Regelfall nicht so ist. Wir betrachten ja meistens nicht "rauschen auf 8Bit Zahlen", sondern "Text", oder "Programmcode" oder "Bitmap").

Eine andere Entropiedefinition (deren Name ich leider vergessen habe) ist: Die Länge des "kleinsten Programms" das die Daten reproduzieren kann. Damit kann man sich glaube ich besser vorstellen wie der Informationsgehalt wirklich aussieht. z.B. ein 1024x1024 Bitmap voller Schwarzweiß-Rauschen (das aber mit einer deterministischen Random Funktion erzeugt wurde) hat nur eine extrem kleine Entropie (weil man dafür mit wenigen Zeilen ein Programm schreiben kann das dieses Bild erzeugt), ein 1024x1024 Bitmap mit "echtem" Schwarzweiß-Rauschen hat extrem hohe Entropie, da man kein Programm schreiben kann das diese Daten erzeugt, ohne dass es die Daten selbst hardcoded enthält.

Auch lesenswert: https://de.wikipedia.org/wiki/Bedingte_Entropie
Mit der Info, dass die Entropie zukünftiger Zeichen gegen 0 konvergiert, je mehr Zeichen man bereits kennt. Übersetzt: Je besser ich vorhersagen kann was als nächstes Zeichen kommt, desto kleiner die Entropie. Wenn jemand deutschen Text schreibt und mit "Xyl" anfängt, weiß ich, dass er mit "ophon" aufhören wird. Entropie von "ophon" ist also = 0 (mit der Nebenbedingung, dass ich "alle vorherigen Zeichen" kenne, also quasi, "dass ich das Deutsche Wörterbuch kenne").

Hab mit Kompressionen noch nie was am hut gehabt. Tu mich auch mit der nutzung von externen libaries schwer. Aber warum nicht mal selbst versuchen

Bisheriger Stand

============================================================
Result for "Lambdax"
============================================================
Decompressed = Original: True
Length Original: 6033
Length compressed: 1690
Length decompressed: 6033
Compress-Ratio: 71.987 %
Time compressed: 143 ms
Time decompressed: 11 ms
============================================================

Da ist noch Luft denke ich

Zitat von Oscar

Eine Kompressionsrate besser als beim ZIP-Format erscheint mir zu gut, um wahr zu sein.

Nur um das nochmal deutlich zu sagen: Ein verwendetes Wörterbuch bzw. eine Ersetztabelle muss natürlich im Kompressionsformat mit enthalten sein, sodass es von der Größe her mitzählt.

Ehh, wo hast du das gesagt? Lese ich zum ersten mal

Edit: selbst beim nochmal lesen, sehe ich diese regel nirgends. Bin mittlerweile bei 72.584 %. Wenn diese art der komprimierung nicht erlaubt ist, dann bin ich raus

Wie willst du Wörterbuch-komprimierte Daten austauschen wenn du das Wörterbuch nicht vorliegen hast?
Das ist ja schlicht logisch, dass das Wörterbuch ein Bestandteil der Daten selbst ist.

Würde man deiner Logik folgen, dann würde ich ein Wörterbuch nehmen mit einem einzigen Eintrag: Dem gesamten String.
Dann bekomme ich jeden String auf 1 Byte runter komprimiert, da das Wörterbuch selbst ja nicht mit reingezählt wird.

Hmmmmmm, interessanter Ansatz, den ich mir auch schon überlegt hatte!

Nirgendwo ist die maximale Größe des Scriptes definiert.

Wenn ich also bspw. die Wortliste des Openthesaurus (Größe ca 2 MB und soviel ist das garnicht, die könnte man nämlich vorher komprimieren ) in mein Script includiere, dann damit einen "optimalen" Baum aufspanne und dann einfach nur "dröge" ersetze, dann ist das ziemlich nah am Optimum!

Aber wie bereits oben von mir gesagt.....reine Fingerübung und daher völlig außen vor, jedenfalls bei mir.

Hier geht es darum, sich selbst ein Verfahren zu überlegen, also einen Algorithmus umzusetzen.

Hehe, böse betrachtet könnte man ja die Scriptgröße * Kompressionsrate bewerten....

Da ich nicht das Rad neu erfinden wollte, denn seit es Computer gibt, wird an der Komprimierung geforscht, habe ich mich zu dieser Lösung entschieden, die aber laut den Regeln nicht erlaubt ist. Deshalb poste ich hier den Code direkt:

;Coded by UEZ build 2022-03-05 proof-of-concept version
#include <GDIPlus.au3>
#include <Memory.au3>

Func _GDIPlus_StreamImage2BinaryString($hBitmap, $sFormat = "PNG", $iQuality = 80, $bSave = False, $sFilename = @ScriptDir & "\Converted.jpg") ;coded by UEZ 2013 build 2014-01-25 (based on the code by Andreik)
    Local $sImgCLSID, $tGUID, $tParams, $tData
    Switch $sFormat
        Case "JPG"
            $sImgCLSID = _GDIPlus_EncodersGetCLSID($sFormat)
            $tGUID = _WinAPI_GUIDFromString($sImgCLSID)
            $tData = DllStructCreate("int Quality")
            DllStructSetData($tData, "Quality", $iQuality) ;quality 0-100
            Local $pData = DllStructGetPtr($tData)
            $tParams = _GDIPlus_ParamInit(1)
            _GDIPlus_ParamAdd($tParams, $GDIP_EPGQUALITY, 1, $GDIP_EPTLONG, $pData)
        Case "PNG", "BMP", "GIF", "TIF"
            $sImgCLSID = _GDIPlus_EncodersGetCLSID($sFormat)
            $tGUID = _WinAPI_GUIDFromString($sImgCLSID)
        Case Else
            Return SetError(1, 0, 0)
    EndSwitch
    Local $hStream = _WinAPI_CreateStreamOnHGlobal() ;http://msdn.microsoft.com/en-us/library/ms864401.aspx
    If @error Then Return SetError(2, 0, 0)
    _GDIPlus_ImageSaveToStream($hBitmap, $hStream, DllStructGetPtr($tGUID), DllStructGetPtr($tParams))
    If @error Then Return SetError(3, 0, 0)

    Local $hMemory = _WinAPI_GetHGlobalFromStream($hStream) ;http://msdn.microsoft.com/en-us/library/aa911736.aspx
    If @error Then Return SetError(4, 0, 0)
    Local $iMemSize = _MemGlobalSize($hMemory)
    If Not $iMemSize Then Return SetError(5, 0, 0)
    Local $pMem = _MemGlobalLock($hMemory)
    $tData = DllStructCreate("byte[" & $iMemSize & "]", $pMem)
    Local $bData = DllStructGetData($tData, 1)
    _WinAPI_ReleaseStream($hStream) ;http://msdn.microsoft.com/en-us/library/windows/desktop/ms221473(v=vs.85).aspx
    _MemGlobalFree($hMemory)
    If $bSave Then
        Local $hFile = FileOpen($sFilename, 18)
        If @error Then Return SetError(6, 0, $bData)
        FileWrite($hFile, $bData)
        FileClose($hFile)
    EndIf
    Return $bData
EndFunc   ;==>_GDIPlus_StreamImage2BinaryString

Func _StringCompress($sString)
    If StringLen($sString) < 24 Then Return SetError(1, 0, 0)
    _GDIPlus_Startup()
    Local $iLen = StringLen($sString), $iMemSize = Mod($iLen, 8) ? ($iLen + 8 - Mod($iLen, 8)) * 4 : $iLen * 4, $i
    Local $tPixelData = DllStructCreate("ubyte scan0[" & $iMemSize & "];"), $iW = Mod($iLen, 4)  ? Int($iLen / 4) + 1 : $iLen / 4
    If $iW > 65535 Then Return SetError(2, 0, 0)
    Local $hImage = _GDIPlus_BitmapCreateFromScan0($iW, 1, $GDIP_PXF32ARGB, $iMemSize, $tPixelData)
    If Not $hImage Then
        _GDIPlus_Shutdown()
        Return SetError(3, 0, 0)
    EndIf
    For $i = 1 To $iLen
        $tPixelData.Scan0(($i)) = Asc(StringMid($sString, $i, 1))
    Next
    Local $binData = _GDIPlus_StreamImage2BinaryString($hImage)
    _GDIPlus_ImageDispose($hImage)
    _GDIPlus_Shutdown()
    Return $binData
EndFunc

Func _StringDecompress($vCompress)
    If BinaryLen($vCompress) < 5 Then Return SetError(1, 0, 0)
    _GDIPlus_Startup()
    Local $sString, $hImage = _GDIPlus_BitmapCreateFromMemory($vCompress)
    If Not $hImage Then
        _GDIPlus_Shutdown()
        Return SetError(2, 0, 0)
    EndIf

    Local $binBMP = _GDIPlus_StreamImage2BinaryString($hImage, "BMP"), $iLen = BinaryLen($binBMP), $iSize =  _GDIPlus_ImageGetWidth($hImage) * 4 - 3
    $sString = BinaryToString(BinaryMid($binBMP, 55, $iSize))
    _GDIPlus_ImageDispose($hImage)
    _GDIPlus_Shutdown()
    $binBMP = 0
    Return $sString
EndFunc

Global $sUsername = "UEZ"

#Region Achtung! Diese Region darf nicht veraendert werden!
Global $hFile = FileOpen(@ScriptDir & '\original.txt', 128)
If $hFile = -1 Then Exit
Global $sOriginal = FileRead($hFile)
FileClose($hFile)
Global $iOriginalLen = StringLen($sOriginal)

Global $iTimer = TimerInit()
Global $vCompressed = _StringCompress($sOriginal)
Global $iTimeDiffComp = TimerDiff($iTimer)
;Global $iCompressedLen = StringLen($vCompressed)
Global $iCompressedLen = BinaryLen($vCompressed)

Global $iTimer = TimerInit()
Global $sDecompressed = _StringDecompress($vCompressed)
Global $iTimeDiffDecomp = TimerDiff($iTimer)
Global $iDecompressedLen = StringLen($sDecompressed)

ConsoleWrite('============================================================' & @CRLF)
ConsoleWrite(StringFormat('Result for "%s"\r\n', $sUsername))
ConsoleWrite('============================================================' & @CRLF)
ConsoleWrite(StringFormat('Decompressed = Original: %s\r\n', $sOriginal == $sDecompressed))
ConsoleWrite(StringFormat('Length Original: %i\r\n', $iOriginalLen))
ConsoleWrite(StringFormat('Length compressed: %i\r\n', $iCompressedLen))
ConsoleWrite(StringFormat('Length decompressed: %i\r\n', $iDecompressedLen))
ConsoleWrite(StringFormat('Compress-Ratio: %s %%\r\n', Round(100 - (100 / $iOriginalLen * $iCompressedLen), 3)))
ConsoleWrite(StringFormat('Time compressed: %i ms\r\n', $iTimeDiffComp))
ConsoleWrite(StringFormat('Time decompressed: %i ms\r\n', $iTimeDiffDecomp))
ConsoleWrite('============================================================' & @CRLF)
#EndRegion Achtung! Diese Region darf nicht veraendert werden!

Das Resultat auf meinem Notebook:

============================================================
Result for "UEZ"
============================================================
Decompressed = Original: True
Length Original: 6033
Length compressed: 3473
Length decompressed: 6033
Compress-Ratio: 42.433 %
Time compressed: 42 ms
Time decompressed: 13 ms
============================================================

In meinem Freebasic Programm "FB File2Bas Code Generator", das Pendant zu "File to Base64 String Code Generator", benutze ich u.a. ein Build-in LZMAT Kompressionsalgorithmus, aber wie Andy bereits geschrieben hat, wollte ich den Code nicht zu Autoit portieren, wäre aber Interessant gewesen, da die Portierung, denke ich zumindest, nicht ganz einfach ist.

Mein Ansatz ist dass ich einfach über einen Monat ein neuronales Netz trainiere um Texte zu komprimieren / dekomprimieren. Keine Ahnung ob es hinterher zu gebrauchen ist - aber was soll's. Das training wird natürlich unabhängig von AutoIt gemacht da ich sonst ja noch in 2 Jahren dran sitzen würde ;D

Testdaten lassen sich glücklicherweise auch sehr einfach generieren. Also hab ich's damit ziemlich einfach.

Bei einem NN zur Kompression ist natürlich wieder das Problem: In wie fern existiert bereits Vorwissen im Algorithmus. Angenommen ich trainiere ein 1GB NN mit unfassbar viel Text, dann kann ich extrem gut komprimieren, weil ich quasi eine Kopie von "jedem möglichen Text" in meinem Programm enthalten habe. Das wäre dann wieder soetwas wie: Ich habe das Wörterbuch nicht in den Komprimierten Daten, und ohne das Wörterbuch sind die komprimierten Daten keine valide Beschreibung der unkomprimierten Daten...

Wieder eine philosophische Fragestellung

Zitat von Mars

Das wäre dann wieder soetwas wie: Ich habe das Wörterbuch nicht in den Komprimierten Daten, und ohne das Wörterbuch sind die komprimierten Daten keine valide Beschreibung der unkomprimierten Daten...

Aber das ist doch genau der Punkt! Ähnliches hatte ich bereits in #31 gepostet.

Ab wann tut denn das Wörterbuch im Script/Programm "weh"?! Genau DAS ist das Problem!

Der aktuelle Download von 7-Zip ist entpackt auf der Platte etwas über 5MB, davon Programm und DLL zusammen 2.5 MB.

Ein vom allerfeinsten C(++)-Compiler erstelltes Kompressions-Programm, dessen "Packcode" auf eine DIN-A4 Seiten passt?!

Im Leben nicht.....

"Natürlich" ist der eigentliche Packcode Pillepalle, das wirklich Aufwendige ist die Analyse und die "optimale" Auswahl eines der dutzenden von Verfahren um "eine Handvoll Bytes" einzusparen.

Wenn ich ein compiliertes AutoItscript mit 500KB ansetze, dann blieben mir, um mit der Dateigröße von 7-Zip mitzuhalten, also 2MB an "Daten" die ich in der Datei unterbringen könnte!

2MB an verschiedensten "Wörterbüchern" oder neuronalen Netzen oder was auch immer.....

Und btw.: der Kollege Lambdax könnte das von ihm benötigte "Wörterbuch" unkomprimiert 300x nacheinander in seine EXE schreiben und die Datei wäre immer noch kleiner als 7-Zip und würde besser komprimieren! Soviel zum "Problem"!

Ist also technisch gesehen ein Pastebin-Upload der zu "komprimierenden" Daten und das Ausgeben der ID (8 Zeichen) eine valide Methode?

Zitat von Oscar

Ok, ich habe das nicht explizit gesagt/geschrieben, aber ich hielt das auch für selbstverständlich.

Man muss die komprimierte Datei ja schließlich irgendwie wieder entpacken können, z.b auf einem anderen Rechner.

Und wenn das Wörterbuch nicht mitzählt, dann kann man natürlich gigantische Kompressionsraten erzielen.

Das halte ich nicht für Selbstverständlich. Mein Gedanke war, das zwei rechner auch die selbe Kompressions technik kennen müssen um den Text zu De/Komprimieren. Warum nicht also auch eine Standartisierte Wortliste, die die meißt verwendeten Wörter einer Sprache beinhaltet. Quasi das der Komprimierungsvorgang nur jene Worte austauscht die er auch kennt. Was AspirinJunkie da erzählt halte ich für ausgeschlossen, den dann müsste jeder Rechner jeden Text der je versendet werden würde, bereits vollständig kennen. Das wäre absurd platzbedürftig, je nach fall. Aber meine methode hingegen halte ich nicht für unrealistisch.

Zitat von Oscar

Dann müssen wir die Gesamtgröße (inkl. Script und aller Zusatzdateien) vergleichen. Das wird absurd kompliziert.

Es geht hier ja nicht darum, eine Kompressions-UDF zu entwickeln. Da gibt es bereits zahlreiche Methoden, um Text/Grafik/Binaries zu komprimieren.

Ich wollte einen Wettbewerb, was mit reinem AutoIt-Code möglich ist.

Vielleicht um auch mal kuriose Lösungswege aufzuzeigen.

Alles klar, dann ist diese Variante raus. Für was anderes reicht meine Erfahrung leider nicht. Bin also gespannt was hier nächsten monat rauskommt

Zitat von Mars

Ist also technisch gesehen ein Pastebin-Upload der zu "komprimierenden" Daten und das Ausgeben der ID (8 Zeichen) eine valide Methode?

Warum nicht?!

Jetzt höre ich schon das Geheule! Und genau dieses Geheule kommt von den Leuten, die Nervenzusammenbrüche bekommen, wenn sie, mit welchem Gerät auch immer, NICHT online sind

Aber mal ohne Witz, ob man heutzutage eine Textdatei mit einer Größe von einigen Kilobytes versendet, oder nur 40% von einigen Kilobytes, das ist bei der Menge an Müll, der heutzutage das Internetz flutet, völlig unerheblich

Wahrscheinlich sehe ich das so locker, weil ich bei keinem einzigen dieser "sozialen" Medien einen Account habe und deshalb zwangsläufig online sein MUSS. Was nicht bedeutet, dass ich nicht für sämtliche Internetfähigen gadgeds Software erstelle. Bei denen auch des öfteren Komprimierungsalgorithmen verwendet werden