Diskussion:Portable Network Graphics

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Portable Network Graphics“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Zum Archiv

Automatische Archivierung

Auf dieser Seite werden Abschnitte mittwochs automatisch archiviert, deren jüngster Beitrag mehr als 730 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 6 Abschnitte.

Automatische Archivierung

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 1500 Tage zurückliegt. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 6 Abschnitte.

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 14 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter Archiv.

"Farbtyp" ?

Abschnitt "Farbmodi und Präzision"

[...] sowie einen Graustufen- und einen Farbmodus mit Alpha-Kanal (Farb-Typen 0, 2, 3, 4 und 6).

Im ganzen Artikel wird nicht erklärt, was das für ominöse "Farb-Typen" sein sollen.

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

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte. Problem besteht noch.

Allgemeinverständlichkeit

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte. Teile des Problems bestehen noch.

Es fehlt die Einordnung, wozu das (Ab den technischen Details - Komprimierung, Dekorrelation) gut ist, gefolgt von einer wohlüberlegten Erklärung. Momentan fühlt es sich an, wie eine unsortierte Liste von Konzepten oder ein Aufsatz ("Zuerst kann man ... Dann kommen ... Abschließend ..."). Die Bananen helfen dabei leider nicht, weil der Text nicht darauf Bezug nimmt. --2A02:8388:6281:F080:7067:A488:151:2DDE 09:44, 21. Apr. 2020 (CEST)

Kompressions-Details für Bilder sind ein komplexes Thema. Soweit ich das sehe, ist das hier schon ziemlich gut erklärt, bitte ggf. die verlinkten Detailartikel studieren. Dass man dabei nicht alles gleich beim ersten Lesen versteht - ist nunmal so.

Alle Fachwörter im Abschnitt "Komprimierung" sind verlinkt oder werden nachfolgend genauer erläutert; LZSS und Huffman sind dann schon allgemeine Kompressionsverfahren, die gar nicht mehr Bild-spezifisch sind.

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

Danke für die Rückmeldung. Dein Argument "Ist ein komplexes Thema" geht doppelt ins Leere, da ich erstens nicht behauptet habe, dass das das Problem sei und zweitens laut WP:ALV nicht als Argument zulässig ist. Es sind weiters nicht alle Fachbegriffe verlinkt ("Codes variabler Länge" ist z.B. ein Rotlink). Ich werde den Baustein wieder einsetzen und würde dich bitten, noch einmal meine oben vorgebrachten Bedenken zu überfliegen. --2A02:8388:6281:F080:BD5D:5E8:2206:CACA 11:39, 22. Apr. 2020 (CEST)

Das Bananenbild dient tatsächlich nicht der Erläuterung der Kompression sondern zeigt nur deren Effizienz, richtig.

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

Es wird ein Ablauf beschrieben: Zuerst (Schritt 1), Dann (Schritt 2), Abschließend (Schritt 3). Also "in genau dieser Reihenfolge". Dabei sind Schritt 1 und Schritt 2 (teilweise) optional. Ich finde, "Zuerst, dann, abschließend" verdeutlicht ausreichend, dass das eine Reihenfolge ist, wenn aber unbedingt nötig, könnte man es auf "Schritt 1: Zuerst ... Schritt 2: Dann ... Schritt 3: Abschließend wird ..." erweitern.

In den nachfolgenden Kapiteln wird dann jeder Schritt nochmal ausführlich im Detail erläutert.

Den Rotlink hab' ich rausgenommen, es ist schließlich nur ein Erklärungssatz, was man unter Huffman-Kodierung sowie Entropiekodierung verstehen kann. Soweit ich sehe, war das der einzige "Fachbegriff", der nicht (effektiv) verlinkt war.

Zu WP:ALV: "Menschen ohne einschlägige fachliche Vorbildung sollen zumindest die zusammenfassende Einleitung [...] verstehen können." In den Details eine Mathe-Artikels wird auch nicht andauernd Höhere Mathematik erklärt, sondern (z.B. für Herleitungen oder Beweise) einfach vorausgesetzt.
Ich hab' schon so manches über Kompressionsalgorithmen gelesen, und speziell hier, in diesem Artikel, ist das imo ziemlich gut und verständlich erklärt. Ich sehe nicht, warum allgemeine Themen, die nicht PNG-spezifisch sind, wie korrelierende Werte, Substitutionskompression oder Entropiekodierung hier nochmals erklärt werden müssten.

--arilou (Diskussion) 09:56, 23. Apr. 2020 (CEST)

