Diskussion:Portable Network Graphics/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:Portable Network Graphics/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

Unterstützung eingebetteter Farbprofile

Firefox 3 unterstützt eingebettete Farbprofile, man kann die Funktion aktivieren indem man im Browserfenster "about:config" eingibt und die Variable "gfx.color_management.enabled" auf "true" setzt. (nicht signierter Beitrag von 77.184.224.220 (Diskussion) 00:52, 6. Aug 2008 (CEST))

Das verändert jedoch die generelle Farbwidergabe des Browsers und ist daher meiner Ehrfahrung nach nicht zu empfehlen. -- ThorJH 22:38, 7. Aug. 2008 (CEST)

PNG in der Wikipedia

Sollten in wikipedia nur PNG Bilder verwendet werden? (nicht signierter Beitrag von Nerd (Diskussion | Beiträge) 19:01, 30. Nov. 2002 (CET))

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? (nicht signierter Beitrag von 212.202.27.133 (Diskussion | Beiträge) 14:35, 18. Mär. 2005 (CET))

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)

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! (nicht signierter Beitrag von 82.82.118.178 (Diskussion | Beiträge) 18:58, 22. Okt. 2003 (CET))

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 (falsch signierter Beitrag von Harmonica (Diskussion | Beiträge) 09:25, 3. Aug. 2004 (CET))

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". (nicht signierter Beitrag von Phrood (Diskussion | Beiträge) 20:01, 14. Mär. 2004 (CET))

Die Aussprache ist in der Spezifikation festgelegt (im Gegensatz z.B. zu GIF), also hat sich formell jeder daran zu halten! (nicht signierter Beitrag von Phrood (Diskussion | Beiträge) 23:06, 17. Apr. 2004 (CET))

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)

Hm, ich habe mal irgendwo gelesen, dass man das in anderen Sprachen als Englisch auch anders (etwa „Peh Enn Geh“) aussprechen „darf“. Ich dachte eigentlich, das wäre in einem halbwegs offiziellen Dokument gewesen, aber finden werde ich es wohl nicht mehr. In der Spezifikation steht jedenfalls nur „ping“. – 91.4.41.176 11:53, 20. Mai 2007 (CEST)

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)

Wäre gut, wenn man da mal ungefähr das Einsparpotential angibt. Ich hatte mal irgendwas „buntes“, ich glaube, es war ein Scan der Oberseite einer CD, das mit JPEG2000 (verlustfrei) kleiner war, aber der Unterschied war nicht sehr groß. – 91.4.41.176 11:57, 20. Mai 2007 (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!)

PNGOUT (das eine ziemlich gute Kompression erreicht) benutzt, wenn nicht anders angegeben, bei RGB-Bildern „Mixed“ (also wohl für jede Zeile den optimalen) und bei Palettenbildern keinen Filter. Das liefert meist recht gute Ergebnisse, manchmal lässt sich das Ergebnis aber auch noch durch Wahl eines anderen Filters verbessern. Ja, manuelle Wahl oder die Brute-Force-Methode kann sich da mitunter lohnen, je nach Einsatzzweck halt, für mobile Geräte mit wenig Speicher oder auch für das Web bietet sich das mitunter an. Wobei ich auch Dateien auf meiner Festplatte gerne optimiere. – 91.4.55.137 12:06, 20. Mai 2007 (CEST)

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? (nicht signierter Beitrag von Jwilkes (Diskussion | Beiträge) 21:40, 7. Feb. 2005 (CET))

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 http://upload.wikimedia.org/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)

Ich würde vorschlagen folgende Links hinzuzufügen, um die Problematik bei der Verwendung von PNGs zu untermauern. Eventuell auch als Quellennachweis.

• Liste von verschiedensten PNG Tests
• PNG transparency test von Jason Summers. Die wahrscheinlich anschaulichste Seite, die Probleme mit Alphatransparenzen in verschiedenen Browsern beschreibt.

--82.212.55.254 18:01, 1. Okt. 2007 (CEST)

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. (nicht signierter Beitrag von 84.184.44.214 (Diskussion | Beiträge) 12:18, 5. Nov. 2005 (CET))

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. (nicht signierter Beitrag von 194.95.59.130 (Diskussion | Beiträge) 19:11, 2. Nov. 2006 (CET))

Verweis auf TweakPNG eingefügt. --Phrood 22:22, 2. Nov. 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. Punktes 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)

Fireworks-PNG

Hallo

Meiner Meinung nach fehlt hier noch ein Hinweis, dass die Software Macromedia Firework ebenfalls png-Dateien benutzt, allerdings als eigenes Datenformat vergleichbar mit dem PDS von Photoshop. (nicht signierter Beitrag von 193.247.250.1 (Diskussion | Beiträge) 10:45, 5. Mai 2007 (CET))

Richtig, ich habe dazu etwas ergänzt. --Phrood 12:14, 5. Mai 2007 (CEST)

Nachteile

"# ermöglicht nicht das einfache Laden von Bildteilen. Wer nur einen Ausschnitt des Bildes laden möchte, muss alle Bildzeilen davor mitladen. Im Falle von PNG-Dateien, die nicht sequentiell, sondern interlaced gespeichert wurden, muss sogar noch mehr geladen werden."

- Das ist kein Nachteil, das ist bei fast allen Bildformaten so.

