Diskussion:Datenkompression/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Datenkompression/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Datenkompression/Archiv#Thema_1

Algorithmus

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)

ultimateZip kennt den black hole algorithmus, was ist das genau? konnte nix dazu finden. mfg der_eine

---

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

Shannon und Kolmogorow waren keine Informationswissenschaftler

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)

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)

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

Wieso ist das eigentlich eineindeutig? Man kann doch beispielsweise bestimmte Bild- oder Audiodaten haben, diese aber unterschiedlich komprimieren. Etwa als PNG oder FLAC mit unterschiedlichen Kompressionsstufen, PNG kann auch unterschiedliche Verfahren (etwa auch keine Kompression oder einfache Lauflängenkodierung) und mit PNGOUT kann man auch zufällig initialisierte Huffman-Tabellen oder so verwenden, um aus einem lokalen Minimum (bezüglich der Dateigröße) herauszufinden. – 91.4.12.34 04:09, 18. Apr. 2007 (CEST)

Eineindeutig heißt hier einfach nur, dass wenn du dein (verlustfrei!) komprimiertes Material dekomprimierst kriegst du dein ursprüngliches Material unverändert wieder heraus. - Xorx77 15:50, 20. Apr. 2007 (CEST)

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)

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)

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)

Datenreduktion != Datenkompression?

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)

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)

Daten != Informationen

Im Einleitungssatz steht:

Die Datenmenge wird reduziert, indem eine günstigere Repräsentation bestimmt wird, mit der sich die gleichen Daten in kürzerer Form darstellen lassen.

Darüber im Kommentar:

Keine Begriffe, wie Entropie, Information, Informationsgehalt ohne jede Erklärung. Nur Kodieren und Dekodieren

Sorry, aber Daten und Informationen sind nunmal nicht das gleiche. Wenn man in dem Einleitungssatz nicht "Informationen" statt "Daten" schreiben darf, dann ist der Satz schlicht falsch. Ein Artikel sollte nur soweit sprachlich vereinfacht werden, solange er dadurch nicht falsch wird. --Mhohner 14:14, 20. Mai 2008 (CEST)

Ich ändere das jetzt. --Mhohner 19:45, 29. Mai 2008 (CEST)

Ich verstehe Daten und Informationen anders. Es geht hier ja nicht um Informationscodierung, sondern um die Codierung von Daten. Als Daten verstehe ich eine Konkatenation von Symbolen eines Alphabets - ein reines Ingenieursproblem. Informationen sind Zusammenhänge, die ich aufgrund der Daten schlussfolgern kann. bspw. Bilder. Erst der visuelle Eindruck führt zu einem Informationsgewinn. Die Codierung von Daten findet nun einmal auf Ingenieursebene und nicht auf abstrakter Ebene statt. Deswegen halte ich den Begriff "Information" für falsch. Denn nicht alles, was wir sehen sind Informationen, sondern zunächst einmal ungefilterte Daten, erst wenn wir den Daten eine Bedeutung zuordnen und sie in Informationen anhand anhand von Redundanz und Irrelevanz gefiltert haben, erhalten wir Information(en). -- ThePacker 15:38, 3. Jun. 2008 (CEST)

Der Einleitungssatz war vereinfacht "Daten werden reduziert, indem man die gleichen Daten mit weniger Daten darstellt". Das ist einfach falsch. Weniger Daten sind andere Daten und damit nicht mehr die gleichen Daten. Kompression ist eben genau die Darstellung der gleichen Information mit weniger Daten. Genau weil Information und Daten zwei unterschiedliche Dinge sind, ist die Einleitung wie sie jetzt dasteht korrekt.

Einfach gesagt, Daten = Information + Redundanz. Daten werden nicht codiert, sondern Daten sind die Codierung von Information. (Verlustfreie) Kompression reduziert die Redundanz und damit die Gesamtdatenmenge. "Information" ist in der Informatik wohl definiert, und Information braucht keine Interpretation. Für die (verlustfreie) Kompression ist irrelevant, welche Bedeutung die Daten und die darin enthaltenen Informationen haben.

Wenn ich jetzt nochmal weiterlese, fällt mir auch noch ein falscher Satz auf:

Bei der verlustfreien Kompression wird die originäre Information I in eine komprimierte Information I' überführt.

Information kann man nicht (verlustfrei) komprimieren. Das muss heißen

Bei der verlustfreien Kompression werden die originären Daten I in komprimierte 
Daten I' überführt, die die ursprüngliche Information vollständig enthalten.

--Mhohner 19:51, 3. Jun. 2008 (CEST)

Ich habe damals die einleitende Definition verfasst und wenn du meinst, dass Information das richtige Wort ist und die Definition bzw der OMA-Abschnitt nun stimmt, werde ich da nicht mit dir streiten. Auch bei mir sind Daten = Information + Redundanz (+ Irrelevanz) von daher kann es meinen sprachlichen Fähigkeiten geschuldet sein, mich hin und wieder missverständlich auszudrücken. Deine Verkürzung des einleitenden Satzes lässt es tatsächlich falsch klingen.

Für den zweiten von dir beanstandeten Satz bin ich aber nicht verantwortlich ;-) -- ThePacker 03:16, 4. Jun. 2008 (CEST)

algorithmen, methoden

kann hier jemand erklären, was der unterschied zwischen einem kompressionsalgorithmus und einer kompressionsmethode ist? der gesamte aufbau der datenkompression ist meiner meinung nach schwer zu verstehen, da mir nicht klar ist, bei welchen dateiformaten ein algorithmus und bei welchen eine methode verwendet wird. da codecs, die zu methoden gehören, wiederum algorithmen sind, ergibt das für mich überhaupt keine sinn mehr!!!

Es gibt keinen Unterschied. Es sind nur zwei verschiedene Worte, die in dem Fall das gleiche bedeuten. --Mhohner 19:44, 29. Mai 2008 (CEST)

Das kann nicht sein. zum beispiel ist GIF ein dateiformat, das den LZW-Algorithmus verwendet und daher selbst KEIN algorithmus!!

Oben ging es um "Algorithmus" vs. "Methode" (siehe Überschrift!). "Dateiformat" ist was anderes. --Mhohner 01:08, 30. Mai 2008 (CEST)

Warum stehen dann Dateiformate unter Methoden?

Du meinst wohl den Abschnitt Datenkompression#Bekannte Methoden. Ja, die Überschrift ist ziemlich unglücklich, und auch der Inhalt ist verbesserungswürdig. P.S.: Bitte unterschreibe deine Beiträge. --Mhohner 13:38, 30. Mai 2008 (CEST)

Vermeidung von Datenaufkommen

Ist das schon eine Datenkompression? Ich meine unglücklich formuliert.-- Kölscher Pitter 11:45, 3. Jun. 2008 (CEST)

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)

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)

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)

Vorschlag zur Neugliederung des Artikels

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)

Kontinuierlichkeit von Kompression /Speicherbedarf ?

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)

Verlustfreie Komprimierung bijektiv?

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)

Einleitung ändern

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)

„[…] oder um die Übertragungsgeschwindigkeit zu erhöhen. […]“ 

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)

Link auf Packprogramm

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

Beispielbild für Kompressionsartefakte in Bildern

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

Bekannte Methoden zur Quellcodierung

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

Anderes oder zusätzliches Beispiel für Kompressionsartefakte

Ich finde das s/w-Beispiel nicht so toll. Wie wär's mit dem Bild rechts? --Leyo 15:10, 14. Jul. 2011 (CEST)

Quellencodierung in der Nachrichtentechnik

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)

Lamberg 1770

[.... „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)