Diskussion:Datenkompression/Archiv

message: Ich habe den Eintrag editiert, da Shannon und Kolmogorow keine Informationswissenschaftler, sondern Mathematiker waren (siehe z.B. die entsprechenden Wikipedia Einträge). 
Der Begriff der Information unterscheidet sich in der Informationswissenschaft ganz erheblich vom nachrichtentechnischen Informationsbegriff, den Shannon seiner Arbeit zu Grunde legt. Shannon und Kolmogorow haben mit der Disziplin der Informationswissenschaft eher wenig zu tun.
--Me again 15:05, 20. Feb. 2010 (CET)
thread_title:  Shannon und Kolmogorow waren keine Informationswissenschaftler 

message: 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)
replies: text: 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)
replies: text: 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)

text: "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)
replies: text:  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)
replies: text:  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)
replies: text:  "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)

text: 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)

text: 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)
thread_title:  Artefakte bei PNG? 

message: 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 [] Tsukasa 01:33, 6. Dez 2005 (CET)
thread_title:  links? 

message: Inwiefern haben Introns etwas mit Kompression zu tun - sind sie nicht einfach "Overhead"? Margay 11:16, 29. Mai 2005 (CEST)
replies: text: 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)
thread_title:  biologische Kompression 

message: Vielleicht hatte ich auch nur einen Prof, der das zu genau sah - keine Ahnung: Meiner Meinung nach ist der Redirect von Datenreduktion auf Datenkompression grundlegend falsch, da eine Kompression (zip, rar, flac) grundsätzlich verlustfrei ist, wohingegen eine Datenreduktion (mp3, ogg) immer verlustbehaftet ist, da bestimmte Daten weggerechnet werden. Kann jemand was damit anfangen? 87.168.62.33 04:08, 28. Apr. 2007 (CEST)
replies: text: Stimmt schon … in der „Alltagssprache“ hat sich aber auch „verlustbehaftete Kompression“ eingebürgert. Ich finde es nicht verkehrt, beides in einem Artikel zu besprechen, da die verlustbehafteten Verfahren üblicherweise auch von verlustfreien Techniken Gebrauch machen, aber die Begriffe sollten (möglichst weit oben) erläutert werden (einschließlich der eigentlich falschen Verwendung des Wortes „Kompression“). – 91.4.7.59 13:59, 29. Apr. 2007 (CEST)
thread_title:  Datenreduktion != Datenkompression? 

message: Ist das schon eine Datenkompression? Ich meine unglücklich formuliert.-- Kölscher Pitter 11:45, 3. Jun. 2008 (CEST)
replies: text: Nein ist es noch nicht. Eine Vermeidung von Datenaufkommen kann durch verschiedene Wege erreicht werden: bspw. weniger genaues Sampling (16 statt 24 bit) niedrigere Abtastrate, oder durch eine effiziente Codierung in Bezug auf die Länge/Umfang der Daten. Für Den Begriff Datenkompression haben sich mittlerweile weniger genaue Definitionen durchgesetzt, was zu einer Unschärfe führt. Deswegen ist Datenkompression umgs. heute die Anwendung unterschiedlicher Reduktionsformen. Der Satz in der Definition soll veranschaulichen, dass es um die Reduktion von Daten geht (gleich welcher Form) - wenn ich die Daten anschließend übertrage, so vermeide ich unnötiges Datenaufkommen, indem ich sie vorher effizient codiere. -- ThePacker 15:53, 3. Jun. 2008 (CEST)
replies: text: Da kann ich dir nicht folgen. Du meinst die Reduzierung der Auflösung. Damit ist ein Informationverlust gegeben. Das ist keine Suche nach redundanten Informationen.-- Kölscher Pitter 09:44, 4. Jun. 2008 (CEST)
replies: text:  Hmm, ich versuch es mal anders, man kann Datenkompression verwenden, um die Daten effizienter zu codieren. Das erledigt man am besten vor einer Übertragung der Daten, um so ein erhöhtes Datenaufkommen zu vermeiden. Die Situation ist Verhgleichbar mit der Verwendung des gzip-Algorithmus den ein Webserver verwenden kann, wenn der Browser in der Lage ist die gzip-codierten HTML-Seiten zu decodieren. Dann kann der Betreiber der Webseite eine gzip-Codierung verwenden, um so die anfallenden Transferkosten zu reduzieren. Dadurch sinkt die zu transportierende Datenmenge. Wenn der Webseitenbetreiber einen Tarif gewählt hat, der abhängig vom Transfervolumen der Daten ist, dann ist es für ihn ökonomischer die Datenmenge zu reduzieren - egal ob er verlustfrei oder verlustbehaftet arbeitet. -- ThePacker 13:26, 4. Jun. 2008 (CEST)
thread_title:  Vermeidung von Datenaufkommen 

message: Vielleicht könnte man diesen Artikel neu gliedern, denn irgendwelche Archiv-Programme mit Kompressionsalgorithmen und Quellcodierungsverfahren zusammen zu stecken ist vielleicht nicht günstig.
Mein Vorschlag wäre das:
Die ganzen Verfahren wie MP3, JPEG, usw, packt man in einen Artikel Quellcodierung, in dem vielleicht auch Verweise auf Zeichensätze, usw. sind. Da könnte man solche Verfahren nach der Art des Signales das sie kodieren ordnen und somit eine Einführung in die Materie geben. Als Definition würde ich vorschlagen, Quellcodierungsverfahren bilden Signale in digitale Daten ab.
Kompressionsalgorithmen wie der Huffmann bleiben hier, oder werden in einen eigenen Artikel zusammengefasst. Als Definition würde ich vorschlagen. "Kompressionsalgorithmen versuchen müglichst gute Codierungsformen für Daten zu finden".
Packprogramme bekommen einen eigenen Artikel.
Natürlich wird alles verlinkt.
Ich glaube ein großes Problem hier ist die Unterscheidung zwischen Daten und Signalen. Signale sind physikalische Repräsentationen von Nachrichten und somit immer prinzipiell analog. Die meisten Quellcodierungsverfahren wie MP3 benutzen zwar heute meistens ein einfacheres Quellcodierungsverfahren, wie beispielsweise PCM, als ersten Schritt, dies ist aber nicht prinzipiell nötig. Die Kompandierung von G.711 wurde beispielsweise in der Anfangszeit analog realisiert.
Was haltet Ihr davon?
--Casandro 22:04, 17. Jun. 2008 (CEST)
thread_title:  Vorschlag zur Neugliederung des Artikels 