"# erreicht bei bestimmten Bildarten wie Fotos naturgemäß nicht die Kompressionsraten verlustbehafteter Algorithmen wie etwa JPEG. Auch im Vergleich zu auf bestimmte Klassen von Bilddaten spezialisierten Algorithmen, etwa nur für gescannte Dokumente (z. B. JBIG2), kann PNG meist nicht mithalten."

- Das ist auch kein Nachteil, das eine Gegenbenheit der Komprimierungstechnik und völlig trivial.

(nicht signierter Beitrag von 85.178.69.181 (Diskussion | Beiträge) 00:33, 29. Aug. 2007 (CET))

Stimme zu, die Punkte könnten entfernt werden --Phrood 22:47, 8. Sep. 2007 (CEST)

Moderne Browser - Arachne?

Ich möchte ja nicht unhöflich sein, aber ich habe von diesem Browser noch nie etwas gehört und würde eine DOS-Software kaum als state-of-the-art bezeichnen. Stattdessen sollte eher auf Opera und Safari verwiesen werden. Wobei ein direkter Verweis auf die verwendeten Layout-Engines wohl noch treffender wäre. Diese wären dann also Gecko für die Mozilla-Browser, WebKit/KHTML für Safari/Konquerer, Presto für Opera und die Layout-Engine des Internet Explorer. (nicht signierter Beitrag von 88.76.33.70 (Diskussion | Beiträge) 17:09, 22. Okt. 2007 (CEST))

Ich habe die Liste der Browser mit Arachne ganz entfernt, zumal ja weiter unten auf die Schwächen der einzelnen Browser näher eingegangen wird. --Phrood 18:40, 22. Okt. 2007 (CEST)

"modern" raus (kann insbesondere von IE wohl kaum behauptet werden), "Arachne" rein. (nicht signierter Beitrag von 77.57.92.20 (Diskussion | Beiträge) 18:44, 27. Dez. 2007 (CET))

Magic number

Was hat es mit dem Byte 89_hex im Dateikopf aufsich? Gibts dafür eine Erklärung? Es ist weder in Codepage 437 noch in Windows' Codepage 1252, noch in den Steuerzeichen der ISO-8859-Zeichensätze irgendetwas "Sinnvolles". :-/ --RokerHRO 13:01, 12. Feb. 2008 (CET)

Eben! Durch den Nicht-ASCII-Wert soll verhindert werden, dass PNG-Dateien irrtümlich als Textdateien erkannt werden. Siehe [2] --Phrood 21:22, 12. Feb. 2008 (CET)

Großartig! Danke. Das sollte doch unbedingt in den Artikel aufgenommen werden, meinst du nicht? :-) --RokerHRO 21:39, 12. Feb. 2008 (CET)

Ich weiß nicht. Der Abschnitt "Dateikopf" und die Vorfilter-Tabelle stechen eigentlich schon jetzt in ihrer Detailtiefe gegenüber dem restlichen Artikel hinaus. Man könnte zwar weitere technische Einzelheiten einfügen, aber wozu? Der Artikel würde dadurch detailverliebt und unausgewogen, und die leicht verständliche und hervorragend aufgebaute PNG-Spezifikation enthält schon alles. --Phrood 22:46, 12. Feb. 2008 (CET)

Vorteile

"# ermöglicht das Abspeichern zusätzlicher Information in der Grafikdatei, zum Beispiel Autoren- und Urheberhinweise.

- Hierzu möchte ich anregen, diesen Passus entweder ganz rauszunehmen oder - der Realität entsprechend - angemessen zu relativieren. Das PNG-Format erlaubt zwar das Einbringen beispielsweise eines Autoren- und/oder Urhebervermerk via des tEXtChunks, aber welche Praxisrelevanz soll sich daraus ergeben? Der "normale" Anwender, der gängige freie/kostenlose oder kommerzielle Fotosoftware nutzt, kann damit nichts anfangen. Der als [Comment] eingebundene tEXt-Chunk kann lediglich von einer Handvoll "Spezial"-Tools ausgelesen werden. Daher sollte meiner Meinung nach entweder dieser für sich selbst schon "schwache" oder gar fragwürdige Vorteil raus, oder die Passage sollte korrigiert werden. Beispielsweise in der Art: "ermöglicht mit speziellen PNG-Tools wie beispielsweise TweakPNG das Abspeichern von zusätzlichen Kommentaren in Textform als tEXt-Chunk (nicht Exif/IPTC konform!)

So wie es jetzt formuliert ist, führt dieser Passus leicht zu Verwirrung - zumindest beim unbedarften Leser. Wer auf der Suche nach einem verlustfreien Bildformat ist, aber bestimmte, von seiner üblichen Fotosoftware lesbare Informationen in ein PNG einbetten will, scheitert. Verschärft wird dieser Umstand, da beispielsweise PS i.V. mit IR das Abspeichern von eigenen Metadaten zulässt, diese aber dann nicht wirklich "eingebettet" werden. Mir ging das genauso :/. Ich suchte einen Ersatz für JPEG und landete kurzerhand bei PNG. Kurz hier in der Wiki recherchiert, gelesen "ach unterstützt Copyright- und Urhebervermerk", passt, Konvertieren angefangen und danch recht dumm geguckt. Ich nehme an, ich habe beim "Überfliegen" des Passus sofort eine EXIF-/IPTC-Konformität angenommen, da heute ohne diese Informationen ehedem nichts "geht". Zumindest dann, wenn man derlei Zusatzinformationen einfach in den Fotodateien braucht. Speziell die Formulierung "Autoren- und Urheberhinweise" würde ich daher streichen, da dies meist im (semi-)professionellen Bereich benutzt oder benötigt wird und diese Infos ohne EXIF-/IPTC-Konformität heute wertlos sind. -- Syug 08:00, 28. Mär. 2008 (CET)