Das hat auch niemand gefordert. Die Begriffe sind aber nicht verlinkt und der Artikel entspricht somit nicht den Richtlinien für ALV. Ein Argument der Form: "Ich muss mich nicht an die Regeln halten, weil die anderen tun es ja auch nicht" kommentierte ich sicher nicht weiter. Nicht zuletzt, weil es nicht zutrifft und die Mathe sehr wohl an ALV arbeitet. --2A02:8388:6281:F080:BC25:8ADD:96B0:238C 13:01, 11. Mai 2020 (CEST)

PS: Bevor du hier einen EW veranstaltest, empfehle ich dir, deine Argumente mal durch 3M gegen lesen zu lassen. Es wäre auch guter Stil, die Allgemeinverständlichkeit nicht selbst, sondern von einem - wie der Name schon sagt - allgemeinen Publikum beurteilen zu lassen. Insbesondere, nachdem du ja schon indirekt eingeräumt hast, dass sie nicht gegeben ist. --2A02:8388:6281:F080:BC25:8ADD:96B0:238C 13:07, 11. Mai 2020 (CEST)

Das empfinde ich als eine gute Idee. -> Wikipedia:Dritte Meinung#Portable Network Graphics

--arilou (Diskussion) 15:16, 11. Mai 2020 (CEST)

WP:Dritte Meinung

3M: ich denke schon, dass die Verständlichkeit verbessert werden kann.

• Substitution und Entropiekodierung werden in einem Abschnitt behandelt, oben aber als separater Schritt beschrieben. Wieso? Falls beides Deflate macht, wovon ich ausgehe, dann sollte man auch oben beides zusammen behandeln. Im Prinzip ist das ja nicht viel anderes, als den Bytestrom (wie eine Zip-Datei) zu komprimieren. Da ist die Erklärung hier und die Aufteilung in zwei Schritte schon eher zu viel.
• Der Begriff "Dekorrelation"/"dekorreliert" ist nicht unbedingt laienverständlich. Was eine Korrelation im statistischen Sinne ist, mag ja noch klar sein, aber wie das Entfernen von Korrelation helfen soll, Pixel zu komprimieren, ist nicht offensichtlich. Beides ist auch nicht verlinkt. Die Erklärung mit dem Reduzieren der Dynamik ist okay, aber dass mit Korrelation aber die Ähnlichkeit zu den benachbarten Pixeln gemeint ist, wird nicht sofort klar.

Der Baustein ist allerdings überflüssig, so schlimm ist der Abschnitt auch nicht. -- Jonathan 17:07, 11. Mai 2020 (CEST)

Dritte Meinung Patentrezept habe ich nicht, es gibt aber auf jeden Fall Verbesserungsmöglichkeiten. Wenn man https://compress-or-die.com/PNG-verstehen liest erkennt man, dass die verschiedenen Verfahren bestimmte Eigenschaften des Bildes ausnutzen, beispielsweise einfarbige Flächen, wiederkehrende Elemente etc. Eigentlich sollte es klappen, den Absatz gemeinsam zu verbessern und verständlicher zu machen. --Siehe-auch-Löscher (Diskussion) 20:14, 11. Mai 2020 (CEST)

Ergänzung: Als erstes sollte man die optionalen Kompressionsschritte benennen und aufzählen, die genannte Quelle schreibt

1. Vorfiltern
2. Wörterbuch-basierte Kodierung per LZ77
3. Entropiekodierung per Huffman

Deckt sich das mit diesem Artikel? Ich kann das leider nicht beurteilen. --Siehe-auch-Löscher (Diskussion) 08:41, 12. Mai 2020 (CEST)

3M: Ich finde den Artikel jetzt auch nicht so schlimm (der Baustein muss definitiv nicht sein), aber Verbesserungspotential gibt es natürlich.

• Vielleicht wäre es für das grundlegende Verständnis hilfreich, zunächst einmal zu erwähnen, dass das PNG-Format zur eigentlichen Kompression den sogenannten Deflate-Algorithmus verwendet (RFC1951) – das ist exakt derselbe Algorithmus, der von den bekannten Tools ZIP, PKZIP und gzip verwendet wird (ich denke, die meisten Leser können damit etwas anfangen). Also keine neue Erfindung, sondern etwas seit langem etabliertes, über das zahlreiche Bücher, Dokumente und Informationen im Internet existieren (und natürlich ein Wikipedia-Artikel). Dieser Algorithmus ist eine Kombination aus LZ77 und Huffman-Kodierung. Genauer muss man es an dieser Stelle eigentlich gar nicht beschreiben, denn das steht schon alles im Deflate-Artikel. Um es nochmal ganz klar zu sagen: PNG tut im Prinzip nichts weiter als die Graphikdaten zu „zippen“ (bzw. „gzippen“, um UNIX-/Linux-jargon zu verwenden).
• Zusätzlich kann (optional) beim PNG-Format ein Vorfilter eingesetzt werden, der dafür gedacht ist, die Komprimierbarkeit durch Deflate zu verbessern. Das ist eine relativ simple Geschichte; der Vorfilter kann z.B. die Differenz zwischen benachbarten Pixeln ermitteln, denn es gibt Fälle, wo diese Differenzen besser komprimiert werden können als die Pixel selbst. Ob diese Vorfilter in der Praxis wirklich viel bringen, ist nicht ganz unumstritten. Es gibt aufwendige „PNG-Optimier-Tools“, die für ein gegebenes Bild jede mögliche Kombination von Vorfiltern systematisch durchtesten und vergleichen, wie gut es am Ende komprimiert wird. Tatsächlich bringt es nur in Ausnahmefällen und bei speziell konstruierten Testbildern wirklich viel, ansonsten ist der Nutzen in der Praxis nur wenige Prozent.

