Freier Kompressionalgorithmus für TI DSP

Hallo,

probier doch erst mal mit den verschiedenen verlustfreien Kompressionsmethoden die es es für den PC so gibt ob sich die Filtertabellen gut komprimieren lassen. Wenn der Entpacker mehr Platz benötigt als eingespart wird ist das Ganze doch sinnlos. Welcher schlanke Algorithmus sich da eignen würde hängt ja auch von den Filtertabellen ab ob diese sich dadurch ausreichend gut komprimieren lassen.

Bye

Hallo Uwe,

Uwe Hercksen schrieb:

Der vorgesehen Platz im Flash für die Tabellen ist 6MB, so groß sollten die Libs zur Dekomprimierung nicht werden. Mir ging es in erster Linie auch darum, ob jemand zufällig Code kennt, der von der _Lizenz_ her passt und sich auf einem DSP ohne große Verrenkungne implementieren läßt. Alles was ich bisher so gefunden habe, steht unter (L)GPL, was ich nicht verwenden kann. Das Rad nochmal neu erfinden möchte ich aber auch nicht unbedingt, wenn es von der Komplexität über RLE hinausgeht.

Ciao Siegbert

Ich hab's jetzt nicht vor mir, aber sind nicht bei den Codebeispielen für C64 Benchmarks dabei, die auch Audio/Video Compression enthalten? Das sollte als TI eigener Code benutzbar sein.

Ansonsten rfc1950 +

Einen fröhlichen Tag wünschend LOBI

Hallo,

die Programme zur Dekomprimierung sollten wohl schon wesentlich kleiner sein. Aber wenn man mit dem ganzen Aufwand nur 7 MB an Tabellen in das Flash bekommt und dann doch noch mehr Flash braucht war die Anstrengung vergeblich. Mich würde es halt beruhigen wenn ich vorher feststellen kann das verschiedenen Kompressionsverfahren wenigstens 50 % Platz einsparen, sind es nur 10 % würde ich gleich mehr Flash vorsehen.

Bye

Ich täte mir die Struktur der Filtertabellen ansehen und schauen, ob eine Differenzbildung oder Approximation (z.B. sinc) plus Abspeichern nur der Differenzen, ggf. Huffman-codiert, eine entsprechende Einsparung bringt.

Am besten passt man die Kompressionsverfahren an die Art der Daten an, im besten Fall legst Du nur noch die Formel für die Tabellen ab.

Oder Du testest einfach mal gängige Verfahren, z.B. LZW per ZIP, und implementierst dann einen passenden Dekomprimierer.

Es gibt keine GPL-lizenzierten Algorithmen ;-)

_Algorithmen_ per se sind generell erstmal frei, nur die individuelle Ausgestaltung unterliegt dem Urheberrecht.

Ganz wenige patentierte Ausnahmen (LZW) - Schutz nur für technische Anwendungen, nicht für Software per se - bestätigen die Regel und bei der 08-15 Kompression sind die allermeisten Patente wie z.B. für LZW längst abgelaufen.

Das Problem ist eher, dass Du Dich für _Deine_ speziellen Daten etwas mit Kompressionsalgorithmen befassen solltest, ja, das braucht halt leider Zeit ;-)

Gruß Oliver

Die Koeffiziententabellen werden ja ohnehin irgendwie berechnet. Pack doch dieses Programm in den Bootloader. Die Demo-Programmierer für die 4KB und 64KB Klasse machen das seit Jahren so.

XL

