hi,..;) das es nicht einfach ist, ist mir bewusst.
>Ich glaub ich muss Dich ent�uschen... So einfach,wie Du Dir das vorstellst ist das ganze nicht... >1. ist es sehr unwahrscheinlich, dass sich lange stellen im bin�rcode >eines bildes wiederholen, auch wenn das bild sehr �hnlich ist. wie gesagt. grunds�tzlich funktioniert das ganze spiel ja schon. und es funktioniert sogar recht gut. von dieser seite ausgehend ist es ja prinzipiell schon fertig(von vesch. optimierungsm�glichkeiten mal abgesehen). >2. gibt es sehr viel leistungsf�higere Pack-Algorithmen, als diesen, >denn Du benutzen m�chtest... Im Moment w�rde, auch wenn Dein Algorithmus >genauso funktionieren w�rde, wie Du es Dir vorstellst, gute Packer wie >RAR oder bzip2 viel besser packen, auch wenn diese nicht auf >vorinformation bauen k�nnen... >RAR hat z.B. optimierte Methoden f�r Medien, also z.B. Bilder und Sounds etc. >Auch passen diese Algorithmen optimal das was Du Blockgr�sse nennst an - >auch w�hrend des Packvorganges, d.h. sie fangen z.B. mit kleinen Bl�cken >an und setzen dann gr�ssere Bl�cke aus kleineren zusammen etc.. ups. ich will nicht packen sondern patchen. der unterschied ist enorm. denn eine einmal gepackte datei kann nicht mehr (wesentlich) weitergepackt werden. ja, und die daten liegen schon komprimiert vor(zb. tif - lzw). es gibt wesentliche teile in jeder der dateien, die man nicht immer wieder �bertragen m�sste. zb gabs bei einigen(nicht bei allen, aber vielen) bildern, eine st�ndige wiederholung in jedem 2. byte. genau da setzt dann meine "weitere" optimierung an. diese bytes aus der urspr�nglichen gel�scht ergibt eine neues bild, welches sich auch in vielen dateien stark �hnelte. bei vektordaten(konstruktionspl�ne sind auch dabei) ists noch �bler(im sinne von redundant). da sind aber auch die dateigr��en nicht so erheblich(aber immerhin so ca. 1-5mb) was ich auch nicht unbedingt(w�re nat. auch nicht schlecht*g*) brauche ist eine super-funktion, die in bruchteilen von milisekunden meine daten durchgeht. nur die 25 min f�r die erste stufe(reines patchen) f�r eine 1,2mb-datei war mir einfach zu langsam ;) eine weitere "optimierungsm�glichkeit", die ich aber noch nicht ganz zu ende begutachtet habe, waren wiederholungen in der eigenen datei. diese m�sste ich nur einmal mitgeben und dann nur noch referenzen darauf. >In diesem Bereich ist es nicht einfach weitere Verbesserungen zu erreichen... >Rein theoretisch ist es zwar wirklich so, dass man umso besser packen >kann, je mehr vorinformation hat, jedoch muss man daf�r bestehende >Algorithmen anpassen, denn diese fangen immer mit null Information an... >Solche Algorithmen kann man auch gut an bestimmte Arten von zu packende >Daten anpassen, hierzu muss man aber nicht nur mit gesunden >Menschenverstand arbeiten, sondern auch viel mit Tests... welches von den beiden traust du mir nicht zu ;)? >Du solltest es Dir wirklich schwer �berlegen, ob Du selbst weiter in >diese Richtung forschen willst... Denn das k�nnte l�nger dauern... aber nat�rlich will ich. es macht nicht nur spa�, sonder ist �beraus lehrreich >Falls es Dich trotzdem interessiert, informier Dich �ber folgende Themen: >Informationstheorie, Informationsgehalt/menge, Entropie, Redundanz, >Kodierungstheoreme, Quantisierung/Vektorquantisierung, >Kompressionsalgorithmen, Huffman, Lempel-Ziv >Hierzu findest Du bestimmt einige gute B�cher, ansonsten kannst Du mit >google starten... jetzt bist du etwas zu tief im detail ;) ich bin immer noch beim patchen.. oder der gesunde teil des verstandes fehlt.. >Wenn Du weiter machen willst, w�rde ich die Spielereien mit Texten >lassen und gleich auf bin�re Daten verallgemeinern. wie kommts zu der aussage? rein informativ! dank dir auf jedenfall mal f�r die ausf�hrliche antwort. wolfgang http://www.vbwelt.de/ | [aspdecoffeehouse] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffeehouse.asp