message: hallo
folgende elementare Sachen werden vom Artikel überhaupt nicht beantwortet:
* welche Kompressionsalgorithmen/-programme arbeiten kontinuierlich ( so dass sie perfekt in einer Befehlsverkettung verwendet werden können auch für mehr oder weniger endlos grosse Datenmengen) ? 
und/bzw.
* wie gross ist dabei noch der (RAM-)Speicherbedarf ?
--Itu 16:25, 25. Feb. 2009 (CET)
thread_title:  Kontinuierlichkeit von Kompression /Speicherbedarf ? 

message: Betrifft diese Änderung: Stimmt die Aussage ist falsch, aber aus einem anderen Grund: Die Kompressionsrate kann je nach Programm variieren, abhängig davon wie gut die Kompressionsheuristik ist. Beispielsweise kann man bei gzip zwischen faster und better wählen, je nach dem ob man besonders schnell oder besonders gut komprimieren will. Zu einer Originaldatei kann es daher mehrere komprimierte Versionen geben. Im mathematischen Sinne handelt es sich daher nicht mal um eine Abbildung, also Funktion, sondern um eine Relation. Sie muss aber auf jeden Fall umkehrbar sein! Ich formulier das mal. --Suricata 11:33, 15. Aug. 2009 (CEST)
thread_title:  Verlustfreie Komprimierung bijektiv? 

message: Ich denke, man sollte die Einleitung ändern, da es nicht allgemein stimmt, dass kein Informationsverlust auftreten darf. bei verlustbehafteter Komprimierung ist es unvermeidlich, das ein Teil der Infos verloren geht (deshalb heißts ja auch "verlustbehaftet"). --MrBurns 00:53, 26. Nov. 2009 (CET)
replies: text: Bestimmt ist das Richtige gemeint, dennoch wird höchstens die Übertragungszeit verringert. Die physikalische Geschwindigkeit der Datenübertragung bleibt gleich. -- 77.188.11.226 23:58, 20. Feb. 2010 (CET)
thread_title:  Einleitung ändern 

message: In dem Artikel würde ich den Artikel zu Packprogramm verlinken wollen. --83.169.20.121 18:37, 20. Jan. 2010 (CET)
thread_title:  Link auf Packprogramm 

message: Ich empfinde das Beispielbild für Kompressionsartefakte bei Bildern sehr schlecht. Erstens ist es winzig, zweitens zeigt es eine Ausschnittsvergrößerung - gehört die jetzt zum Originalbild oder ist es eine mit höherer Kompression gespeicherte Variante? Optimal wäre ein Bild ohne Kompression, eine Vergrößerung eines Ausschnitts, ein Bild mit Kompression (und entsprechenden Artefakten) und dann von der selben Stelle eine Ausschnittsvergrößerung. Das wären dann natürlich vier Bilder, dürfte aber wesentlich mehr einleuchten. Moredread (nicht mit einer Zeitangabe versehener Beitrag von Moredread (Diskussion | Beiträge) 14:11, 22. Jun. 2008 (CEST)
thread_title:  Beispielbild für Kompressionsartefakte in Bildern 

message: Eigentlich sollte JPEG doch in der mittleren Spalte stehen, da auch der JPEG-Standard einen "lossles mode" anbietet? (nicht signierter Beitrag von 134.60.209.123 (Diskussion | Beiträge) 13:29, 12. Dez. 2008 (CET)
thread_title:  Bekannte Methoden zur Quellcodierung 

message: Ich finde das s/w-Beispiel nicht so toll. Wie wär's mit dem Bild rechts? --Leyo 15:10, 14. Jul. 2011 (CEST)
thread_title:  Anderes oder zusätzliches Beispiel für Kompressionsartefakte 

message: Moin, wieso wird man von Quellencodierung zu Datenkompression weitergeleitet? Das ist nicht deckungsgleich. Der nachrichtentechnische Bezug beinhaltet ganze zwei Spiegelstriche unter dem Punkt "Datenübertragung" ... tolle Wurst!
-- 31.150.66.189 17:38, 15. Jan. 2012 (CET)
thread_title:  Quellencodierung in der Nachrichtentechnik 

message: [.... „Reflexions sur la propriété d’une courbe algébraïque dont les contours marqueraient les traits d’un visage connu“ (Livorno 1770, 8°.), in dieser Schrift entwickelt der Graf die fast komische Idee, ob es nämlich nicht möglich wäre, einem Mathematiker das Porträt einer bestimmten Person zu schicken, in lauter algebraischen Formeln ausgedrückt. Aus denselben könnte dann der Fachmann eine krumme Linie feststellen, welche den Schattenriß dieser Person darstellte....] Gemeint ist Lamberg, Maximilian Joseph Graf von (GND=100176410) Aus: Wurzbach, Band 14, S.45. 14:17, 26. Jul. 2016 (CEST)
thread_title:  Lamberg 1770