Bediene Dich in der BSD-Welt. Die BSD-Lizenz ist so frei, daß Du mit dem Code wirklich alles machen kannst. Zieh Dir mal den Source der letzten OpenBSD-Version (ftp://ftp.de.openbsd.org/pub/OpenBSD/4.0/src.tar.gz) und schau mach, was Du da verwenden kannst und willst. gzip, compress und zip solltest Du da garantiert finden. Nur nicht ins gnu-Verzeichnis rutschen!

Mit freundlichen Grüßen

Frank-Christian Krügel

Hätte ich jetzt auch empfohlen - die Lizenz paßt, der Code ist aber für einen kleinen 8-Bitter evtl. etwas groß - für einen dicken DSP und 6MB Daten sollte das passen.

Ob die Daten damit gut komprimierbar sind, kann er ja erstmal mit gzip ausprobieren - wenn es reicht, muß er nicht lange nach anderen, für diese Daten besser geeigneten Verfahren suchen.

cu Michael

Hallo Andreas,

Andreas Lobinger schrieb:

Hm, da werde ich mal nachschauen.

Zlib sieht schon mal prima aus, danke für den Hinweis.

Ciao Siegbert

Hallo Uwe,

Uwe Hercksen schrieb:

Die Hardware ist schon fertig, es geht nur noch darum, den Bootloader anzupassen und eben mehr ins Flash reinzukriegen ohne den Aufwand zu übertreiben. Original-Filterdaten zum Testen habe ich bisher leider noch keine zur Verfügung gestellt bekommen.

Ciao Siegbert

Hallo Oliver,

Oliver Bartels schrieb:

Das Problem ist, dass wir den Bootloader nur zuliefern und ich statt echter Daten und Applikationsroutinen nur Dummies habe. :-(

Stimmt, da habe ich mich falsch ausgedrückt.

Ich werde unserem Auftraggeber wohl Vorschläge für einen passenden Algorithmus unterbreiten. Die soll er dann selber testen und entscheiden.

Ciao Siegbert

Hallo Oliver,

Oliver Bartels schrieb:

Das Problem ist, dass wir den Bootloader nur zuliefern und ich statt echter Daten und Applikationsroutinen nur Dummies habe. :-(

Stimmt, da habe ich mich falsch ausgedrückt. Eigentlich suche ich problemlos nutzbare Implementierungen.

Ich werde unserem Auftraggeber wohl Vorschläge für eine passende freie Implementierung unterbreiten. Die soll er dann selber testen und entscheiden.

Ciao Siegbert

Hallo Uwe,

Uwe Hercksen schrieb:

Die Hardware ist schon fertig, es geht nur noch darum, den Bootloader anzupassen und eben mehr ins Flash reinzukriegen ohne den Aufwand zu übertreiben. Original-Filterdaten zum Testen habe ich bisher leider noch keine zur Verfügung gestellt bekommen.

Ciao Siegbert

Hallo Axel,

Axel Schwenke schrieb:

Die Filterdaten sind wohl Ergebnisse irgendwelcher Experimente, also leider nichts mit Berechnen drin. Das Teil hat übrigens ausreichend RAM, daran scheitert es nicht.

Ciao Siegbert

Hallo Frank,

Frank-Christian Kruegel schrieb:

An die BSDs hätte ich wirklich selber denken können, ich werde mal bei NetBSD reinschauen, deren Code sollte wirklich problemlos portierbar sein. Von gzip gibt es aber nur eine GPL-Version, oder? Zumindest der Code auf

Ciao Siegbert

Hallo Frank,

Frank-Christian Kruegel schrieb:

Merci nochmals. Hab's jetzt auch gefunden:

Bleibt noch die Portierung auf den DSP.

Ciao Siegbert

Für dich relevant ist ja nur der (De)kompressions-Teil. Dafür reicht zlib und die ist absolut frei:

XL

Das sollte mit dem KotKomposter, oder wie das TI-Dingens heißt, doch halbwegs komfortabel gehen. Unserem VisualStudio-Programmierer tropft der Zahn, wenn er sieht, wie fein man mit dem TI-Teil debuggen kann :)

Das war keine Beschwerde meinerseits, sondern eine Feststellung. Für irgendwas muss ich ja bezahlt werden. :-)

Ja, der CCS hat einige nette Funktionen, besonders auch zu Performance-Tests. Wenn er noch ein bisschen stabiler wäre, wäre er noch besser. :-) Hat schon jemand mit dem CCS 3.3 Erfahrung, ob der sich da verbessert hat?

Ciao Siegbert