Diskussion:Datenkompression

aus Wikipedia, der freien Enzyklopädie

Lempel Ziv und alles Algorithmus-verwandte sollte -- eigentlich in Kompressionsalgorithmus verlegt werden.

pkzip gibt es unter Windows auch, nicht nur unter Linux. --Michael 06:40, 29. Mai 2003 (CEST)

---

ACHTUNG: Arc wurde zu einer Begriffklärungsseite - bitte entsprechend neu präzisieren! -- lg Robodoc 00:16, 9. Feb 2004 (CET)

es ist extrem anmaßend, 7-zip in eine reihe mit shannon, dem begründer der informationstheorie, zu stellen. besonders, da historisch bedeutsamere programme (z.b. bzip, compress, pkzip) fehlen

Dann bist du herzlich eingeladen genau diese wichtigen Meilensteine hier passend zu ergänzen. -- Alexander.stohr 02:21, 5. Mai 2004 (CEST)

nein. dann ist es angebracht, alle nicht meilensteine zu löschen

Inhaltsverzeichnis 1 Artefakte bei PNG? 2 Eineindeutig 3 links? 4 biologische Kompression 5 arithmetische codierung

[Bearbeiten] Artefakte bei PNG?

Ich ging bisher davon aus, dass PNG verlustfrei komprimiert (also wie ZIP, GZIP usw.). Artefakte sind aber immer ein Zeichen von Informationsverlust. Warum sollten die also bei PNG oder GIF auftreten?--SiriusB 15:11, 28. Jul 2004 (CEST)

Das Downsampling auf 8Bit Farbpalette und die dadurch entstehenden Farbverfälschungen habe ich als Kompressionsartefakt eingestuft. Das ist zwar bei PNG nicht zwangsläufig so da es 24 bit Farben + 8bit Transparenz zulässt, dennoch wird bei den allermeisten PNGs die Farbpalette benutzt.
Wenn man dem Downsampling absieht sind sie aber tatsächlich verlustfrei. - Xorx77 19:53, 28. Jul 2004 (CEST)

Es sind aber keine Kompressionsartefakte. Die Farbverfälschung entsteht schon vorher, bei der Anpassung des Farbformats. Dass GIF nur 256 Farben speichern kann, hat mit der eigentlichen Kompression - und um die geht es hier ja - nichts zu tun. -- 3247 20:59, 24. Jan 2006 (CET)

"allermeiste PNGs" ... eine gewagte Behauptung. :-) Es kommt sicher auch darauf an, was für Bilddaten als PNG gespeichert werden. Wenn es für Zeichnungen als "GIF-Ersatz" benutzt wird, reichen 8 Bit aus und PNG komprimiert i.A. dann sogar besser als GIF. Für Fotos und Zeichnungen mit Farbverläufen u.Ä. muss man natürlich 24 Bit (bzw. 32 Bit, wenn mit Alphakanal) nehmen. Und dann ist PNG immernoch besser, als ein unkomprimiertes Bitmap durch einen "generischen Kompressor" wie Zip/Gzip/Bzip2 zu jagen. --RokerHRO 19:17, 13. Sep 2004 (CEST)

Ich habe "allermeiste" benutzt, weil es einen sehr triftigen Grund gibt 24Bit + 8Bit Transparenz PNGs nicht zu verwenden: der Internet Explorer stellt diese nicht korrekt dar. - Xorx77 20:42, 13. Sep 2004 (CEST)

Das ist vor allem ein triftiger Grund, den MS IE nicht zu benutzen;) Aber mal davon abgesehen: für die 24-Bit kodierung eines Fotos braucht man keine Transparenz, und solche PNGs werden im IE auch korrekt angezeigt. -- D. Düsentrieb (?!) 20:47, 13. Sep 2004 (CEST)

"Das ist vor allem ein triftiger Grund, den MS IE nicht zu benutzen" - Ich weiß, aber sag des mal allen IE-Benutzern ;-) Allerdings wird für Photos zum komprimieren wohl meist JPEG im Netz verwendet, weil es kaum Vorteile bringt Photos verlustfrei zu komprimieren. Man sieht den Unterschied eh nicht (wenn mans richtig macht natürlich nur) - Xorx77 15:15, 14. Sep 2004 (CEST)

Danke erstmal für die Antworten. Wie sieht die Komprimierbarkeit bei 48+16 Bit aus, was PNG ja auch unterstützt? Verwendet das überhaupt jemand? Wenn ja, wo werden 281 Billionen Farben und 65536 Transparenzstufen gebraucht?--SiriusB 15:47, 14. Sep 2004 (CEST)

Was willst Du zur "Komprimierbarkeit" bei 48+16 wissen? Es funktioniert wie bei 24+8. Benutzt werden mehr als 8 Bit pro Kanal u.a. in der Medizin. --Harmonica 16:15, 18. Nov 2004 (CET)

frage an die "auflistung der methoden", welchen sinn hat diese? hier scheinen wahllos einige formate aufgezaehlt zu werden, andere nicht. wenn wenigstens eine korrelation erfolgt waere, zum bsp. gif = lzw oder pcx/bmp = rle, um zu zeigen welche formate welche verfahren benutzen, aber so? fast alle formate in denen dateien auf dem rechner vorliegen bedienen sich verschiedener kompressionsalgorithmen. egal welches bildformat, audioformat oder videoformat, nur jeweils 2 oder 3 formate aus 1000den sind unkomprimiert, vllt sollte man eher diese nennen ;-) im uebrigen vermisse ich andere kompressionsverfahren, wavelet basierte zum bsp (wie fuer viel mehr als nur fuer jpeg2000 eingesetzt!), sicher gibt es hier schon gute erklaerende seiten in der wikipedia, muesste man mal die links heraussuchen und hier setzen... Tsukasa 01:41, 6. Dez 2005 (CET)

