Diskussion:Portable Network Graphics

PNG in der Wikipedia

Sollten in wikipedia nur PNG Bilder verwendet werden?

Hauptsächlich sollten PNG und JPEG (Wikipedia:Bilder) verwendet werden, jeweils das geeignetere Format. Ich denke, dass für Fotos JPEG besser geeignet ist, ansonsten natürlich PNG. kronn 23:36, 3. Aug 2003 (CEST)

"Die Kompressionsraten verlustbehafteter Algorithmen, wie sie unter anderem bei JPEG verwendet werden, erreicht der verlustfreie Algorithmus von PNG naturgemäß nicht." Dieser Satz klingt so, als ob JPEG allgemin besser komprimiert, dabei kommt es doch auf das Bild an. Grob gesagt: Photos -> JPEG, Screenshots -> PNG. Sie sind halt, wie du schon sagtest, für unterschiedliche Bilder geeignet. Sollte man den Satz nicht ändern?

Ich habe die Aussage jetzt relativiert. --Phrood 17:48, 18. Mär 2005 (CET)

Vorsicht: Hier sollte man nicht die verlustbehaftete Kompression in JPG mit der verlustfreien in PNG verwechseln. Einfach erklärt lässt JPG Details im Bild einfach weg. Das kann das menschliche Auge oft kaum mehr wahrnehmen, aber trotzdem leidet die Qualität des Bildes, je höher man komprimiert umso stärker. Bei PNG ist das anders: Hier wird versucht über bestimmte Verfahren das Bild geschickter abzuspeichern. Man speichert nicht mehr jeden Bildpunkt einzeln, sondern fast bestimmte Bereiche zusammen. Die Qualität des Bildes wird nicht beeinflusst. Dies funktioniert besonders bei Pixelgrafiken wie Diagrammen gut, da dort viele zusammenhängende einfarbige Flächen enthalten sind. Bei Fotos sollte man wegen der zahllosen Details eher JPG einsetzen. Dadurch entstehen gewisse Verluste, die aber bei bestimmten Kompressionsraten zu verkraften sind. PNG würde die Dateigröße von Fotos stark erhöhen -- und das bei nur unwesentlichem Qualitätsgewinn. Stern !? 23:35, 19. Mai 2005 (CEST)

Wenn du damit meinst, dass PNG nur mit verlustfreien Formaten verglichen werden sollte, gebe ich dir Recht. Die geringere Performance im Gegensatz zu JPG ist kein echter Nachteil, ich habe daher den Punkt entfernt. Phrood 12:07, 20. Mai 2005 (CEST)

Natürlich ist es ein echter Nachteil - immerhin komprimiert JPG oft viel besser. Man hat sich nun mal für einen verlustlosen Algorithmus entschieden und alle Vor- und Nachteile des Formats basieren auf solchen Entscheidungen. Es spricht überhaupt nichts dagegen, den Unterschied zu dokumentieren. Tatsächlich ist es meiner Erfahrung nach eine der häufigsten Fragen von Anfängern, warum JPG soviel besser komprimiert als PNG oder TIFF etc. Der von Dir gelöschte Abschnitt beantwortet das sehr gut, deswegen habe ich ihn wieder eingefügt. Wegen mir kann man das auch innerhalb des Artikels verschieben, aber es ist eine wichtige Information. Überhaupt ist diese Aufteilung Vor- und Nachteile mMn nicht so gelungen, aber das kann man vielleicht später mal ändern.--Harmonica 20:00, 20. Mai 2005 (CEST)

Nein, es ist Fehleinschätzung, daß JPG generell besser komprimiert (bezogen auf Bildqualität). Wenn du z.B. einen Screenshot mit JPG in hoher Qualität komprimierst (so daß die Quantisierungsfehler nicht störend sind), ist ein JPG oft 10mal größer als ein PNG, das sogar in höherer (da fehlerfreier) Qualität vorliegt. Die besseren Komprimierungsraten von JPG beziehen sich nur auf Bilder ohne scharfe Diskontinuitäten. JPG und PNG haben völlig verschiedene Anwendungsbereiche, so daß man Äpfel und Birnen vergleichen würde. Phrood 21:18, 20. Mai 2005 (CEST)