OK, entfernt. Unter "Nachteile" steht aber bereits "unterstützt zwar eingebettete Metainformationen, die aber weder dem Exif- noch dem IPTC-Standard entsprechen." --Phrood 19:55, 28. Mär. 2008 (CET)

Magic Number in der Infobox

Hallo zusammen, ich bin darauf angesprochen worden, dass die von mir gewählte Textdarstellung der Magic Number nicht richtig ist. Dem stimme ich zu, allerdings möchte ich hier darüber diskutieren wie Magic Number am besten dargestellt werden sollte:
(folgendes ist von meiner Diskussionsseite hierher verschoben)
[...] Ich ersetze also das ‰-Zeichen durch ein "." und lasse die Codepage einfach weg.
Allgemein habe ich mir ein paar Gedanken über die Darstellbarkeit der Magicnumber gemacht. Die erste Idee, die ich auch umgesetzt habe, bei der String-Darstellung einfach alle nicht druckbare Zeichen durch ein "." zu ersetzen, so wie dies in Übersicht von Gary Kessler geschieht. Aber wirklich glücklich bin ich mit dieser Darstellung nicht, zumal es Verwechslungen geben kann wenn tatsächlich ein Punkt (0x2E) in der Magicnumber vorkommen sollte. Man erkennt zwar an der Hexadezimal Darstellung genau um welches Zeichen es sich handelt, aber verwirrend ist es trotzdem. Eine andere mögliche Darstellung wäre die ASCII C Notation, wie sie im RFC 2083 verwendet wird. Was haltet ihr davon? Schön wäre es noch natürlich wenn als magic codep ASCII C Notation o.ä. angegeben und verlinkt würde, mögliche Lösung wäre eine Weiterleitung auf einen noch zu erstellenden Abschnitt im Artikel ASCII oder C (Programmiersprache) (bsp. en:C syntax#Backslash escapes). [...] Meph666 ^{→ post} 11:43, 3. Apr. 2008 (CEST)

Wenn man die ASCII C Notation verwenden würde dann sähe der String so aus:
"\x89PNG\r\n\x1a\n"
was auf jeden Fall aussagekräftiger ist als das derzeitige ".PNG...." -- Meph666 ^{→ post} 11:57, 3. Apr. 2008 (CEST)

Als Programmierer habe ich nichts gegen diese ASCII-C-Notation. Ob sie von Nichtprogrammierern auch verstanden wird, kann ich nicht beurteilen. Vielleicht wäre dann ein Hinweis auf ASCII-C-Notation oder so sinnvoll. --RokerHRO 12:20, 3. Apr. 2008 (CEST)

Zumal man auch bedenken sollte, dass es hauptsächlich die Programmierer sind, die sich für diese Infos interessieren. -- Meph666 ^{→ post} 12:49, 3. Apr. 2008 (CEST)

Diese Annahme teile ich mal. Make it so! :-) --RokerHRO 13:17, 3. Apr. 2008 (CEST)

besser mit (\x89 P N G \r \n \x1a \n) oder ohne (\x89PNG\r\n\x1a\n) Leerzeichen? Ich wäre eher für ohne. -- Meph666 ^{→ post} 13:29, 3. Apr. 2008 (CEST)

Erledigt, hab außerdem zwei Weiterleitungen angelegt ASCII-C-Notation, ASCII C Notation (engl. Schreibw), beide zeigen auf Escape-Sequenz#Escape-Sequenzen in C und verwandten Programmiersprachen Viele Grüße -- Meph666 ^{→ post} 14:20, 3. Apr. 2008 (CEST)

256 Farben

Im Artikel heisst es "PNG kann wie GIF Pixel aus einer Farbpalette mit bis zu 256 Einträgen verarbeiten." Dies würde eine Limitierung auf 256 Farbtöne bedeuten und keine verlustfreie Kompression von Fotos ermöglichen. Ich dachte immer PNG kann hier mehr Farben? --Gunter Schmidt 13:42, 16. Aug. 2008 (CEST)

Ja, aber bei mehr Farben dann nicht mehr über eine Farbpalette sondern nur noch über DirectColor. --RokerHRO 15:38, 16. Aug. 2008 (CEST)

PNG-Grafik (Animiert, xx Frames)