[Bearbeiten] Eineindeutig

Habe das zuerst für einen Rechtschreibfehler gehalten, tut mir leid. Was ist mit injektiv? Ich finde das klingt (ein)eindeutiger, weil man entweder den Begriff Injektivität kennt und also weiß was gemeint ist, oder ihn eben nachschaut, ist dort ja ganz gut erklärt. Bei eineindeutig werden es wohl ziemlich viele einfach als eindeutig lesen. -- KL47 19:23, 25. Sep 2004 (CEST)

Ich hab mal eineindeutig verlinkt, ist ein Redirect auf Injektivität. Besser so? Direkt "injektiv" zu schreiben ist für viele wohl unverständlich. Alternativ könnte man "in beide Richtungen eindeutig, also injektiv" schreiben. -- D. Düsentrieb ⇌ 22:02, 25. Sep 2004 (CEST)

Gut, ist denke ich deutlich so. Habe noch also eindeutig in beide Richtungen angefügt, um es ganz klar zu machen. -- KL47 14:02, 26. Sep 2004 (CEST)

Hi, eineindeutig heißt, dass eine Abbildung sowohl injektiv als auch surjektiv ist. Dieser Fall wird als bijektiv bezeichnet. -- ThePacker 9. Jul 2005 20:37 (CEST)

Im Zusammenhang mit der bijektiven Abbildung wird von einem Isomorphismus gesprochen. Ist das wirklich richtig? Ich frage mich, welche Verknüpfung zwischen den verschiedenen Zeichen definiert ist, die linear abgebildet werden kann. Nicht jede bijektive Abbildung ist automatisch ein Isomorphismus. -- Alexander Holzbach 06.11.2006

[Bearbeiten] links?

ich bin dafür den link auf die projektarbeit von martin fiedler rauszunehmen. selten so etwas "unwissenschaftliches" gelesen. ist zwar sehr prosaisch und locker, dadurch leider unerträglich durch unhaltbare aussagen. da gibts wirklich besseres!

dafuer dann lieber einen benchmark link hinein, zum bsp maximumcompression.com [[1]] Tsukasa 01:33, 6. Dez 2005 (CET)

[Bearbeiten] biologische Kompression

Inwiefern haben Introns etwas mit Kompression zu tun - sind sie nicht einfach "Overhead"? Margay 11:16, 29. Mai 2005 (CEST)

ich denke da gibt es einen zusammenhang... bei sogenannten 64k oder 4k intros gibt es wie der name suggeriert eine obergrenze der dateigroesse... also packt man diese normalerweise so gut man kann ein... das ganze waere noch nicht relevant fuer diesen artikel... aber folgendes macht es dann doch relevant: es gibt nicht wenig forschung und entwicklung aus dieser szene die sich um packer-tools dreht... gute beispiele sind das aeltere und nicht frei verfuegbare kkrunchy und das neueste crinkler (eine mischung aus linker und paq-basierter datenkompression)... bei datenkompression geht es nicht nur um den algorithmus der verwendet wird sondern um den einsatz aller moeglicher techniken um das ziel, eine kleinere datengroesse zu ereichen naeherzukommen... Tsukasa 12:03, 2. Jan 2006 (CET)

habe ich jetzt "intros" und etwas namens "introns" verwechselt...? komische ueberschrift (biologische kompression) anyways... Tsukasa 12:04, 2. Jan 2006 (CET)

[Bearbeiten] arithmetische codierung

habe ich da etwas nicht verstanden? unter der ueberschrift arithmentische codierung finde ich hier auf den ersten blick woerterbuchbasierte codierung. arithmetische codierung ist meiner ansicht nach etwas anderes... hier nuetzt man die historie nicht zum woerterbuch-lookup sondern zum vorhersagen der naechsten sequenz, des naechsten zeichens, dabei speichert man nicht fundorte sondern nur wahrscheinlichkeitsannahmen oder ablehnungen... muss hier nicht etwas korrigiert werden im artikel? Tsukasa 01:32, 6. Dez 2005 (CET)

Meinst Du die Ueberschrift? Das habe ich jetzt mal geaendert.

Die Nennung der Arithmetischen Kodierung zusammen mit der Huffman Kodierung im Abschnitt Entropiekodierung gehoert da auch nicht hin, aber ich sehe gerade keinen besseren Platz. --Krille 23:10, 21. Dez 2005 (CET)

"h.264" und "mpeg" ist falsch katalogisiert... sowohl x264 als auch xvid zaehlen zu mpeg4 codierern, daher besser beide unter mpeg... allerdings implementieren diese verschiedene teile des mpeg4 standards... verschiedene profile... - btw: ich frage mich ob es sinn macht hier alles aufzuzaehlen, oder nicht einfach entsprechende links der klassen von encodern zu setzen..., sonst wird der artikel hier mit implementierungs-links der encoder vollgemuellt... Tsukasa 10:54, 2. Jan 2006 (CET)