Mir ist das alles bekannt. Nur gilt für viele Leute nun mal Bild gleich Foto. Zu beschreiben, wieviel kleiner so ein Foto mit JPG im Vergleich zu PNG wird wäre z. B. absolut legitim und auch für den Leser sinnvoll. Die genauen Unterschiede aufzuschlüsseln würde in einem PNG-Artikel aber vermutlich zu weit führen - andrerseits, warum nicht, wenn schon die Vorfilterung fast so detailliert wie in den Specs drinsteht. Aber wenn man im Artikel Vor- und Nachteile (zu wem eigentlich?) abgrenzen will, dann auch die Kompressionsleistung. Das fällt bei ausführlicher Besprechung dann weder unter Vor- noch unter Nachteil, ist aber insgesamt einer der wichtigeren Punkte bei der Erklärung des Formats. Wer mag, kann unter Vorteile die bessere Leistung in Sachen Kompressionsrate im Vergleich zu GIF aufführen, oder was immer sonst noch. Persönlich fände ich einen Unterpunkt Kompressionsleistung gut, und außerdem ähnliche Punkte für die anderen Eigenschaften des Formats, die dann den Abschnitt Vor- und Nachteile nach und nach ersetzen. Ich hatte bei diesem Artikel dann und wann den Eindruck, dass er von PNG-Fans verfasst wurde, die ständig die Überlegenheit dieses freien Formats gegenüber GIF herausstreichen wollen, weswegen auch die zahlreichen Vergleiche ihren Weg in den Artikel gefunden haben. Die sind nicht grundsätzlich falsch, aber eine saubere Beschreibung finde ich in einer Enzyklopädie sinnvoller als die Definition über den Vergleich mit anderen Formaten. Das ist mittlerweile nicht mehr so akut, aber immer noch spürbar. Ich wollte den Artikel immer mal ändern, stehe aber seiner Größe etwas hilflos gegenüber. Dann sind da noch die mMn viel zu detaillierten Teile, bei denen ich mich aber nicht traue, sie ersatzlos zu streichen.--Harmonica 23:56, 20. Mai 2005 (CEST)

Ich stimme dir im Großen und Ganzen zu. Ich habe mich ja auch schon dafür ausgesprochen, den detaillierten Abschnitt zu entfernen. Was die JPG-Geschichte angeht, so hat eine derartige Beschreibung in diesem Artikel aber nichts verloren. Konsequenterweise müßte man das ja dann auch bei allen anderen Grafikformaten tun. Da sollte man eher einen Abschnitt im Artikel Bildkompression einfügen und auf diesen verweisen. Phrood 00:04, 21. Mai 2005 (CEST)

Vergleich zu anderen Bildformaten

Ich finde den neu eingefügten Vergleich zu anderen Bildformaten in der Form sinnlos. Ohne die Art des Bildes zu erwähnen und verschiedene Bildtypen (Fotos, gescannte Texte, Liniengrafik, Logos mit wenigen Farben) zu vergleichen (anstatt nur ein einziges), ist die Aussage gleich Null. Ich kann auch Bilder finden, bei denen die Ergebnisse völlig anders ausfallen, insofern ist die Tabelle beliebig. Bei PSD fehlt zudem die Angabe des Komprimierungstyps.

Darum plädiere ich dafür, die Tabelle zu löschen. Falls niemand was dagegen hat, mache ich das in ein paar Tagen.

Wenn sich jemand die Arbeit machen will, einen ausführlichen Test durchzuführen, würde ich den übrigens in einen eigenen Artikel stecken (Vergleich von Bilddateiformaten mit verlustloser Komprimierung). --Harmonica 22:34, 13. Aug 2004 (CEST)

GIF?