PNG ist seit einiger Zeit schon Animationsfähig ... ich habe mal mit Javascript eine animierte Datei überprüft und zwar die hier (http://www.treebuilder.de/apng/result/img/3d2.png) ihr Upload datum fand am (Mittwoch, 29. August 2007 17:35:37) stat(sie wurde da das letzte mal verändert). und ich habe mich auch selber darüber gewundert aber ihr könnt euch wahrscheinlich vorstellen das es möglicherweise das Format schon immer unterstütz hatte nur das es kaum jemand gewusst hatte. http://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png -Nizu Kazushi 23:22, 15. Nov. 2008 (CET)

PNG ist nicht animationsfähig. Bei APNG handelt es sich um eine Erweiterung durch Chunks, die nicht von der PNG-Entwicklergrupp registriert wurde, da sie dem Grundgedanken von PNG zuwiderläuft. --Phrood 00:06, 16. Nov. 2008 (CET)

Ja aber die Datei die du da siehst ist immer noch PNG ^^ und sie ist halt nur durch einen Zusatz im eigenen Quelltext erweitert worden... für mich bedeutet es PNG unterstütz Animationen den unabhängig von der Software hast du die Möglichkeit das bild un animiert zu sehen da es von Anfang an eine PNG Datei wahr.. und die Erweiterung nur hinzuintegriert wurde damit das Format auch Animationen unterstütz ... ich würde es als Entwicklung ansehen. ... und ich frage mich welche Browser heute APNG unterstürzen.

Vor allem wo ist dieses Vielversprechende Multiple-image Network Graphics Format. seit Jahren versprochen und immer noch irgendwo versteckt in einem Tresor? --Nizu Kazushi 02:03, 16. Nov. 2008 (CET)

Es nutzt einfach keiner, das gleiche Schicksal hätte im übrigen fast auch PNG erlebt. Für Animationen setzen heute nahezu alle Webdesigner auf Flash (bzw. Silverirgendwas) diese bieten weitmehr Möglichkeiten als eine starre Bildfolge. (vgl. [3])--Cepheiden 09:34, 16. Nov. 2008 (CET)

Man könnte PNG auch um Zahlen- und Formeldaten erweitern, das macht daraus aber noch kein Tabellenkalkulationsformat. --Phrood 11:11, 16. Nov. 2008 (CET)

Beide Beispielbilder sind PNGs, die von jedem PNG-fähigen Programm als Bild dargestellt werden. Wenn da noch weitere Daten drin sind, ist das toll, PNG ist ja auch ein beliebig erweiterbares Format. Aber diese Zusatzdaten werden nur von Programmen ausgewertet, die diese eben auch verstehen. Da diese nicht zur originalen PNG-Spec gehören, werden sie von den meisten PNG-fähigen Programmen auch nicht ausgewertet werden. Mein Firefox stellt daher bei den Bildchen auch nix animiert dar.

Ich könnte mir ja auch ein sndx-Chunk ausdenken und ein Programm schreiben, das diesen Chunk auswertet und Sound abspielt, während es das PNG-Bild anzeigt. Kann PNG damit Sound? Sicher nicht. --RokerHRO 13:23, 16. Nov. 2008 (CET)

Zu der Frage "Wo ist MNG?": Es ist in jedem Programm, dessen Entwickler es unterstützen wollen. Die Spec ist offengelegt, es existiert eine Referenz-Implementierung als libmng. Es kann also jeder nutzen, der mag. Was meinst du mit "gut versteckt im Tresor"? Dass es die bekannten Browser- und Grafiksoftware-Hersteller nicht unterstützen? Nun, frag das die Entwickler jener Software, nicht uns. --RokerHRO 13:27, 16. Nov. 2008 (CET)

Ich stelle mir nur vor wie groß das Potential währe wen die PNG-Entwicklergrupp sich mit APNG Verbündet hätte... damit währe Gif Verdrängt worden. Ok ich kann verstehen das GIF weniger Ressurcen braucht. aber zur heutigen zeit wird die erforderliche Leistung kein Problem sein. Flash ist auch gut ... dagegen konnte SVG(+Javascript) nicht ankommen aus Geschwindichkeitsgründen. Aber Flash wahr schon immer Kostenpflichtig was mich heute immer noch stört... und ich meinte mit der obrigen Frage Wo MNG stecken geblieben ist? ich meinete damit, MNG Daten gibt es nicht wirklich, ausehr auf der Seite http://www.libmng.com/MNGsuite/prom_1_img.html ich meite damit das sich die PNG corp selbst aus dem renen geschmissen hatte da sich ihr Format(MNG) nicht durchsetzen konnte. auf die Frage warum MNG wen es Flash gibt ist so nicht vergleichbar... man müsste sich fragen Warum Gif wen es auch MNG(oder APNG/PNG) gibt. und warum SWF wen es SVG(+Javascript) gibt.--Nizu Kazushi 23:26, 16. Nov. 2008 (CET)

Deine Meinung nach dem besseren GIF-Ersatz usw. kannst du gerne mit den PNG-Entwicklern ausdiskutieren, oder mit den Mozilla-Entwicklern, die APNG entwickelt haben. Ansonsten sollten wir die Diskussion auf dieser Seite darauf beschränken, wofür sie da ist: zur Verbesserung des zugehörigen Wikipedia-Artikels. ;-) --RokerHRO 23:36, 16. Nov. 2008 (CET)

Animierte PNG

Ich habe png-Dateien, die in OpenOffice-Impress animiert dargestellt werden. In OO-Writer nicht. Firefox 3.5 zeigt sie auch nicht animiert (obwohl er das angeblich schon lange kann). Geeqie leider auch nicht. Kann das jemand erklären? -- Frikki 00:05, 9. Nov. 2009 (CET)

Das Format ist eben kein PNG und wird von vielen Anwendungen nicht unterstützt. Siehe Abschnutt "Eigenschaften" und Artikel Animated Portable Network Graphics. Bzw. irgendwas stimmt mit der Datei nicht. Dies hier ist aber kein Anwenderforum, wenn du eine Grafik für die Wikipedia erstellen willst und Probleme hast, kannst du dich auch an die Wikipedia:Grafikwerkstatt wenden. --Cepheiden 08:14, 9. Nov. 2009 (CET)

Übersetzung von "Portable Network Graphics"