--Winof (Diskussion) 13:08, 12. Mai 2020 (CEST)

@Winof Ohne jetzt Quellen zitieren zu können, gehe ich davon aus, dass das Vorfiltern an sich schon enorm viel bringt. Was in der Tat relativ wenig bringt ist, die verschiedenen Vorfilter per Brute Force durchzuprobieren um die Komprimierung zu optimieren. Aber immer nur stumpf den Paeth-Predictor zu nehmen (z. B.) durfte wesentlich besser sein als komplett ohne Vorfilter. Wobei mir auch nicht ganz klar ist, inwieweit die Schritte wirklich optional sind. Kann ich eine PNG-Datei wirklich ohne Vorfilter und ohne Deflate-Komprimierung speichern? Bzw. bei Deflate auch noch LZ77 oder Huffman einzeln deaktivieren? Was wäre der Sinn? -- Jonathan 08:47, 17. Mai 2020 (CEST)

@Jonathan Haas: Es ist richtig, dass der Paeth-Filter bei abgestuften Bildern noch am meisten bringt, aber wirklich nicht umwerfend viel. Die restlichen Filter bringen so gut wie gar nichts, außer in bestimmten Grenzfällen und bei konstruierten Testbildern. Bei Bildern mit Palette („indexed“) oder weniger als 8 Bit Farbtiefe bringen die Vorfilter allesamt nichts. Es ist alles lange her, daher habe ich leider keine konkreten Zahlen parat. Aber wenn man abgestufte Bilder (z.B. Fotos) verlustfrei speichern muss und dabei soviel Platz wie möglich einsparen will, sollte man eher auf spezialisierte Formate wie JPEG2k ausweichen.

Die Vorfilter sind in der Tat optional. Typ 0 ist definiert als „kein Filter“, d.h. die Bytes werden unverändert zum Komprimieren durchgereicht. Das Komprimieren ist dagegen nicht optional; der PNG-Standard definiert zwingend den Deflate-Algorithmus. Allerdings kann der Deflate-Algorithmus auch quasi unkomprimierte Daten produzieren, wenn man will, indem man einfach das Wörterbuch weglässt (es gab GIF-Implementationen, die dies getan haben, um das Unisys-Patent zu umgehen) und anstelle richtiger Huffman-Codes eine 1:1-Codierung verwendet. Sowas dürfte aber in der Praxis keinen besonderen Nutzen haben. --Winof (Diskussion) 18:17, 18. Mai 2020 (CEST)

Sinn? Manchmal gibt es Randbedingungen, z.B. Performance, dass einfach keine Zeit für Vorfilter und zippen ist, und die Bilddaten einfach nur möglichst schnell Platz machen müssen für die nächsten. Also ab mit dem .png auf das SSD-Raid...

Nur so als (ausgedachtes) Beispiel. --arilou (Diskussion) 09:45, 19. Mai 2020 (CEST)

Um ehrlich zu sein fällt es mir schwer, mir ein konkretes, praktisches Beispiel vorzustellen, bei dem eine solche Vorgehensweise tatsächlich vorteilhaft wäre. Normalerweise wird eine PNG-Datei einmal geschrieben, aber öfter gelesen, so dass der Aufwand für die Kompression nicht so sehr ins Gewicht fällt. Davon abgesehen ist der Deflate-Algorithmus auf halbwegs aktueller Hardware so schnell, dass es vielleicht nur dann einen Unterschied macht, wenn man extrem große Mengen an PNG-Daten erzeugen muss – aber dann wiederum wird der Nutzen wieder dadurch aufgefressen, das die unkomprimierten Daten mehr I/O-Bandbreite benötigen. Wenn man wirklich in so einer Situation ist, ist es vermutlich am sinnvollsten, einen der schnelleren Kompressionslevel zu verwenden, z.B. Level 2 (Default ist – je nach Software – meistens Level 5 oder höher), was immer noch erheblich besser ist als gar nicht zu komprimieren, und vermutlich nicht nenneswert mehr Zeit benötigt (das Erzeugen von „Fake-Deflate“-Daten ohne Kompression erfordert durchaus auch einen gewissen Rechenaufwand, da die Daten ja so codiert werden müssen, dass sie ein Decoder als vermeintliche Deflate-Daten lesen und „dekomprimieren“ kann). Damals bei der Fake-GIF-Kompression ging es tatsächlich nur um die Patent-Problematik; nach Auslaufen des Patents ist diese Software wieder in der Versenkung verschwunden.