Im Text heißt es "Für viele Zwecke reicht aber das GIF-Format und Mitte 2004 wird auch in Europa dessen Patent auslaufen, so dass dessen Verwendung auch frei sein wird."

Da aber PNG eigentlich immer besser komprimiert als GIF und funktional besser ist, sehe ich keinen Grund statt PNG noch GIF zu verwenden, sieht man von animierten GIFs ab, die jedoch von MNG beherrscht werden. Ich würde die Zeile löschen!

na dann -Sei mutig. --'~' 20:33, 22. Okt 2003 (CEST)

Problem: Fast niemand beherrscht MNG. Und Animationen sind anscheinend nicht totzukriegen. Darüber hinaus wird GIF überall richtig unterstützt, PNG hingegen nicht. Für Pragmatiker bedeutet das, weiterhin GIF zu verwenden. -- Benutzer:Harmonica

Das trifft nur auf PNGs mit Alphakanal oder Farbkorrektur zu, andere PNGs (mit beliebigen Farbtiefen) werden eigentlich überall unterstützt. Das ist immer noch wesentlich mehr, als GIF zuläßt (mit Ausnahme von Animationen). --Phrood 22:50, 3. Aug 2004 (CEST)

Alphakanal oder Farbkorrektur werden aber nicht so oft benötigt bzw. verwendet. Daran daß PNG technisch überlegen ist zweifelt glaube ich keiner. Mir ging es nur um den Grund, warum GIF für manche durchaus noch Bedeutung hat. Es funktioniert überall, stellt sozusagen den kleinsten gemeinsamen Nenner für graphische Browser da, und jetzt ist auch noch das Patentproblem weggefallen. Darüber hinaus sind viele Sitedesigner faul und nehmen gern, was sie immer schon genommen haben. Der erste Eintrag weiter oben klingt so, als müsse man langsam anfangen, GIFs praktische Bedeutung überall herauszustreichen. Das fände ich zwar auch nett, spiegelt aber einfach nicht die Realität wieder. --Harmonica 10:32, 4. Aug 2004 (CEST)

Aussprache

Daß PNG auch "peng" ausgesprochen werden kann, ist falsch. In der Spezifikation heißt es:

Pronunciation - PNG is pronounced "ping".

Die Aussprache ist in der Spezifikation festgelegt (im Gegensatz z.B. zu GIF), also hat sich formell jeder daran zu halten!

Ich habe mit meinem IPA-Halbwissen mal versucht die Aussprache anzugeben. Wer mag, kann die Angabe nochmals überprüfen. Stern !? 02:40, 4. Mär 2005 (CET)

Verlustfreie Komprimierung nicht optimal?

"Auch im Vergleich zu auf bestimmte Klassen von Bilddaten spezialisierten Algorithmen, etwa nur für gescannte Dokumente, kann PNG meist nicht mithalten." - Könnte bitte jemand ein Beispiel für so einen Algorithmus/Dateiformat geben? Soweit ich weiß, ist der PNG-Algorithmus (Filtering+Deflate) nahezu ebensogut wie die esoterischen, noch effizienteren Algorithmen. Sofern niemand etwas dagegen hat, werde ich diesen Punkt löschen. --Phrood 23:18, 3. Aug 2004 (CEST)

Ich hab was dagegen, ich habe den Punkt hinzugefügt. Beispiel ist etwa JBIG-2 für gescannte Textdokumente. Da kann PNG nicht mithalten. Es ist allgemein bekannt, daß Algorithmen besser sind, je mehr sie die Datenklasse einschränken, auf der sie arbeiten. PNG bleibt "Allzweckwaffe" für alle normalen Bilddaten, aber sobald jemand sich Mühe macht, für bestimmte Daten eigene Algorithmen zu entwickeln, wird PNG verlieren, weil es nicht soviele Annahmen über die Eigenschaften der Daten machen kann. --Harmonica 10:26, 4. Aug 2004 (CEST)

Wie weit gehen in der Beschreibung?