"Portable Network Graphics" wird in der Begrifferklärung mit "Portable Netwerkgraphiken" übersetzt. Ich halte es für einen Fehler "Graphics" als Plural zu übersetzen. "graphics" ist ein Singular mit Pluralform (auch mein Wörterbuch, das "New Oxford American Dictionary" bestätigt dies, es gibt noch weitere Beispiele in der Englischen Sprache (so wie "physics"). Eine bessere Übersetzung wäre "Portables Netzwerkgraphikformat", da dies auch den Sinn des Wortes besser überträgt und durchaus dem englischen Ausdruck gut entspricht. -Sebastian42 21:03, 17. Dez. 2009 (CET)

Außerdem ist es sehr ungewöhnlich ein Format mit dem Plural seiner Einzelobjekte zu bezeichnen, es ist nicht "Texte" sondern "Textformat". Eine andere Übersetzung, die ich für möglich halte (vielleicht sogar besser als der vorige Vorschlag ist "Portable Netzwerkgraphik", da es eher den Gewohnheiten für Formatnamen entspricht zu beschreiben, was das Format speichert als dessen Plural (dies ist gerade an weiteren gebräuchlichen Endungen zu erkennen, wie .txt "Text", .bmp "Bitmap, nicht etwa .txs für "Texts", man spricht auch von einem Image, nicht von Images, wenn man über Imageformate spricht ...). Auch enthält eine PNG-Datei nicht mehrere Graphiken sonder genau eine. -Sebastian42 21:09, 17. Dez. 2009 (CET)

"Portable Netzwerkgraphik" halte ich auch für vernünftig.-- ThorJH ^Disk. 22:02, 17. Dez. 2009 (CET)

Abschnitt „Nachteile“

Der Satz „Unterstützt das CMYK-Farbmodell nicht und ist deshalb nicht als vollständiger TIFF-Ersatz geeignet.“ kann so ohne nähere Begründung nicht stehenbleiben: PNG verwendet das RGB-Modell, in welchem alle möglichen Farben (je nach Tiefenauflösung) darstellbar sind. Wenn nun ein anderes Farbmodell nicht unterstützt wird, sollte dies keine Unzulänglichkeit von PNG sein, weil beide Modelle ineinander konvertierbar sind. Wenn alle Farben des alternativen Modells durch das von PNG benutzte Modell darstellbar sind, liegt also kein „Nachteil“ vor -- kläre mich auf, wer's besser weiß. (nicht signierter Beitrag von 95.117.249.112 (Diskussion | Beiträge) 23:26, 5. Feb. 2010 (CET))

Sind denn die Farbräume RGB und CYMK genau gleich, das heißt 1 zu 1 in einander umrechenbar? (vgl. Datei:CIE_RGB-CMYK-Beleucht.png) --Cepheiden 08:32, 6. Feb. 2010 (CET) P.S. ex gibt ja mehrere RGB-Farbräume, welches nutzt denn PNG überhaupt?

Algemeiner Hinweis: Weder in CYMK noch in RGB sind "alle möglichen" Farben darstellbar.-- ThorJH ^Disk. 09:31, 6. Feb. 2010 (CET)

Richtig, alle Farben sind nur im CIEXYZ-System enthalten. Die Umrechnung zwischen RGB und CMYK ist nicht bijektiv. Beispiel: RGB=(0.5,0.5,0.5) kann sowohl als CMYK=(0,0,0,0.5) als auch als CMYK=(0.5,0.5,0.5,0) aufgefasst werden. Theoretisch gleiche Farbe, aber in der Praxis ein Unterschied, weil ein durch die drei Grundfarben erzeugtes Grau etwas anders aussieht als ein durch schwarze Tinte erzeugtes. --Phrood 11:14, 6. Feb. 2010 (CET)

RGB und CMYK sind nicht deckungsgleich, wie Phrood schon anmerkte. Viele RGB-Farben können aufgrund verschiedener Schwarzdeckung durch mehrere CMYK-Quadrupel abgebildet werden, die rein rechnerisch die gleiche Farbe sind, im praktischen Druck aber verschieden aussehen. Falls man Grafiken für den Offsetdruck aufbereiten will, muss man außerdem Überdrucken können, das geht mit CMYK-Daten, die automatisiert aus RGB-Daten generiert worden sind, nur unzureichend. --RokerHRO 17:38, 6. Feb. 2010 (CET)

Kompressionsstufen

Bei vielen Bildprogrammen kann man hier zwischen 0 und 6 wählen. Leider wurde das im Artikel nicht behandelt.... (nicht signierter Beitrag von 89.196.12.179 (Diskussion) 09:16, 5. Mär. 2011 (CET))

Welche Programme sollen das sein? Gimp kennt Stufen von 0 bis 9, und ImageMagick auch (wobei letzteres noch die verschieden möglichen Filter mit in den Kompressionslevel kodiert). PNG benutzt die zlib zur Kompression, und die zlib besitzt 10 Kompressionsstufen von 0 (unkomprimiert) bis 9 (maximale Kompression), wobei – laut der Doku der libpng – bei PNG-Bildern die Stufen >6 in der Regel keine weitere Verbesserung bringen, nur mehr Rechenzeit benötigen:

/* Set the library compression level. Currently, valid values range from

* 0 - 9, corresponding directly to the zlib compression levels 0 - 9

* (0 - no compression, 9 - "maximal" compression). Note that tests have

* shown that zlib compression levels 3-6 usually perform as well as level 9

* for PNG images, and do considerably fewer caclulations. In the future,

* these values may not correspond directly to the zlib compression levels.

*/

--RokerHRO 18:53, 5. Mär. 2011 (CET)

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)

Meinst Du die Absätze "Vorteile" und "Nachteile"? Ich habe dazu gerade im Artikel über BMP folgenden Beitrag in der Diskussion geschrieben: "Ich habe gerade die Begriffe PNG und BMP nachgeschlagen. Zwei ausgezeichnete Artikel. Leider für den schnellen Ueberblick für einen Laien sehr technisch. Ich vermisse bei diesem Beitrag über BMP die bei PNG vorhandenen, für Unkundige sehr nützlichen Absätze "Vorteile" und "Nachteile", die einen guten Ueberblick über PNG im Vergleich zu anderen Formaten geben, wenn man sich mit den Sachen nicht auskennt. Das wäre hier auch sehr nützlich. Gruss, Harald Andres". Mit anderen Worten, ich finde diese Absätze für Laien hilfreich. Gruss, Harald Andres

Disku von 2004 ??? somit:

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:28, 4. Dez. 2012 (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)

Disku von 2006 ? somit:

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:28, 4. Dez. 2012 (CET)

PNG

sitze in der schule brauche erklärung von png kurzfassung (nicht signierter Beitrag von 84.140.65.94 (Diskussion) 12:02, 7. Jan. 2013 (CET))

Lies einfach die zwei Sätze der Einleitung. Das müsste reichen. --McZusatz (Diskussion) 12:27, 7. Jan. 2013 (CET)

Sowas von:

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:48, 24. Jan. 2013 (CET)

Hinweis zur Verwendung innerhalb Wikipedia

Hallo, ich würde gerne einen Satz zur Verwendung/Bedeutung von PNG in der Wikipedia ergänzen, etwa nach den Absätzen Vorteile/Nachteile: In der Wikipedia ist PNG neben SVG das empfohlene Format für Grafiken und Skizzen. Einwände? --Forscher56 (Diskussion) 09:29, 24. Jan. 2013 (CET)

+1 ; kannst' ja fast schon vorletzten Satz per cut&paste reinnehmen X-) --arilou (Diskussion) 09:48, 24. Jan. 2013 (CET)

Verweise vom Artikelnamensraum in den Wikipedia- oder Hilfe-Namensraum sind nicht so gern gesehen. Das betrifft auch inhaltliche Verweise wie „In der Wikipedia wird Lemma soundso genutzt…“ --RokerHRO (Diskussion) 17:03, 24. Jan. 2013 (CET)

1. WP selbst ist inzwischen eine der meistbesuchten Websites des Internet, und somit durchaus maßgeblich z.B. für die Verbreitung und Unterstützung von Dateiformaten (z.B. Grafikformate).
2. Es geht nur um 1 Satz: "In der Wikipedia ist PNG neben SVG das empfohlene Format für Grafiken und Skizzen."

Daher halte ich diesen Selbstbezug als vertretbar. --arilou (Diskussion) 09:00, 25. Jan. 2013 (CET)

Bits pro Kanal

Im Abschnitt "Farbtiefen" wird nicht klar, was denn nun der Unterschied zwischen der ersten Auflistung 1,2,4,8,16 und RGB8 bzw. RGB16 sein soll. Gelten die ersten "1,2,4,8,16" vielleicht für Graustufenbilder? Dann sollte das auch so erkennbar sein.

--arilou (Diskussion) 11:07, 16. Apr. 2015 (CEST)

Geändert; war vor der Änderung klar, und sollte jetzt auch wieder klar formuliert sein.

--arilou (Diskussion) 11:24, 16. Apr. 2015 (CEST)

Bitkosten

Der Begriff taucht lediglich als Bildunterschrift auf. Es wird im Text kein Bezug darauf genommen und es wird auch keine Aussage dazu getroffen, welcher Farbton hohe Kosten widerspiegelt und welcher geringe. --Stahlpolymer (Diskussion) 08:39, 7. Feb. 2017 (CET)

Keiner und alle. Für hohe Bitkosten sorgen vor allem

• schnelle Farbwechsel (egal von welcher Farbe zu welcher anderen, solange es unterschiedliche sind)
• unregelmäßige Farbwechsel - regelmäßige, z.B. immer schön 1 Pixel schwarz, 1 Pixel weiß, schwarz, weiß, s.,w.,s.,w. ..." erzeugt nur geringe Kosten.

--arilou (Diskussion) 09:00, 7. Feb. 2017 (CET)

Revert 11.04.2018

Bzgl. dieser Änderung (praktisch ein Revert).

1) Verbreitung/"durchgesetzt"

Laut Artikel-Einleitung:

"[PNG ist] das meistverwendete verlustfreie Grafikformat im Internet [...] konnte sich PNG nicht gegen GIF und JPG durchsetzen."

Ein Format, das das meistverwendete ist, hat sich ja wohl durchgesetzt?!?

Ich vermute, dass die zweite Aussage schlecht recherchiert ist, und eingeschränkt werden müsste, z.B. "hat sich nicht als Format für die Fotoverarbeitung durchgesetzt", oder eine ähnliche Einschränkung.

2) Vorteil 'True-Color'

