Diskussion:Portable Network Graphics/Archiv

message: 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. 
: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)
thread_title:  Unterstützung eingebetteter Farbprofile 

message: Sollten in wikipedia nur PNG Bilder verwendet werden? (nicht signierter Beitrag von Nerd (Diskussion | Beiträge) 19:01, 30. Nov. 2002 (CET)
replies: text: 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)
replies: text: "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)
replies: text: Ich habe die Aussage jetzt relativiert. --Phrood 17:48, 18. Mär 2005 (CET)

text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  PNG in der Wikipedia 

message: 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)
thread_title:  GIF? 

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

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

message: "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)
replies: text: 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)
thread_title:  Verlustfreie Komprimierung nicht optimal? 

message: 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)
replies: text: 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)
thread_title:  Standardisierung, Weiterentwicklung 

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

message: 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)
replies: text: Verweis auf TweakPNG eingefügt. --Phrood 22:22, 2. Nov. 2006 (CET)
thread_title:  Metadaten anzeigen 

message: 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)
replies: text: "verlustfrei" ist richtig, korrigiert. --Phrood 17:54, 29. Jun 2006 (CEST)
thread_title:  Verlustfrei oder nicht? 

message: 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)
replies: text: 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)
replies: text:  Geändert--Uwe W. 19:16, 17. Mär. 2007 (CET)
replies: text: 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)
thread_title:  Einleitung 

message: 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)
replies: text: Richtig, ich habe dazu etwas ergänzt. --Phrood 12:14, 5. Mai 2007 (CEST)
thread_title:  Fireworks-PNG 

message: "# 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)
replies: text: Stimme zu, die Punkte könnten entfernt werden --Phrood 22:47, 8. Sep. 2007 (CEST)
thread_title:  Nachteile 

message: 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)
replies: text: 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)
replies: text: "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)
thread_title:  Moderne Browser - Arachne? 

message: Was hat es mit dem Byte 89hex 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)
replies: text: Eben! Durch den Nicht-ASCII-Wert soll verhindert werden, dass PNG-Dateien irrtümlich als Textdateien erkannt werden. Siehe  --Phrood 21:22, 12. Feb. 2008 (CET)
replies: text: Großartig! Danke. Das sollte doch unbedingt in den Artikel aufgenommen werden, meinst du nicht? :-) --RokerHRO 21:39, 12. Feb. 2008 (CET)
replies: text: 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)
thread_title:  Magic number 

message: "# 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)
replies: text: 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)
thread_title:  Vorteile 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text:  Diese Annahme teile ich mal. Make it so! :-) --RokerHRO 13:17, 3. Apr. 2008 (CEST)
replies: text:  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)
thread_title:  Magic Number in der Infobox 

message: 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)
replies: text: Ja, aber bei mehr Farben dann nicht mehr über eine Farbpalette sondern nur noch über DirectColor. --RokerHRO 15:38, 16. Aug. 2008 (CEST)
thread_title:  256 Farben 

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

message: "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)
replies: text: "Portable Netzwerkgraphik" halte ich auch für vernünftig.-- ThorJH Disk. 22:02, 17. Dez. 2009 (CET)
thread_title:  Übersetzung von "Portable Network Graphics" 

message: 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)
replies: text: 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)
replies: text:  Algemeiner Hinweis: Weder in CYMK noch in RGB sind "alle möglichen" Farben darstellbar.-- ThorJH Disk. 09:31, 6. Feb. 2010 (CET)
replies: text:  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)

text: 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)
thread_title:  Abschnitt „Nachteile“ 

message: "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)
thread_title:  Durchsetzen 

message: "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)
replies: text: Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:56, 6. Aug. 2020 (CEST)
thread_title:  Transparenz