Ich bin dafür, keine detaillierte Beschreibung der Filtertypen und der Kompression in den Artikel einzufügen, da es sich um Parameter handelt, auf die Benutzer i.d.R. keinen Einfluß haben und daher eher verwirrend wirken. Eine gute Beschreibung findet sich ja eh in der Spezifikation. Allenfalls könnte man die Komprimierungstechnik angeben (gzip mit Vorfilterung der Bilddaten). --Phrood 16:23, 6. Nov 2004 (CET)

Dann hast du ein schlechtes PNG-Programm. Ich kann bei den Programmen, die ich verwende, sehr wohl Kompressionsstärke und ggf. auch den Filtertyp angeben und ich möchte das auch, da die automatische Wahl des Filtertyps bisweilen fehlschlägt und ich mit dem manuellen Setzen des Filtertyps so eine stärkere Komprimierung erreichen kann. Außerdem zeigen die Filtertypen, wieso PNG z.B. besser komprimiert, als wenn man einfach ein unkomprimiertes Bitmap mit (g)zip komprimiert. Gerade das ist ja die Stärke von PNG! --RokerHRO 15:51, 8. Nov 2004 (CET)

Ich kann nicht ganz nachvollziehen, was du meinst. IMHO sollte ein besseres Programm den Filtertyp (oder besser gesagt die Filtertypen, da sie in jeder Bildzeile (!) unterschiedlich sein können) automatisch setzen, und zwar so, daß die Komprimierung maximiert wird. Und sollte man doch manuell einstellen müssen, bietet der Paeth-Filter meistens die besten Ergebnisse. Aber das sollte normal nicht sein, da eine automatische Auswahl vom Programm sehr wohl möglich ist und das Ergebnis dann in jedem Fall besser ausfällt als ein Filter für alle Bildzeilen. (Viel Spaß im manuellen Tunen - du hast 5^Y Möglichkeiten!)

Zum Artikel: eine kurze Erwähnung des Filterns ist sicher angebracht, aber so weit würde ich nicht gehen, die einzelnen Filtertypen aufzulisten.

Vorschlag: Die i.d.R. höhere Komprimierungsrate von PNG beruht zum großen Teil auf einer umkehrbaren Transformation (Filtern genannt) der Bilddaten vor der eigentlichen Komprimierung mittels des gzip-Algorithmus. Beim Filtern kann einer von fünf verschiedenen Filtertypen auf jede Bildzeile unabhängig angewandt werden. Dies wird meist vom zu speichernden Programm erledigt, bei manueller Einstellung bietet der auf das gesamte Bild angewandte Paeth-Filter oft nahezu optimale Ergebnisse. --Phrood 20:50, 8. Nov 2004 (CET)

Standardisierung, Weiterentwicklung

Im Text steht, PNG habe sich "kaum weiterentwickelt". Klingt das nur für mich negativ?

Abgesehen davon ist es sachlich falsch. Dezember 1994 war der Auslöser, und dann wurde intensiv diskutiert und entwickelt. Vom ersten Draft Januar 1995, als es noch PBF hieß, bis zu der Standardisierung durch IETF, IANA und W3C Ende 1996 / Anfang 1997.

Nach der Standardisierung kann man nicht so einfach "weiterentwickeln"; da müßte man schon entweder mit dem Standard brechen, oder innerhalb der Standardisierungsgremien die Veränderungen mit unterbringen. Auch wenn die W3C und IETF flexibler sind als die ISO - ändert man das Format laufend, hat das viele Nachteile.

Abgesehen davon war PNG bei Standardisierung der 1.0 Spec auch fertiggestellt. Basteleien waren und sind nicht mehr notwendig. Es sind Erweiterungsmöglichkeiten vorgesehen, die auch genutzt werden, aber die jeweilige Nutzung der Erweiterungen gehört eben nicht in den Standard.

Ich möchte den Satz "Seit der ersten Spezifikation hat sich das PNG-Format kaum weiterentwickelt." ersetzen durch "Seit der Version 1.0 wurde das PNG-Format von verschiedenen Seiten standardisiert."

