Entwickler-Ecke
Algorithmen, Optimierung und Assembler - Undo-Daten komprimieren
Spaceguide - Mi 16.02.05 14:41
Titel: Undo-Daten komprimieren
Was meint ihr ist die beste Methode, Daten, welche aus einer XOR-Verknüpfung von zwei Bildern hervorgegangen sind zu komprimieren? Lineares Run-Length-Encoding hab ich schon probiert, bringt nicht viel und bläht öfters auch mal auf. Hat sich schon jemand von Euch mit Packbits beschäftigt?
uall@ogc - Mi 16.02.05 15:00
uses zlib;
ScorpionKing - Mi 16.02.05 15:05
ZLIB +
ZIP
MfG, Scorpion!
Spaceguide - Mi 16.02.05 15:24
Ist eindeutig zu langsam.
uall@ogc - Mi 16.02.05 15:27
zlib ist nicht wirklich langsam -> kommt drauf an was du machen willst, vielleicht paar mehr infos?
tommie-lie - Mi 16.02.05 15:49
zlib [
http://www.gzip.org/zlib] in der aktuellen Version soll deutlich schneller sein. Größer werden die Daten nie.
Und wenn du mal was richtig langsames sehen willst, nimm bzip2, wenn der in Software implementiert ist, kann man ihm beim komprimieren zugucken :mrgreen:
Spaceguide - Mi 16.02.05 15:58
Nein, zLib ist schon sehr schnell für diese Kompressionsmethode. Mit RLE oder ähnlichen simplen und schnellen Verfahren werde ich wohl nicht auf eine Kompressionsrate von 1:2 kommen wie ich es mit zLib erreiche (gerade getestet).
Was ich konkret machen will: Um Schritte bei Bildbearbeitung rückgängig machen zu können muss man sich die Veränderungen merken mit Altes-Bild XOR Neues-Bild. Das kann aber ziemlich auf den Speicher gehen, z.B. Bild = 4000x4000xRGB = ~46MB pro Schritt. Ich habe es zwar soweit optimiert, dass ich das Bild in Kacheln zerlege und nur veränderte Kacheln abspeichere, jedoch kommt es oft genug vor, dass alle Kacheln verändert wurden.
tommie-lie - Mi 16.02.05 16:03
Spaceguide hat folgendes geschrieben: |
Nein, zLib ist schon sehr schnell für diese Kompressionsmethode.
[...]
jedoch kommt es oft genug vor, dass alle Kacheln verändert wurden. |
Was willst du uns jetzt damit sagen? Bist du mit zlib zufrieden, oder suchst du noch was anderes?
Spaceguide - Mi 16.02.05 16:36
Ja was besseres werde ich kaum finden. 40MB Daten packt er mir hier in zwei Sekunden, das ist doch ein sehr guter Wert. Das untere Geschwafel war für uall, er hatte nach mehr Infos gefragt.
Noch eine Frage zu zLib: Wenn ich in einen TMemoryStream hineinkomprimieren, dann wird das sehr langsam, wenn ich den Stream nicht vorher auf eine Größe setze, da anscheinend viele Reallocs vorkommen. Das Problem ist nun, woher weiss ich, wie gross ich den MemoryStream machen soll? Größe des Inputs? Halbe Größe des Inputs? Gibt es eine Schätzen-Funktion?
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!