Für die Abschnitte 'Vorteile/Nachteile' ist nicht klar genannt, wogegen sie sich abgrenzen. Da steht nicht "Vorteile gegenüber xyz". Truecolor-Fähigkeit ist also ein Vorteil z.B. gegenüber Gif - aber nur ein 'Gleichstand' gegenüber JPG. (Allerdings kann JPG afaik keine 16 bit pro Farbkanal, womit PNG auch hier von einem 'Vorteil' sprechen kann.)

Ich fordere von Benutzer:Ralf Roletschek einen Eigenrevert seines Edits.

--arilou (Diskussion) 09:50, 11. Apr. 2018 (CEST)

Das "meistverwendete" bezweifle ich. Da die Quelle englisch ist, kann ich dazu nichts weiter sagen. Bei 5% Anteil kann wohl kaum die Rede von "meistverwendet" sein. Bei Truecolor ist PNG schwächer als TIF, DNG usw. --M@rcela 10:00, 11. Apr. 2018 (CEST)

Eine webweite Statistik über die Verbreitung im Internet bezweifelst du, die von einer Firma durchgeführt wird, aber eine (vmtl. falsch) zitierte Aussage einer einzelnen Person in einem einzelnen Buch traust du? (Über Sibylle Mühlke ist im Web nichts aufzufinden, außer dass sie wohl erfolgreich Adobe-Photoshop-Bücher schreibt.)