Einsprüche?

Es ist vielleicht eine kurze Anmerkung wert, dass man nicht mehr großartig dran rumschrauben will und dass das eine gute Idee ist, und warum. Ich habe auch schon von einiger Zeit hinter den Satz Es ist aber absichtlich Raum für Erweiterungen gelassen worden, um in zukünftigen PNG-Versionen auch andere, effizientere oder schnellere Algorithmen zu unterstützen. eine Einschränkung eingefügt. So wie ich es mitbekommen habe, haben die ursprünglichen PNG-Autoren keine Absicht, je andere Verfahren zu nutzen, um nicht die Akzeptanz des Formats durch nicht lesbare Dateien in älteren Programmen zu gefährden, andrerseits ist es theoretisch möglich. Kleinere Änderungen wie ein zusätzlicher Chunk für irgendwas sind natürlich drin.--Harmonica 07:57, 8. Feb 2005 (CET)

Transparenz

Kennt sich jemand genauer mit der Transparenz von PNGs aus? Es gibt ja viele Browser/Viewer, die können PNGs anzeigen, aber keine transparenten PNGs. Diese zeigen in den transparenten Bereichen dann eine opake Farbe an, z.B. grau oder schwarz. Kann man diese Transparenz-Ersatzfarbe im PNG beeinflussen? Konkretes Problem ist das neue Wikinews-Logo, zu sehen auf [1]. Mein IE 5.0 zeigt den Hintergrund des Logos grau an und weiß würde viel besser aussehen. --195.33.105.17 16:26, 17. Feb 2005 (CET)