Wenn man – aus welchem Grund auch immer – Bilder unkomprimiert speichern möchte, bietet es sich an, ein Format zu verwenden, das dies „von Natur aus“ unterstützt. Das geht schneller und erzeugt kleinere Dateien, als wenn man versucht, so etwas mit PNG zu „faken“ (aufgrund des LZ77- und Huffman-Overheads). --Winof (Diskussion) 15:59, 11. Jan. 2021 (CET)

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)

Facebook

Laut Text wird von Facebook animiertes GIF nicht unterstützt, im Eintrag zu GIF steht aber dass sie sich doch dazu durchgerungen haben. Scheint mir also veraltet und inzwischen falsch zu sein. (nicht signierter Beitrag von 2A02:810D:2440:2933:F872:355:509B:5387 (Diskussion) 07:12, 13. Mär. 2021 (CET))

Infos zur (verlustarmen/-freien) Skalierbarkeit

Für Laien sollte aus dem Text auch hervorgehen, ob man Grafiken (harte Kanten) im PNG-Format ohne große Verluste skalieren (speziell vergrößern) kann. Nicht jeder Mensch kennt sich mit Vektorformaten und solchen Dingen aus. --Zopp (Diskussion) 15:10, 28. Dez. 2022 (CET)

Das ist eine generische Eigenschaft aller Rastergrafik-Formate und wird daher im Artikel Rastergrafik thematisiert, der bereits in der Einleitung verlinkt ist. Es ergibt keinen Sinn, solche allgemeinen Eigenschaften in allen Artikeln über konkrete Grafikformate (und das sind viele!) zu wiederholen. --Winof (Diskussion) 10:45, 29. Dez. 2022 (CET)

Ich verstehe die Relevanz dieses Einwands, aber an erster Stelle sollte immer die Userfreundlichkeit sein - und welcher Laie weiß denn, daß er Infos zu dieser Eigenschaft unter dem Stichwort Rastergrafik finden wird? Und: Wenn es schon Abschnitte Vergleich > Vorteile/Nachteile gibt, dann gehört diese Info (aus Sicht der Informationssuchenden) doch wohl dort dazu? Redundanzen hin oder her, die lassen sich im Interesse der Praxistauglichkeit nicht komplett vermeiden. --Zopp (Diskussion) 15:26, 29. Dez. 2022 (CET)

Rastergrafik ist an prominenter Stelle in der Einleitung verlinkt, das muss genügen (davon abgesehen geht aus dem Artikel auch klar hervor, dass die Bilddaten pixelweise gespeichert werden). Wenn sich ein „Laie“ dafür interessiert, ob etwas verlustfrei skaliert werden kann, dann kann man durchaus von ihm erwarten, dass er sich über die Unterschiede von Vektorgrafik und Rastergrafik informiert. Zweitens kann man von jemandem, der sich für Skalierung interessiert, erwarten, dass er in den gleichnamigen Artikel Skalierung hineinschaut, wo das Thema ausführlich und erschöpfend erläutert wird. Irgendwo muss man einen Kompromiss eingehen bzw. eine Grenze setzen, damit die Pflege von Artikeln in der Wikipedia nicht ausufert, und diese Grenze wäre ganz klar überschritten, wenn identische Informationen in 70 Artikeln eingearbeitet werden sollen, die bereits im Artikel zum Oberbegriff enthalten sind. Ich fürchte, so etwas würde in der Wikipedia generell auf wenig Akzeptanz stoßen, gleichgültug um welches Thema es geht.

Übrigens, der Abschnitt Vergleich beschreibt die Vor- und Nachteile im Bezug auf andere Rastergrafikformate. An dieser Stelle mit Formaten zu vergleichen, die keine Rasterformate sind, wäre unpassend (Äpfel mit Birnen). Der Artikel über PNG ist dabei keine Ausnahme; siehe die Artikel von anderen gängigen Rastergrafikformaten (z.B. JPEG, GIF, BMP, TIFF) – keiner von denen trifft Aussagen zur Skalierbarkeit, oder versucht, Vergleiche mit Vektorgrafikformaten zu ziehen. --Winof (Diskussion) 10:36, 30. Dez. 2022 (CET)

PS: Ist übrigens in der englischen Wikipedia genauso (aber das nur am Rande). --Winof (Diskussion) 10:43, 30. Dez. 2022 (CET)