Und als zusätzlicher Beleg soll eine Anteils-Analyse der Wiki-Commons-Bilder dienen?

--arilou (Diskussion) 12:18, 11. Apr. 2018 (CEST)

Ich bezweifle jeden Bericht, der behauptet, im Internet wären mehr PNG als JPG. Dazu reicht gesunder Menschenverstand. --M@rcela 12:35, 11. Apr. 2018 (CEST)

Vorsicht mit solchen Argumenten, sonst müsste evtl. der Menschenverstand oder dessen Gesundheit angezweifelt werden.

JPG ist im Internet weit verbreitet, bei Fotos und Bildern. Nicht aber bei Logos, Buttons, Icons und ähnlichem, die ganzen kleinen Fitzel, die sich häufig verlustlos sehr stark komprimieren lassen. Das war früher eine Domäne von GIF, bis die Patentler kamen. Heute macht das (laut der englischen Quelle) wohl 80% PNG, 20% GIF.

Deshalb ist es wichtig, 'Foto' von sonstigen Grafik(ch)en zu unterscheiden.

--arilou (Diskussion) 13:08, 11. Apr. 2018 (CEST)

PS: Alleine hier im WP-"Rahmen" ist nur oben links 1 "Bild" (das 3D-Puzzle), aber 12 verschiedene Buttons, Icons, Symbole.

Durchsetzen

"Da PNG-Fotos in der Regel wesentlich größer sind als JPG und PNG lange Zeit nicht ohne Weiteres in Browsern dargestellt wurden, konnte sich PNG nicht gegen GIF und JPG durchsetzen."

Könnte das bitte jemand prüfen, ob in der Quelle nicht vielmehr gemeint war "in der Bild-Be- und -Verarbeitung"? Dass PNG dort nicht allzuweit verbreitet ist, kann ich leicht glauben.

Auf Webseiten, mit all den kleinen Buttons, Icons, Logos - da hat sich PNG ziemlich etabliert.

--arilou (Diskussion) 13:25, 11. Apr. 2018 (CEST)

RGB8 / RGB16

Eine WP:OmA weis vmtl. nicht, was "RGB8" bzw. "RGB16" bedeutet. Das sollte bei der ersten Verwendung in wenigstens einem Halbsatz erwähnt werden.

--arilou (Diskussion) 11:09, 16. Apr. 2015 (CEST)

Done, somit:

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:53, 6. Aug. 2020 (CEST)

"Farbpräzision"

Indizierte Farben oder weniger Bits pro Farbkanal müssen nicht bedeuten, dass das Bild eine "Geringere Farbpräzision" besitzen muss. Das sollte anders formuliert werden.

--arilou (Diskussion) 11:14, 16. Apr. 2015 (CEST)

Wird im Artikel so nicht mehr behauptet, Thema somit erledigt:

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:54, 6. Aug. 2020 (CEST)

Gif Patentbelastung

zu Beginn ist davon die Rede, dass das GIF Format bis 2006 mit einem Patent belastet sei und weiter unten, dass dem nur bis 2004 so war. (nicht signierter Beitrag von 79.214.10.164 (Diskussion) 08:01, 13. Aug. 2015 (CEST))

Man lese doch einfach unter GIF#GIF und die LZW-Patente nach:

Das "prominente" LZW-Patent lief Juni/Juli 2004 aus; weitere (nicht-prominente) Patente dann spätestens (laut „Software Freedom Law Center“) am 1. Oktober 2006.

Werd's im Artikel entsprechend korrigieren.

--arilou (Diskussion) 16:43, 3. Sep. 2015 (CEST)

Steht jetzt entsprechend im Artikel, somit Thema erledigt:

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:54, 6. Aug. 2020 (CEST)

Farbtiefen

"Farbbilder können alternativ mit dem Farbpalettenmodus mit bis zu 256 indizierten Farben gespeichert werden. Die indizierten Farben sind aus dem vollen RGB8-Spektrum frei wählbar."

Wo ist denn da der Vorteil, sich 256 Farben aus dem vollen RGB8-Spektrum (256 Farben) aussuchen zu können, um dann im Palettenmodus zu arbeiten? Da kann man ja gleich RGB8 hernehmen...

"RGB8" meint hier den RGB-Farbraum mit jeweils 8 Bit pro Farbkanal, also "24 Bit Truecolor". --RokerHRO (Diskussion) 09:59, 15. Apr. 2017 (CEST)

Macht Sinn, tschuldigung :-)