Der IE ist bis heute nicht in der Lage, den Alpha-Kanal (der beliebige "Durchsichtigkeits-Level" gestattet) eines PNG-Bildes korrekt auszuwerten. Er kann nur eine Transparenz-Farbe (also ein spezieller RGB-Wert, der im PNG-Header als "bitte werte diesen RGB-Wert als transparent" definiert wurde) korrekt darstellen. Da Microsoft diesen Bug nun schon seit Jahren im IE nicht gefixt hat, ist das ein Grund mehr, von diesem Browser die Finger zu lassen. ;-( --RokerHRO 16:58, 17. Feb 2005 (CET)

Die Datei /media/wikinews/de/b/bc/Wiki.png scheint einen vollen Alphakanal zu haben, also insbesondere keinen einzelnen Pixelwert, der als transparent gilt (was auch bei PNG möglich ist, aber nicht beim vollen Alphakanal - da ist diese Information schlichtweg überflüssig, da sie bereits im Alphakanal steckt). Der IE-Bug ist bei dieser Datei also irrelevant. Diejenigen Pixel, die im Alphakanal der Datei als transparent markiert sind, haben im Bildkanal die Farbe grau. Dort müßte man sie auf weiß umsetzen.--Harmonica 16:51, 18. Feb 2005 (CET)

Die Frage ist wohl nicht nach der Transparenz von PNGs, sondern nach den Bugs eines bestimmten Browsers.

Links auf Workarounds für den Bug des IE stehen unter den Weblinks.

1-Bit-Transparenz (ähnlich GIFs) kann auch (sogar) der IE korrekt anzeigen.

Die Frage ist aber, ob man für den Fehler eines Browsers Workarounds baut, oder ob der Hersteller nicht eher den Fehler beheben sollte! --Jwilkes 15:46, 20. Feb 2005 (CET)

Ich frage mich ohnehin, warum sich die Hälfte der Weblinks mit IE-Bugs beschäftigt. Das gehört hier eigentlich nicht rein. (Diesen Kommentar hatte ich schon mal geschrieben, scheint aber nicht angekommen zu sein?!)--Harmonica 20:01, 20. Feb 2005 (CET)

Wenn man einige Punkte beherzigt, kann man mit PNG auch im IE normale Transparenz erzeugen, so wie GIF sie erzeugt. Dann tritt auch keine graue Fläche auf. Hierzu muss die Anzahl der Farben des Bildes auf 256 begrenzt werden und der Alphakanal sollte nur einen einzigen Transparenzton verwende. Wenn ich jetzt nichts übersehen habe, funktioniert es dann auch im IE. Das gilt dann natürlich nur für die einfache Transparenz, die auch GIF beherrscht. Man kann also ohne Angst auf GIF verzichten und die volle GIF-Funktionalität auch mit PNG nachbilden und dabei sogar Speicherplatz sparen. Alphaschatten sind im IE generell noch nicht möglich. Da treten die hässlichen grauen Flächen auf. Handhabungen gibt es nur mit CSS-Gepfusche. Angeblich soll ein voller Alphakanal aber ab der neuen IE-Version, die vermutlich im Sommer erscheinen wird, möglich sein. Warten wir und hoffen wir! Stern !? 23:28, 19. Mai 2005 (CEST)

Das Beschränken auf 256 Farben ist nicht notwendig. – 84.130.22.193 18:11, 14. Mai 2006 (CEST)

Technische Details

Im Abschnitt technische Details wird beschrieben, wie sich durch eine Vorverarbeitung der Bilder der Kompressionsfaktor erhöhen lässt. Dies wird im Artikel als Vorfilterung bezeichnet. Diese Bezeichnung ist aber etwas unglücklich gewählt, denn beschrieben wird eine prädiktive Kodierung.

Bei einer prädiktiven Kodierung wird mit einem definierten Algorithmus aus vorangegangenen Codesymbolen (in diesem Fall Pixeln) eine Vorhersage für das nächste zu codierende Symbol getroffen. Codiert wird dann statt dem eigentlichen Symbol die Differenz zwischen Vorhersagewert und dem tatsächlichem Wert des Symbols. Da benachbarte Pixel oft einen ähnlichen Farbwert besitzen, lässt sich der Farbwert des Pixels recht gut vorhersagen, und diese Differenz ist meist sehr klein. Durch den Prädiktor wird dadurch eine Symbolfolge generiert, in der Symbole mit kleinen absoluten Beträgen sehr häufig sind (in allen glatten, unstrukturierten Bildbereichen) und Symbole mit großen Beträgen nur selten auftauchen (z.B. an Objektkanten). Je stärker die Auftretenswahrscheinlichkeit der Symbole von der Gleichverteilung abweicht, umso geringer ist die Entropie der Quelle und entsprechend besser lässt sich eine Nachricht mit einem Entropiecoder codieren. Daher stellen die vier möglichen Prädiktionsalgorithmen (up, sub, average, Paeth) beim PNG eine effektive Methode zur Vorverarbeitung typischer Bilder vor der Entropiecodierung dar. Ausnahmen sind aber z.B. stark verrauschte oder geditherte Bilder. Hier wäre der Prädiktionsfehler meist sehr hoch und deshalb ist dann eine direkte Codierung der Bildpunkte besser geeignet (Modus none).

Der Begriff Vorfilter sollte daher besser in Prädiktor geändert werden.

Die PNG-Spezifikation verwendet den Begriff "Filter", daher die Bezeichnung "Vorfilter". Daran ist, denke ich, nichts falsch, denn es handelt sich tatsächlich um einen Filter (im Sinne der Bildbearbeitung). Du kannst aber gerne im Artikel ergänzen, dass es sich dabei genauer gesagt um prädiktive Kodierung handelt. --Phrood 12:37, 5. Nov 2005 (CET)

Sehe ich genauso, Sub, Paeth & Co. sind eben Vorhersagefilter, daran ist nichts unglücklich, nur ist Filter vielleicht nicht der präziseste Begriff. Prädiktor wäre also vielleicht in der Tat besser, allerdings kannte ich den Begriff nicht, und ich kenne mich mit Komprimierung aus. Das mag daran liegen, daß ich fast alles zum Thema auf englisch gelesen habe und mich nur an predictive coding bzw. prediction value erinnern kann. Das muß natürlich nichts heißen. Eine Googlesuche mit Prädiktor Komprimierung und Prädiktor Kompression bringt 290 bzw. 220 Hits, vor allem in Uniskripten. Scheint sich also erst zu etablieren. Jedenfalls sollte der Begriff, wenn er denn übernommen wird, gut eingeführt werden, so daß keine Mißverständnisse beim Leser aufkommen können. Es gibt sogar einen Artikel Prädiktor, der aber (noch) nichts zum Thema Datenkomprimierung aufweist. Lange Rede, kurzer Sinn: Prädiktor bitte nur zusammen mit einer wie auch immer gearteten Definition dieses Begriffes. Filter hat, unpräzise oder nicht, als Alltagsbegriff den Vorteil, auch von technischen Laien verstanden zu werden. Insofern würde es mich nicht schmerzen, wenn es so bleibt, wie's ist.--Harmonica 13:09, 5. Nov 2005 (CET)

Metadaten anzeigen

Was noch fehlt: Die Angabe von Programmen (für Windows und Linux), mit denen man die Metadaten von PNG-Bildern sehen und bearbeiten kann.

Verweis auf TweakPNG eingefügt. --Phrood 22:22, 2. Nov. 2006 (CET)

Filter

Die Filter werden auch bei Palettenbildern eingesetzt. Je nach Bild funktionieren sie dort auch wunderbar. Es gibt auch bei Graustufen- und Echtfarbenbildern Kandidaten, die mit den Filtern nicht besser komprimiert werden. Darum ist der Filter auch optional bzw. die Möglichkeit vorhanden, für jede Zeile einen eigenen Filter inkl. "keinen Filter" einzusetzen. Deswegen Revert. Was das Ersetzung von Komprimierung durch Kompression angeht - werden die Begriffe nicht synonym verwendet?--Harmonica 02:46, 7. Jan 2006 (CET)

Verlustfrei oder nicht?

Auf WP:Grafiktipps ist die Rede von einer "weitgehend verlustfreien" Kompression, während hier im Artikel von "verlustfrei" die Rede ist. Was stimmt denn nun? --217.237.150.107 17:52, 29. Jun 2006 (CEST)

"verlustfrei" ist richtig, korrigiert. --Phrood 17:54, 29. Jun 2006 (CEST)

Einleitung

Ist GIF Proprietär? Nach der Lektüre des 2. Punkte des Artikels Proprietär sind mir Zweifel gekommen ob die Aussage in der Einleitung dieses Textes stimmt. Dort steht:

Protokolle, Dateiformate und ähnliches werden als „proprietär“ bezeichnet, wenn sie nicht mit freier Software implementierbar sind, weil sie z.B. lizenzrechtlich oder durch Patente beschränkt sind. Beispiele für proprietäre Dateiformate sind das MS-Word-Format oder das WMA-Format. Beispiele für nicht proprietäre, offene Formate sind Ogg Vorbis, das Portable-Network-Graphics-Format oder das HTML-Format.

Implementirbar heißt doch eingebaut, oder? Der Freie Browser Firefox kann aber GIF darstellen, danach könnte GIF also nicht Proprietär sein?--Uwe W. 18:42, 17. Mär. 2007 (CET)

Scheint mir auch so, mittlerweile ist die GIF-Spezifikation frei im Internet verfügbar. Ich würde das Wort "proprietär" streichen. --Phrood 19:01, 17. Mär. 2007 (CET)

Geändert--Uwe W. 19:16, 17. Mär. 2007 (CET)

Bei GIF war der LZW-Komprimierungsalgorithmus mit Patenten belegt. Das Dekodieren war durch die Patente nicht betroffen. Somit war es durchaus möglich, GIF-Dateien zu lesen, nur das erzeugen war nicht möglich. Es gab allerdings einen Trick, indem man Datenströme erzeugte, die von einem GIF-Dekoder gelesen werden konnte, daber aber nicht komprimiert waren, so genannte "unkomprimierte" GIF-Dateien. --RokerHRO 22:01, 17. Mär. 2007 (CET)