'RGB8' und 'RGB16' wird im Artikel mittlerweile "erklärt", somit ist diese Verwechslunsgefahr behoben, Thema erledigt:

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:56, 6. Aug. 2020 (CEST)

Transparenz

"Ein Alphakanal ist eine zusätzliche Information, die für jedes Pixel angibt, wie viel vom Hintergrund des Bildes durchscheinen soll (0 bis 100 %)."

Das ist unglücklich formuliert, man könnte denken, es ginge da tatsächlich um %-Schritte, wenn es doch tatsächlich nichts mit Prozenten (Hundertstel) zu tun hat.

Wenn man schon unbedingt die Prozente drinlassen will, könnte man es in etwa so ausdrücken:

"Ein Alphakanal ist eine zusätzliche Information, die für jedes Pixel angibt, wie viel vom Hintergrund des Bildes durchscheinen soll (0 entspricht 100% Durchscheinen, 255 bzw. 65535 entspricht 0% Durchscheinen)"

Gute Idee. Magst du es in den Artikel einbauen? :-) --RokerHRO (Diskussion) 09:58, 15. Apr. 2017 (CEST)

Ja, habe es eben eingebaut, bzw. geändert.

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:56, 6. Aug. 2020 (CEST)

Rolle des W3C

Zitat aus der Infobox: „Entwickelt von: PNG Development Group (dank W3C)“ – Wie ist das denn gemeint?

Die Entwicklung des PNG-Formats hatte wenig bis gar nichts mit dem W3C zu tun. Die PNG Development Group wurde von Thomas Boutell initiiert (ein unabhängiger Informatiker, bekannt für die GD-Library) und war ein bunt zusammengewürfelter Haufen von Leuten. Einer davon (Chris Lilley) war in der Tat W3C-Mitglied, diese Tatsache trug aber nicht zur Entwicklung des PNG-Formats bei. Zum W3C-Draft wurde PNG erst lange, nachdem der Standard weitgehend feststand.

Die ganze frühe Geschichte kann man hier nachlesen: http://www.libpng.org/pub/png/pnghist.html, und hier noch ein ausdrückliches Zitat von Greg's libpng-Homepage: „Despite the implications in some of CompuServe's old press releases and in occasional trade-press articles, PNG's development was not instigated by either CompuServe or the World Wide Web Consortium, nor was it led by them. Individuals from both organizations contributed to the effort, but the PNG development group exists as a separate, Internet-based entity.“

Lange Rede kurzer Sinn: Ich halte es für angebracht, den irreführenden (wenn nicht gar falschen) Zusatz „dank W3C“ zu streichen. --Winof (Diskussion) 20:03, 19. Aug. 2019 (CEST)

Done, somit:

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:58, 6. Aug. 2020 (CEST)

Transparenzbilder

Das Bild vor dem Schachbrettmuster hat Bereiche vor weißen Kacheln, die dunkler sind als im Bild mit ganz-weißem Hintergrund. Das widerspricht der Prämisse, dass es genau dasselbe Vordergrundbild sei, denn dann müssten Bereiche mit gleichfarbigem Hintergrund auch exakt gleich erscheinen.

--arilou (Diskussion) 11:48, 21. Apr. 2020 (CEST)

Bild ist mittlerweile aus Artikel entfernt, Problem somit wech; damit:

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 10:05, 6. Aug. 2020 (CEST)

Spritesheet

Im Abschnitt Nachteile werden “Spritesheets” erwähnt, mit einem Link, der auf die Seite Sprite (Computergrafik) weiterleitet. In selbigem wird aber der Begriff nirgendwo erwähnt.

Meine Vermutung ist, dass CSS-Sprites gemeint sind (zwar wird dort der Begriff “Spritesheet” ebenfalls nicht erwähnt, aber die Ableitung von “Spritesheet” aus “Sprite” und “Style Sheet” wäre in diesem Fall naheliegend).

Falls meine Vermutung richtig ist, sollte der Link m.E. entsprechend geändert werden. Sollte der Begriff “Spritesheet” generell verwendet werden, sollte er auch im entsprechenden Artikel ergänzt (und die Weiterleitungsseite entsprechend angepasst) werden. --2003:C3:CF23:F201:1025:EF27:8AA2:354F 09:48, 7. Jan. 2021 (CET)

Allgemein bezeichnet man mit Sprite-Sheets eine Reihe von Bildern (Sprites, Icons o.ä.), die spalten- und/oder zeilenweise zu einem größeren Bild zusammengefügt wurden. Häufig wird dies für Animationsphasen von Spielfiguren verwendet, aber auch für Icon-Sammlungen und Ähnliches. Wie man das am besten im Artikel umsetzt, ist mir leider nicht ganz klar. Wir haben zwar den Artikel CSS-Sprites, auf den man verlinken könnte, er beschreibt aber nur einen kleinen Teilaspekt von Sprite-Sheets, nämlich die Anwendung mit CSS innerhalb von Web-Applikationen. Sprite-Sheets wurden aber schon in Computerspielen vor 40 Jahren verwendet, lange bevor es CSS überhaupt gab. Daher fände ich einen Link auf CSS-Sprites eher irreführend (davon abgesehen finde ich diesen Artikel auch eher mangelbehaftet). Leider haben wir keinen Artikel über Sprite-Sheets, im Gegensatz zur englischen Wikipedia (siehe en:Sprite_sheet). --Winof (Diskussion) 15:36, 11. Jan. 2021 (CET)