Talk:PNG

PNG comparison

The section "In contrast, when storing images that contain text, line art, or graphics – images with sharp transitions and large areas of solid color – the PNG format can compress image data more than JPEG can." could use a little clarification. I'm sure PNG can ALWAYS compress better than JPEG when the criteria is lossless reproduction of the original image (or something very close to it.) Does anybody have a reference where this information is from, and what criteria were used for this comparison?

80.212.191.68 (talk) 13:25, 26 December 2014 (UTC)

The text is speculative and should be deleted. Most of the comments in that section have no references and are not obviously derived from the standard. There have been discussions on the working group mailing lists about this, but they are also mostly speculative and there have been counter arguments suggesting it is better to use JPEG than PNG regardless of the image data if small file size is required.

I'm not going to change it because the whole section needs research and a rewrite, which I am not about to attempt.

Jbowler (talk) 05:59, 4 May 2015 (UTC)

Pronunciation

I've never heard anyone pronounce it "Ping" and most people would look at you blankly if you said it, which was why I thought writing "the official pronunciation" seemed a bit odd. Most people don't read the implementation standard to find out how to pronounce an abbreviation. Ojw 11:12, 14 August 2005 (UTC) (henceforth referring to libpng as l'Academié Pingèse)

Everyone I know pronounces it "ping". --KJBracey 14:58, 21 October 2005 (UTC)

The prononciation is defined as "ping" by the official specification. It's a specification feature! --Adhemar

Strictly speaking, abbreviations are never pronounced in proper English. The official specification is simply wrong (and yes, this is "feature"): it is more accurate to say P-N-G is officially called or referred to as 'ping' (which I have never heard used by the way). There is no pronounciation, proper or improper, for any abbreviation including PNG. I just found this a bit odd and annoying especially for an encyclopedia. Yes, it's the language police!!!! 207.112.56.138 01:30, 14 October 2007 (UTC)

That's absurd; people pronounce abbreviations all the time. NASA is na-suh, for example, GNU is gnu, and BASIC is pronounced like basic. If you meant something else, please elaborate, because I cannot interpret your message in a way that makes sense.--Prosfilaes 04:36, 14 October 2007 (UTC)

Most people I know pronounce it as "png" or "p-n-g", but then again, I live in the Netherlands. There is also the question of whether a specification should address what is essentially a linguistic issue. Suppose for a moment that a specification would contain the line "This format is called Foo, which is pronounced 'bar'." Would you accept that? I sure as hell wouldn't, so by extention I don't see a reason to accept this for PNG either. 82.139.85.9 (talk) 02:45, 2 January 2008 (UTC)

People may pronounce abbreviations/initialisms "all the time", however, this may develop confusion amongst the tech community. As mentioned earlier, individuals may "stare blankly" if one were to pronounce it in such a manner. I for one, agree, seeing ping as more commonly recognized as the act of triggering a node (ping/pong) on a network to respond via ICMP. 66.244.80.2 (talk) 16:36, 15 November 2010 (UTC)

• Culturally, suggesting both pronunciations (as "ping" or "P-N-G") seems appropriate. As mentioned above, in the USA, many acronyms are pronounced as words, if they don't sound awkward, such as NASA ("naa-suh") or Space Shuttle contract STSOC ("Stee-sock"), but not IRS (spoken "I-R-S" since "urrs" or "ires" would be awkward) and not DoD (spoken "D-oh-D" since "Dodd" would be odd). For company names, there's "AT&T" (spoken "A-T-and-T") or "IBM" (spoken "I-B-M") versus "DEC" (spoken "Deck" not "D-E-C"), and DEC's computer OS "VAX/VMS" was a combination word+letters (spoken "Vacks-V-M-S" not "vims"). Some people in the USA commented that Operation Iraqi Freedom should have been renamed as Operation Iraqi Liberation ("OIL" as the word). Hence, pronouncing "PNG" either as a word, or letters, fits English as spoken in the USA plus other countries. -Wikid77 (talk) 09:58, 26 April 2008 (UTC)

Adding more fuel to the fire; NASA is pronouced as a word because people recongize it such. GNU is both an acronym and a word in itself (a gnu is a horny beast, to quote the FSF). AT&T is not recognized as a word (by anyone I ever heard of) and would be ackward to pronouce; it doesn't fit how people speak english or any other language (that I know of). PNG falls into the category of abreviations which do not look like words and would be ackward to pronouce if tried. Ping, I agree, is a close resemblence to PNG, but most (I suggest) people who do not speak english natively would 'stare blankly' if you suggested that the way to pronouce the name of the image file format PNG is "ping". Anyways, the discussion is a bit moot. The official pronouciatin of PNG is ping, regradless of how much sense that makes (or how little) 80.162.60.16 (talk) 17:57, 30 November 2011 (UTC)

Since there are no vowels in the acronym, it should be pronounced officially as Pee-en-jee. Also, acronyms should not be a word. WiinterU (talk) 12:37, 20 March 2023 (UTC)

May I direct this conversation to this page: en.wikipedia.org/wiki/Acronym_and_initialism there is a difference between NASA, and PNG, NASA is an acronym, an abbreviation that sounds like a word, PNG is an initialism, you say the initials of the word. DFTBA! 216.67.75.63 (talk) 06:29, 30 August 2012 (UTC)

One: This is a dead discussion; there's no point in moving it.
Two: They're both initialisms, and in American English typically pronounced as words, not initials.
Three: Nothing you say will change that: the usage is far too widespread. See above.
Cheers. -- Elphion (talk) 08:32, 30 August 2012 (UTC)

I've also never heard anyone refer to a "PNG" file as a "PING". The whole bunch of examples of acronyms that are spoken as words or acronyms that are spoken letter-by-letter misses one simple rule: An acronym with a normal "English-like" arrangement of consonants and vowels (or "Y"), whether coincidentally or by design, probably will be spoken as a word. On this basis, it's no wonder that no-one really speaks the acronym "PNG" because it doesn't contain a vowel. Ian Fieggen (talk) 04:37, 6 April 2014 (UTC)

Have you read the discussion above? When someone says "I've never heard that" and someone answers "I've always heard that", then it is clear that that kind of argument cannot settle the matter. What is clear is that both pronunciations are used, despite all the argument about why that shouldn't be true. -- Elphion (talk) 22:07, 6 April 2014 (UTC)

The only authoritative source for the pronunciation is the one given in the citation. It matters little whether it should be pronounced that way or, even, whether it is pronounced that way unless someone can provide a source which suggests that it is not pronounced that way. Until it appears in a dictionary we only have one source - the article that was cited - and even if is in a dictionary, that's just another source.

Jbowler (talk) 06:04, 4 May 2015 (UTC)

I'm writing an APNG decoder and came here to reference something unrelated, but I just realized that the article offers an alternate pronunciation for PNG before the official pronunciation. And here I see that this may be an old dead-horse topic, but as an authoritative source, Wikipedia should be more exacting: List the official pronunciation first!

The creators of the word/initialism/whatever-your-spin-wants-to-call-it specifically and explicitly say it is pronounced "ping", with full and pointed awareness of the GIF problem.

Everyone else is wrong.

This is true whether people like it or not; whether it makes sense or not; whether mispronunciations exist in the wild or not; whether speakers have bothered to read the spec or not; whether you classify it as an initialism or something else. If you are disagreeing with the creator(s) of a word, you are placing your own ego about how things work above the rightful owner of the work.

I'm going to edit the article to place the official pronunciation FIRST, and make clear the second is an unsanctioned alternative found in the wild.

—Duoas 05:00 3 Dec 2019 (UTC)

The people who call it 'ping' are probably the same people who pronounce gif as 'jif' - i.e. idiots — Preceding unsigned comment added by 2.121.230.219 (talk) 21:10, 25 November 2020 (UTC)

I don't disagree that it should be listed first given the 'ping' pronunciation is given in the ISO/IEC standard. With that stated, the idea that the creator of a word's opinion should determine how it's pronounced for the rest of eternity is completely nonsensical. PNG isn't a brand name, it's a non-patented file format and the pronunciation is therefore a reflection of common usage, not the opinions of an individual. — Preceding unsigned comment added by 119.24.200.63 (talk) 01:11, 26 January 2021 (UTC)

I see this horse is already nearly dead, but found my way here as someone who falls into the 'never' camp when it comes to hearing it pronounced 'PNG'. This phrase: (PNG, officially pronounced PING, more commonly pronounced PEE-en-JEE) seems wholly made up and is unsupported by the source it sites. I am proposing removing the more as it's well established in this discussion that short of a source indicating which pronunciation is more common it's all anecdotal. (PNG, officially pronounced PING, commonly pronounced PEE-en-JEE) Ccunning (talk) 17:46, 17 June 2021 (UTC)

I wouldn't say it's wholly made up. Standard pronunciation rules would dictate that when you have three consonants written together in capital letters without a vowel you'd pronounce it like an initialism. Beyond that, you typically don't have a source for any issue of pronunciation like this. It would require some kind of professionally administered global survey, which nobody is ever going to conduct due to the trivial nature of the topic. I personally would have absolutely no doubt that PEE-en-JEE would be the more common pronunciation across the world due to: 1) the fact it complies with standard pronunciation rules; 2) the high likelihood that people would first be exposed to the word in a written format rather than by hearing it in a conversation; 3) because the reasons why "Ping" is "correct" stem from obscure quotes by the creators of the format and an ISO/IEC standard hardly anyone will have ever heard of. In general, I always think arguments for changes that are highly likely to be wrong in reality and which are justified by appeals to impossible sourcing requirements rarely improve Wikipedia articles. 119.24.200.63 (talk) 07:11, 29 June 2021 (UTC)

png/jpg file comparison w/ transparent

"Using PNG instead of a high-quality JPEG for such images would result in a large increase in filesize (often 5–10 times) with negligible gain in quality."

recently i converted an image to png (no downsizing) and turned the largely white background into a transparent background which cut down tremendously on file size and was nearly the size of the original jpg. i think its fair to note this somewhere in the article, anyone disagree? --AlexOvShaolin 22:22, 18 October 2007 (UTC)

That's not exactly due to the transparency, it's probably more because when you made the made those areas transparent, you made them a uniform colour, and areas of uniform colour compress very well.

Many image editors, when making parts of an image completely transparent, will also reset the colour values (normally to black, I think.)

You should get similar results if you just paint the background areas as a solid colour. In fact, you'd probably get a smaller result since an Alpha channel would then not be needed.

Of course, a similar trick could be used with a JPEG image. Solid blocks of colour will compress quite well under JPEG too. CountingPine 19:09, 19 October 2007 (UTC)

Internet Explorer 3

IE3 actually has a update available that allows it to support PNGs. I know this only because I remember applying it back in the 90s... 87.112.74.244 (talk) 13:49, 29 December 2007 (UTC)

Pix or it didn't happen. 82.139.85.9 (talk) 02:46, 2 January 2008 (UTC)

I found two conflicting arguments for this on Microsoft's very own website: "Internet Explorer 3.0...PNG graphics"[1] and "PNG output format requires Internet Explorer 4.0 or later"[2], yet there is no mention of PNG in the Internet_Explorer_3 article. I'm not sure what to believe. Time to install Multiple IE.[3] --Hm2k (talk) 10:02, 25 September 2008 (UTC)

Library support?

This page should contain a subsection in "Software support" called "Library support". 82.139.85.9 (talk) 02:46, 2 January 2008 (UTC)

Wikipedia PNG nightmares

04-Feb-2008: The handling of PNG files on Wikipedia has involved many nightmares of changing problems with speed, access, display, and lockouts over the past year. Although PNG files are typically 4x to 21x times slower than equivalent JPEG thumbnails, they have been used to display numerous photographs or paintings on Wikipedia. There was even a massive effort to convert all small GIF or JPEG files (which showed a text label) into gargantuan PNG files, causing Wikipedia articles to become mostly PNG data and no longer primarily text in 2007. The massive size of PNG thumbnails can be seen by right-clicking on image properties in Wikimedia Commons, which formerly also worked on Wikipedia to show image width/height, file name, and file size. The right-click menu for PNG/SVG images was disabled on Wikipedia during late 2007 (but not on Wikimedia Commons), and it is no longer possible on Wikipedia to right-click open PNGs in a new window or display the image properties/sizes. For a few days in November 2007, the right-click menu once again worked for Wikipedia PNG files, but in December 2007, the right-click menu for PNG images was disabled again. As if that weren't bad enough, for people expecting to right-click open a PNG image in a new window, as of February 2008, attempting to stop the slow, massive download of gargantuan PNG files usually will lock-up a browser, until going offline. Formerly, all during 2007, a massive PNG file could be stopped by clicking the browser "STOP" button to quit the gargantuan download of the bloated PNG files, and resume viewing of a Wikipedia article. However, in February 2008, the PNG download began forcing the browser window to continue the slow download of gargantuan PNG images by locking that browser window when the "STOP" button is clicked, and continuing a hacked download attempt, unless the browser is taken offline to release that locked window and resume viewing the page. Not only are many Wikipedia files bloated with the mass of gargantuan PNG files, but once those PNG images begin the massive download, the browser window becomes jammed to prevent scrolling text. However, by stopping a Wikipedia article soon after the text appears, the PNG images can be pre-empted, and the page can be scrolled to read the text (with blank images) or to just "Show Picture" for each JPEG or GIF image on the page. To make matters even worse and worse, for a while, Wikipedia was forcing the text portion of each page to wait until the slow, massive download of gigantic PNG files was completed, BEFORE any part of a Wikipedia page would be displayed. Of course, there was no Wikipedia announcement that these peculiar changes in spastic handling of the gargantuan PNG files would impact users in such bizarre and nightmarish ways. Note that the problem is not the gigantic PNG files, but rather peculiar changes in the way Wikipedia displays PNG files, because on Wikimedia Commons, PNG files are always incredibly slow, massive downloads, but STOPPABLE mid-way, and the right-click has never been blocked to prevent viewing the massive sizes of PNG images, nor the browser locked or forced to display those gigantic PNG files on Wikimedia Commons. The nightmare of unpredictable PNG image viewing, blocking, and browser lockups has only occurred on Wikipedia. The use and handling of PNG images has made Wikipedia look like a very trashy and cumbersome website, as well as slowing response time for many thousands of Wikipedia users. As usual, GIF and JPEG images incur no delays or lockouts of any kind. At this point, I must advise: avoid using all PNG images on Wikipedia until the PNG-garbling has been resolved; GIF or JPEG images will still allow users to right-click open in a new window and can be stopped during display, without browser lockup. -Wikid77 (talk) 05:49, 4 February 2008 (UTC)

This page is for discussing the article on PNG files. See Wikipedia:Bug reports for how to report problems with Wikipedia. --Zundark (talk) 08:41, 4 February 2008 (UTC)

Fireworks

"Apparently Adobe Fireworks is among the few tools that can produce semi transparent PNG8 files which degrade gracefully to single color transparency in the older IEs."

This seems a little unencyclopaedic. Also, is there a reference? —Preceding unsigned comment added by Jordan Gray (talk • contribs) 02:34, 1 August 2008 (UTC)

Here's a source: http://www.communitymx.com/content/article.cfm?cid=E4024

As you can see, the orange shadow around the snowflake that contains alpha transparency is ignored in Internet Explorer 5.01, 5.5, and 6. - Akadewboy (talk) 23:34, 2 September 2008 (UTC)

Should there also be something about PNG being the default file format of Fireworks? And how it's able to achieve a bunch of stuff like vector data in what is a bitmap file? --96.53.87.186 (talk) 19:04, 30 May 2013 (UTC)

PNG has higher system requirements than JPG

I've noticed that if many PNG files are displayed on a page it can slow down computers that don't have very good specs. Maybe someone could add to the article that one disadvantage about PNGs is they have higher system requirements and explain why they require more resources. It's probably a combination of they require more RAM and more CPU power to decompress. I'm not an expert, so I can't explain why JPGs run much better on old computers. - Akadewboy (talk) 23:19, 2 September 2008 (UTC)

PNGs don't have higher system requirements than JPGs. Data formats don't have system requirements. What may have system requirements, however, is a particular program that displays and/or manipulates data in a certain format. The speed and memory overhead of processing an image file depends on the quality of the implementation.

May I ask how exactly you were comparing them? This may also have something to do with the results you ended up with. -- Smjg (talk) 00:41, 3 September 2008 (UTC)

The compression in PNG is much less compute-intensive than JPG. What I suspect might be happening is alpha-channel processing, which many computers don't have good hardware or OS support for. GIF and JPG aren't capable of alpha blending, so rendering them can be quicker on those machines/OSs. --LDC (talk) 05:58, 4 September 2008 (UTC)

True, but the only way in which this can have anything to do with Akadewboy's observation is if he's comparing apples and oranges, either directly (a PNG with an alpha channel against a JPG without) or indirectly (using a naive PNG implementation that processes an alpha channel even if there isn't one). -- Smjg (talk) 18:53, 5 September 2008 (UTC)

All I know is that I had a computer from the 90s (with WinXP), I set up a mall webpage with lots of PNGs on the page. When I tried to scroll up or down in the browser it wasn't scrolling smoothly. After I converted all the PNGs to JPG the browser scrolled up and down perfectly. This led me to beleive that having multiple PNG images requires more CPU processing power than multiple JPG images and slowed my system down which made the browser scrolling not smooth. Each image wasn't very large in dimension (only 256x224)and had a small filesize, they were just many small screenshots of NES/SNES games (taken with an emulator). None of the PNGs had alpha. Maybe it was something else that caused the unsmooth scrolling, but that would be a big coincidence. - Akadewboy (talk) 08:51, 10 September 2008 (UTC)

There are a lot of potential factors coming into play there. The web browser used would probably be the most important. After that, I'd consider the size of the JPGs and the internal colour type of the PNGs. The browser may have been having to do alpha blending because it couldn't tell that the image was fully opaque, or because it treated all PNGs as having an alpha channel. CountingPine (talk) 10:12, 10 September 2008 (UTC)

Akadewboy, I suppose the question is: Are you sure the PNGs had no alpha channel, as opposed to an alpha channel that's set to full opacity everywhere? Other things to check are:

• that there is no tRNS chunk, which also specifies alpha values (for indexed-colour) or a single transparent colour (greyscale or truecolour)
• that the number of bits per sample is no more than 8

Do you still have the webpage, or at least the PNGs you used? Being able to examine them might help.

Since you suggest that it could've been something else that caused the unsmooth scrolling - did you try creating a version of the page using the same images as JPGs? That would've been necessary for the nearest you can get to a fair comparison. -- Smjg (talk) 11:04, 10 September 2008 (UTC)

Naming conventions for image file formats

Please see the discussion at Talk:Image file formats#Naming_conventions_for_image_file_formats on naming conventions for articles on image file formats. Dcoetzee 00:47, 25 October 2008 (UTC)

Comparison with JPG image

It would be better to use an image that does not contain anti-aliased fonts, as, for the viewer who does not know about aliasing, that will look a lot like JPG artifacts, thus lessening the message of the image. An image with crisp, sharp content would show the artifacts much clearer. 217.31.178.94 (talk) 10:32, 25 January 2009 (UTC)

Feel free to replace the image with a better one. Plugwash (talk) 02:46, 29 March 2009 (UTC)

Interlace passes are not compressed separately

I removed two words to contrary effect the other day; I have just found the misstatement in two more places. I've always interpreted the PNG spec to the effect that IDAT is a single compressed datastream, and have just found these paragraphs in the spec: [4]

"In a PNG file, the concatenation of the contents of all the IDAT chunks makes up a zlib datastream as specified above. This datastream decompresses to filtered image data as described elsewhere in this document."

"In the same vein, there is no required correlation between the structure of the image data (i.e., scanline boundaries) and deflate block boundaries or IDAT chunk boundaries. The complete image data is represented by a single zlib datastream that is stored in some number of IDAT chunks; a decoder that assumes any more than this is incorrect. (Of course, some encoder implementations may emit files in which some of these structures are indeed related. But decoders cannot rely on this.)"

True, there's an error given that scanline boundaries aren't the only aspect of the image data's structure – needless to say, interlace passes are another example.

Moreover, I have myself written a PNG encoder with working interlacing, and it compresses the whole of the image data in one go. I somehow think this speaks for itself.... -- Smjg (talk) 23:15, 25 April 2009 (UTC)

I don't follow the meaning of your comment. The PNG specification states that the image data can span IDAT chunks and the IDAT chunks do not correspond to boundaries in the image data. The IDAT chunks are actually designed to relate to network packets. The idea is you filter the image, zlib compress it, then send it across the network in a series of packet sized chunks. PNG is almost always transfered as a file, so separate IDAT chunks are rarely used. However, you can't just assume a PNG is one IDAT chunk, in fact the specification explicity states that is incorrect.

83.216.149.7 (talk) 13:56, 8 December 2011 (UTC)

A previous version of the article claimed that the seven passes that make up an interlaced PNG image are "filtered and compressed separately". I was just explaining that this statement is wrong. While the interlaced and filtered datastream may be split into blocks for compression, and the compressed datastream split up for storage in multiple IDAT chunks, the point I was making is that the boundaries of these blocks are arbitrary, not (as some earlier editor seemed to believe) related to interlace passes. — Smjg (talk) 23:01, 5 September 2012 (UTC)

I understood that compression did not continue between interlace passes too. In the sense that you would not find a LZ77 compression code which spans two passes. Not in the senses that of interlace passes relating to IDAT chunks. However I'm not 100% certain. 87.115.162.55 (talk) 19:03, 15 February 2013 (UTC)

LZ77 is just a way in which an arbitrary string of bytes may be compressed. It doesn't care about what the string of bytes represents or how it is structured. The same goes for deflate, which is PNG's compression scheme. It's up to the encoder writer to either generate the entire pre-compressed image data as a single byte string and call the deflate code once on that, generate and deflate each interlace pass separately, or break it up in some other way. Each way, it's equally a valid PNG file, so decoders need to be able to handle all three cases. — Smjg (talk) 15:01, 6 April 2013 (UTC)

Isn't JPEG losless at Maximum Quality?

I'm not sure, but I'm pretty sure that a JPEG saved at Maximum Quality in Photoshjop does not have any loss, therefore there is not a corruption every time you save it. I think this is a common misconception about jpegs saved at maximum quality in Photoshop, which I think is 'lossless'. Loss only occurs if you save at a lesser quality than 'Maxiumum' Does anyone know for sure about this. In which case PNG is almost never better than a jpeg unless you want a transparent background. ? — Preceding unsigned comment added by 24.63.55.210 (talk) 17:00, 20 September 2009 (UTC)

No, ordinary JPEG, even at maximum quality, is always lossy. This doesn't necessarily mean that you will be able to see the difference from original, it means that it isn't possible to reconstruct the original image precisely (bit by bit). There is also lossless JPEG, but this format is almost never used. Svick (talk) 17:29, 20 September 2009 (UTC)

Correct: The loss is insignificant, and even that would only be if you are not working it as a PSD (ie. never open the jpeg to work on), just work on the PSD. —Preceding unsigned comment added by 71.233.248.178 (talk) , 24 July 2010, 12:12 UTC

The loss may or may not be insignificant, depending on your software: some programs give little choice in the quality setting when saving JPG files, and the highest quality setting offered may still introduce noticeable differences. As suggested above, save intermediate edits in a lossless format like PNG or TIFF before converting to JPG. -- Elphion (talk) 20:37, 24 July 2010 (UTC)

Merge from OptiPNG

Recently OptiPNG was considered for deletion, with no consensus emerging. When that result was challenged at deletion review, the suggestion was made repeatedly that the best course of action would be to merge the article (or a summarized version of it) into this article. I am bringing that suggestion here for discussion. Another possibility to consider is a simple redirect, without a merge. Thank you. Chick Bowen 00:49, 23 January 2010 (UTC)

I agree that most of these optimization tools should be discussed together. If you read the paper by the author of OptiPNG, which is a very good source for technical info on the optimization issue, you'll see that the techniques employed by these programs are generally the same. Another good source is the chapter in Sayood's book cited in pngcrush#References. I'll add more technical details if others don't do it first. I don't have a lot of time to dedicate to this lately, mainly thanks to the threatened Great Purge of biographies that has to be dealt with at WT:COMPSCI and elsewhere. Pcap ping 06:52, 25 January 2010 (UTC)

Thanks. It's now been redirected by User:Stormie. The history is still under the redirect if more is needed, including the refs that were in the old article. Chick Bowen 20:27, 25 January 2010 (UTC)

Mentioning OptiPNG, related question: How does it fit within the (optimizing) tool list? It doesn't say how it relates to those. I ask because I've used it within IrfanView, but it's not mentioned here. 2600:100C:B25A:3C9B:DD5D:EF41:EDCA:6F79 (talk) 15:01, 17 September 2023 (UTC)

"The PNG acronym is optionally recursive"

The first paragraph currently says: The PNG acronym is optionally recursive, unofficially standing for “PNG's Not GIF”. Well, any acronym is "optionally recursive" for that matter. Who gives a shit? This should be removed.

Since nobody objected to my suggestion, I've removed the sentence. —Preceding unsigned comment added by 92.2.100.126 (talk) 18:41, 26 March 2010 (UTC)

It is a statement of fact which is properly cited. Admittedly, the "optionally recursive" is a little redundant since it is obviously recursive unlike almost all other acronyms. Why would you think all acronyms have a meaningful recursive form? Is it the "optionally" which is causing the problem? It can mean "Portable Network Graphics" or optionally it can mean the recursive "PNG's Not GIF".

I did the rv before seeing your comment, otherwise I would have discussed it first. VMS Mosaic (talk) 03:04, 27 March 2010 (UTC)

The citation is from some guy's website. What significance does it have that some guy made a website and decided on a whim that "PNG's Not GIF" was a neat alternative expansion of PNG? That makes it an interesting and noteworthy thing to mention in the introduction to an encyclopedia article, does it? There's no sense of "officialness" in the cited page, so why should any credence be given to the idea that people are going around all over the place thinking of PNG as standing for anything other than what it actually stands for?

Additionally, clearly all acronyms have an optional recursive form. I bet I can make up a "meaningful" "optional" recursive expansion for any acronym you want to give me. None of them would be noteworthy of course, because they'd be made up by some shmuck on the internet, like this one is.

ATM: ATMs Tender Money

HTML: HTML Tells Me Lots

IRS: IRS's Really Stupid 92.2.100.126 (talk) 15:14, 27 March 2010 (UTC)

The official PNG web site as defined in the official W3C PNG specification officially defines the PNG acronym as unofficially standing for "PNG's Not GIF". Yes, the cite should actually be the same as cite #1. I didn't do the citing and don't know why a second less authorative source was used other than to have as many sources as possible. If needed, I will change the cite. VMS Mosaic (talk) 20:45, 27 March 2010 (UTC)

OK I guess, in that case it's more defensible. You better had change the citation because I don't know how. 92.2.100.126 (talk) 15:30, 28 March 2010 (UTC)

Alternatives for lossless storage of photographic images

This section needs some work:

JPEG is a worse choice for storing images that require further editing as it suffers from generation loss, whereas lossless formats do not. Since PNG's extreme inefficiency in compressing photographs makes it not useful for saving temporary photographs that require successive editing, the usual choice is a loss-less compression format designed for photographic images, such as lossless JPEG 2000, or Adobe DNG (Digital negative). When the photograph is ready to be distributed, it can then be saved as a JPEG, and this limits the information loss to just one generation. Furthermore, PNG does not provide a standard means of embedding Exif image data from sources such as digital cameras, which makes it problematic for use amongst photographers, especially professionals. TIFF, JPEG 2000, and DNG do support such meta data.

Okay, the first thing about this is that PNG is in the mid-range of efficiency at lossless compression of photographic images. It is only compared to a lossy method such as JPEG that it appears to be extremely inefficient. JPEG-2000 is a very good format for lossless compression of photographic images, but as far as I'm aware it isn't used that much. Adobe DNG isn't really a lossless compression format, but is used for storing RAW images in a cross-compatible format. For a typical digital camera, the RAW images themselves have less bits per pixel (only one color per pixel, and usually something around 12 bits), so keeping it in RAW format makes the image smaller. But anyway, it needs to mention that Adobe DNG is only applicable to RAW photographic images, and isn't for general image editing, although I believe you can make general modifications to the color temperature and stuff.

Now, the reason that they don't typically use PNG for storing temporary images used in image editing is not because it doesn't compress well, but because it doesn't have features to store all the image editing data, such as multiple layers, effect layers, vector graphics, the settings for these layers, and so on. Also, it only works with RGB color, not CMYK (used for printing) or Adobe RGB. As far as I know, most of the special formats used to store image editing work such as PSD are actually poorly compressed compared to best-compression PNG, or not compressed at all.

Oh, and about JPEG-LS -- I think it's pretty cool, and in general it's better for lossless compression of photographic images than PNG, around the same level as JPEG-2000. But there's hardly any application support for the format. Also, it should not simply be called "near-lossless", since that is only one of its two modes of compressing the files, the other being lossless compression.

I've spent so much time typing this I don't feel like editing the article myself anymore. Bleh. Clarphimous (talk) 20:28, 17 May 2010 (UTC)

Just some notes:

• PNG is not "extremely inefficient" compared to lossless JPEG2000; with proper use of prediction filters, PNG provides comparable compression of photographic images and significantly outperforms JPEG2000 on plain graphics.
• In fact, PNG can work with the Adobe RGB (as well as with any other RGB color space), that's what the iCCP and cHRM chunks were introduced for.

Ippopotamus (talk) 11:52, 18 May 2010 (UTC)

• Oh, and PNG can actually store extra data (layers, vector graphics, etc.) in user-defined chunks; those PNG's produced by Fireworks lead people to common misconception that PNG images can contain layers. — Ippopotamus (talk) 12:03, 18 May 2010 (UTC)

I edited this section for impartiality based on comments in this discussion. Editing is what Wikipedia is all about.

83.216.149.7 (talk) 13:40, 8 December 2011 (UTC)

Higher bit depths

Are there any plans for PNG to support higher bit depths (like 16 bits per channel or Floating Point)? --70.167.58.6 (talk) 14:57, 5 October 2010 (UTC)

16 bpc are already there. — Ippopotamus (talk) 21:17, 5 October 2010 (UTC)

16 bpc was there from the start and any compliant decoder is supposed to be able to read it. I doubt floating point would be added in the forseable future firstly because adding a new format would break the idea that any png should be readable by any png decoder (which is a major advantage of png over say tiff) and secondly because I don't think there is demand for it outside of niche markets. Plugwash (talk) 16:41, 6 October 2010 (UTC)

I can't see what practical use there would be for floating-point RGB/greyscale values. Moreover, floating point formats are platform-dependent. Conversion between the platform's FP format and whichever the PNG group decides to use would be both a performance hit and potentially lossy. This is already part of why we have flexible gamma, and why PNG uses floating points only in some ancillary chunks – where they are stored in a platform-neutral ASCII notation. — Smjg (talk) 11:23, 11 April 2011 (UTC)

Not for print graphics?

"PNG was designed for transferring images on the Internet, not for print graphics, and therefore does not support non-RGB color spaces such as CMYK."

designed for transferring images on the Internet

Agreed.

not for print graphics

What evidence is there of this? It contradicts my intuition, that being able to reproduce images accurately in printed works is part of portability and so something the PNG group would have aimed for. Moreover, ISTM the point of the pHYs chunk relates to print graphics.

therefore does not support non-RGB color spaces

It's true that PNG doesn't support non-RGB colour spaces, but not for that reason. To quote the rationale section of the PNG spec:

"There is no support for CMYK (Cyan, Magenta, Yellow, blacK) or other unusual color spaces. Again, this is in the name of promoting portability. CMYK, in particular, is far too device-dependent to be useful as a portable image representation."

In other words, the reason PNG doesn't support CMYK is that it isn't portable. It is expected that, when printing graphics, the printing hardware or software transforms the RGB colour space specified for the image to the device's CMYK space, thereby enabling the image to appear consistently across different printers. This objective would be much more difficult to achieve if the image were stored in CMYK in the first place.

-- Smjg (talk) 17:30, 21 November 2010 (UTC)

Yes, CMYK is device dependent. But so is RGB. Color accuracy in either system requires color management, typically with ICC profiles. CMYK + color managemeent is just as portable as RGB + color management, and gives more precise color since it's a larger color space. PNG's lack of support for CMYK severely restricts it as a format for print media, which use CMYK almost exclusively. PNG doesn't support CMYK for the reason mentioned in the article: the primary purpose of PNG is the transfer of *Network* images, which are almost entirely in some version of RGB. -- Elphion (talk) 18:13, 21 November 2010 (UTC)

Added: The pHYs chunk is not specific to printing: it simply describes the pixel aspect ratio and intended size of the source image. If the output device (whether monitor or printer) has a different pixel aspect ratio, or pixels of a significantly different size, it would have to resize the image to reproduce the intended appearance. -- Elphion (talk) 20:05, 21 November 2010 (UTC)

The beginning of what you say is true, but you miss the whole point of what I'm saying. The point of the spec statement is presumably that CMYK colour management is considerably more complicated than RGB colour management. As such, it is probably simpler to have the images transported in RGB and converted to the particular device's CMYK locally than to transport them in some variety of CMYK and have to convert that to a particular device's CMYK. The whole point of PNG's colour management is to enable images to render consistently, or as near to consistently as possible, on a wide variety of devices. Adding CMYK support to PNG would do nothing to further this aim. Besides, I was taught that CMYK's gamut is actually smaller than RGB's. -- Smjg (talk) 21:35, 21 November 2010 (UTC)

No, I'm not missing the point of what you're saying. The workflow you describe (keep all information in RGB and convert to CMYK at the printer) works fine for monitor-based images, but not for professional-quality printing. And it's not necessary, or even necessarily simpler to do it that way. Color management via ICC profiles is a standard procedure; it makes no difference whether the source or target space is RGB or CMYK. Managing CMYK is not "considerably more difficult". The designers of PNG chose not to support CMYK, so the print industry will continue to use TIFF files to transport information aimed at quality printers. Re gamuts: The size of the gamut depends on the coordinates of the device's primaries. CMYK devices typically do have smaller gamuts -- but the space is larger (denser), being 4-dimensional rather than 3-dimensional. A CMYK image converted to RGB loses color information. -- Elphion (talk) 23:22, 21 November 2010 (UTC)

True, CMYK is 4-dimensional, but this is part of how colours are specified and inks are mixed, and not an actual extra dimension in the perceptual colour space. (Of course, if you're printing for mantis shrimps, it's another matter....) Besides, any RGB or CMYK space is a continuum - what may vary between formats and images, however, is the resolution with which a point in this continuum is specified.

Maybe knowing this will help: What bit depth does the professional printing industry use? How does it deal with potential loss of quality when converting between different CMYK profiles? -- Smjg (talk) 13:29, 22 November 2010 (UTC)

The difference is not one of quantization. (Most print workflows use 8, 12, or 16 bits per channel, which in theory PNG can handle.) The "added dimension" in CMYK deals with an issue that is specific to the subtractive model: do you darken a color by adding C+M+Y or by adding K -- or by some combination of both? In theory, setting C = M = Y yields "gray" -- but in practice, it's a different gray than K yields by itself. There are whole ranges of colors that differ in how they are darkened with differing combinations of C,M,Y and K -- perceptibly different colors that all map to the same RGB color. The richness of a printed image can be entirely lost in a monitor version of the same image (one reason that monitor images of paintings often fall flat). Similarly, effects on a monitor often don't translate well to print: the sunset sky that fairly glows in your digital photo on the screen may just look muddy when printed. In short, RGB works well for monitor images, but lacks the required subtlety for printing. Sophisticated printing workflows that adjust the CMYK for various reasons before the image reaches the printer cannot rely on RGB, and therefore won't use PNG. -- Elphion (talk) 14:39, 22 November 2010 (UTC)

So professional printing makes use of being able to specify the same colour (point in, say, the CIE 1931 colour space) in multiple ways. Can you give an example of a practical use of this? Or does the optimum CMYK combination for a given colour need to be found by hand?

The average user would probably work with images that originated in RGB or one of its derivatives (e.g. YCbCr in JPEGs). So I suppose what's really meant is that PNG isn't meant for professional quality print graphics. Maybe someone'll invent some PPG (Portable Print Graphics) format, like PNG but which works in CMYK.... -- Smjg (talk) 14:18, 23 November 2010 (UTC)

I've updated the article to reflect the lack of support for professional-quality print graphics. I've also removed the tag - feel free to restore if you think it's still needed. twilsonb (talk) 10:26, 17 March 2011 (UTC)

PNG Stereo

PNG Stereo - is this an official format or some hack? It has support in current programs (like this one), but two images side-by-side? That hardly seems well thought out. ▫ JohnnyMrNinja 02:09, 3 February 2011 (UTC)

I'm puzzled by it. Why should a file format specifically designed to hold two images have a concept of them being "encoded side-by-side"? If it's a format that structurally holds two images, they would not have any physical position relative to each other. If it just holds them side by side as if they're one image, it would defeat the whole point of having a separate format. Besides, the official format for storing multiple images in one file is MNG, further suggesting to me that PNG Stereo is a hack. And a totally pointless one at that - PNG is perfectly capable of holding a stereogram as two images side by side. It even has a standard chunk to indicate this. -- Smjg (talk) 14:57, 18 February 2011 (UTC)

Looking at Nvidia 3D Stereo documentation, it appears that a PNS file is just a standard PNG file, and the claim that it's a separate format with a separate filename extension is a marketing gimmick. Moreover, it isn't clear whether a PNS is just a standard PNG stereogram (i.e. has the right-hand image aligned on an 8-pixel boundary and a sTER chunk) or a divergent way of doing the same thing. — Smjg (talk) 20:15, 10 April 2011 (UTC)

At the moment, there's an AfD for PNS and the very similar JPEG Stereo. Please share your thoughts. If it gets replaced by a brief mention here, I can see that it needn't be more than one or two sentences. — Smjg (talk) 11:12, 11 April 2011 (UTC)

.mng example?

Should there be an example of an animated png, such as: http://www.libpng.org/pub/png/img_png/adam7gif.gif  ? I profess near complete ignorance on the subject, and so cannot be bold here, but it seemed like a good idea.Slarty2 (talk) 20:51, 11 April 2011 (UTC)

Wouldn't it make more sense to put the example in Multiple-image Network Graphics? And the specific example you suggest is an animated GIF, not a MNG -- Elphion (talk) 21:05, 11 April 2011 (UTC)

PNG and MNG are distinct formats. There's no such thing officially as an animated PNG. Moreover, MNG isn't widely supported by web browsers, though that doesn't mean we can't add an example there just in case (just as we've been using Ogg for audio since before browsers supported it). Anyway, you might be better off taking this discussion to Talk:Multiple-image Network Graphics. — Smjg (talk) 13:31, 31 October 2011 (UTC)

How to use this shit on wikipedia?

I wanted to update several maps here on wikipedia, which were made in this format. I think there should be a link somewhere on the article page about how to handle it in wikipeida. Is there any easy way i can update a map? — Preceding unsigned comment added by Ilya-42 (talk • contribs) 13:51, 19 July 2011‎ (UTC)

The procedure for updating images on WP doesn't depend on the file format. In a nutshell: Save the full resolution image from your browser, then edit it in your favourite graphics app, then when you're done, use the "Upload a new version of this file" link near the bottom of the image description page. — Smjg (talk) 13:06, 31 October 2011 (UTC)

Papua New Guinea

Perhaps a link to the disambiguation page would be appropriate since png autodirects here. — Preceding unsigned comment added by 132.181.61.215 (talk) 01:20, 20 September 2011 (UTC)

PNG is the disambiguation page. I've changed png to redirect there. -- Elphion (talk) 03:35, 20 September 2011 (UTC)

(added) I have no axe to grind about whether alternatives to "PNG" are mentioned here via hatnote or whether "png" (l.c.) goes to PNG, but clearly people searching for some capitalization variant of "PNG" need to get some indication that there are alternative targets. -- Elphion (talk) 03:40, 20 September 2011 (UTC)

"PNG images render more quickly on the screen than GIF"

I had to look up this source to see what it actually says. On noticing that the source is W3C, I wondered at first whether it actually stated that PNG images on the web display more quickly (because a PNG file is typically smaller than an equivalent GIF file, and so it takes less time to download) but somebody misinterpreted the information to the effect that PNG files generally render more quickly.

But no - this is what W3C says:

"First, PNG images render more quickly on the screen and produce higher quality images. In some instances, PNG images are also smaller than GIF images."

In any case, it would be nice to know how they measured this. Maybe, statistically speaking, inflate decompression (PNG) is computationally cheaper than LZW (GIF) decompression. I don't know. But I'd think it's implementation dependent. A given PNG decoder might be faster, or slower, than a given GIF decoder. To add to the complication, the same image has many different possible PNG encodings; some might take longer to decode than others, and you can't really make a like-for-like comparison with GIF in this respect. So overall, the statement doesn't seem to me to make sense.

OK, so another possible interpretation is that interlaced PNGs take less time to display an initial image than interlaced GIFs, but the source doesn't talk about interlacing. — Smjg (talk) 13:50, 31 October 2011 (UTC)

This bald statement seems very odd in a W3C doc; on the face it looks like partisan PNG pushing. PNG and GIF decoding algorithms for similar images (indexed with same size color table) are very similar. (Encoding is another matter: Deflate is significantly more expensive than LZW, which is why images created on the fly are generally served as GIFs on a high traffic site.) I suspect the interlacing is indeed what they're referring to, since the brief W3C info sheet they link to (http://www.w3.org/Graphics/PNG/) takes time to mention the interlacing specifically as a time-saving device: "PNG also has a novel interlacing scheme which provides a usable graphic faster". But translating that to "renders faster" seems a reach -- and if the image takes advantage of high quality features not available in GIF (which they also tout) the file size may be significantly larger, so that even the interlaced preview may not render faster. I wish people could stop the religious wars; each format has its place. -- Elphion (talk) 15:17, 31 October 2011 (UTC)

Significantly larger than what? OK, obviously larger than it would be without the alpha channel or reduced from truecolour to indexed. It might also be larger than a GIF file of the reduced image. But the PNG image that "takes advantage of high quality features not available in GIF" has no equivalent GIF file, and so isn't really relevant to a file size comparison between PNG and GIF. — Smjg (talk) 13:20, 1 November 2011 (UTC)

Exactly. The claim "PNG has all these neat features that GIF doesn't -- oh, and it loads faster too" is comparing apples and oranges. -- Elphion (talk) 13:57, 1 November 2011 (UTC)

Even the statement "provides a usable graphic faster" is tenuous. What is a usable graphic? Is a quarter resolution graphic usable? PNG provides a different sequence of lower resolution versions to GIF. At the lowest resolution neither PNG or GIF are particularly useful. PNG could take more or less time to display the same amount of visual data as the lowest level of an interlaced GIF, it depends how efficient the compression is for that image.83.216.149.7 (talk) 19:15, 9 December 2011 (UTC)

I removed this statement. It is not accurate because it says the image renders faster, the download time should be considered part of the file size, which is already mentioned. Image file format could only make a difference if PNG and GIF were rendered from compressed data, which almost certainly is never the case. If it was, GIF is a much simpler format and would render faster. The statement also showed bad grammar 'more quickly'.83.216.149.7 (talk) 12:46, 8 December 2011 (UTC)

To clarify the reason for removing this statement. Rendering speed is the measure of the time it takes to put a graphic into the display. Both PNG and GIF will be loaded into an uncompressed form in memory before copying to the display. The time taken to download, load from disk, decompress, or convert to a display compatible format is not rendering time. The statement could say that a smaller PNG file would download faster, although that would apply equally to any file, including GIF. It could have said that an interlaced PNG has to download less data before displaying it's low resolution version.

83.216.149.7 (talk) 13:23, 9 December 2011 (UTC)

Comparison to other file formats

A comparison to BMP should be added.50.103.230.83 (talk) 14:31, 30 January 2012 (UTC)

Also would be nice if PNG were compared to WebP. --96.53.87.186 (talk) 19:02, 30 May 2013 (UTC)

Removed Citation Needed

The original comment here, by 46.208.96.9, was subsequently edited by 81.141.225.236. I don't know whether the same editor was using both IPs. -- Elphion (talk) 17:26, 25 October 2012 (UTC)

Original version by 46.208.96.9 on 13 July 2012:

The first line in the Image editing software section of this article had a citation needed mark. I removed this because it made no sense, it was asking for a citation of the obvious. All PNG files are compressed with the same method. If one program saves a PNG file larger than another program then its compression must not be as effective. Apart from storing excess data in the file (as in the Fireworks case) there isn't any other way to make a significant difference to the file size. Can anyone see any reason why this might not be the case? 46.208.96.9 (talk) 20:08, 13 July 2012 (UTC)

Version as edited by 81.141.225.236 on 30 September 2012:

The first line in the Image editing software section of this article had a citation needed mark. I removed this because it made no sense, it was asking for a citation of the obvious.

All PNG files are compressed with the same method. - Unless a different method is used, e.g. MS Paint 5 and MS Paint 6 - which when used interchangeably on the same file prove that PNG is not lossless.

PNG Format specifies the use of ZLIB lossless compression. No other compression method is part of the specification. Using a different method would create PNG files that could not be loaded by other programs. Theoretically a program could incorrectly apply ZLIB compression so that it makes a smaller file and compresses with errors. That would not be 'lossy' compression but's ZLIB compression with errors. Lossy compression (such as in JPEG) always loses data, over the whole image and by design. The statement about efficiency of compression and file size still applies. 87.115.120.124 (talk) 12:23, 26 November 2012 (UTC)

If one program saves a PNG file larger than another program then its compression must not be as effective. Apart from storing excess data in the file (as in the Fireworks case) there isn't any other way to make a significant difference to the file size. Can anyone see any reason why this might not be the case? 46.208.96.9 (talk) 20:08, 13 July 2012 (UTC)

81.141.225.236 subsequently edited the lead to suggest that PNG compression is not lossless, which prompted my comment in the section Lossless Compression below. -- Elphion (talk) 17:26, 25 October 2012 (UTC)

Lossless compression

81.141.225.236 (talk · contribs · WHOIS) has twice edited the lead to insist that the compression method used by PNG is not lossless. This is nonsense, and completely contradicts the point of PNG. PNG uses DEFLATE, a well-known algorithm that is in fact lossless (it is commonly used in zip programs for text files as well). The added material about MS Paint may or may not be true (it would require an authoritative source), but even if true, it does not address the losslessness of DEFLATE or PNG, but rather flaws in how MS Paint handles images. (And in any event, it does not belong in the lead.) -- Elphion (talk) 12:44, 30 September 2012 (UTC)

EXIF & JPEG 2000

It states the JPEG 2000 can contain EXIF data, but if you go to the EXIF page on Wikipedia it says that it's not supported with JPEG 2000. Which is it? — Preceding unsigned comment added by 67.141.250.181 (talk) 22:41, 17 December 2012 (UTC)

Can we Embed TEXT Comments in our pictures too?

JPG allows us to edit & embed several paragraphs (4+kB) of descriptive plain text comments in our pictures. (Such as with Irfanview picture viewer/editor, ——under Information > Comment.) Can PNG do that?
    I see three notations mentioning text as "textual metadata," under "Ancillary chunks." I have no idea what they imply. Metadata usually implies it's for software reading, not human editing. Here too? Please clarify that section, it seems too technical or vague. Thanks!
--67.125.107.234 (talk) 17:30, 18 February 2013 (UTC)Doug Bashford

Update; 18 February. I found more info at http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html
"4.2.3. Textual information The iTXt, tEXt, and zTXt chunks are used for conveying textual information associated with the image. This specification refers to them generically as "text chunks"."
4.2.3.1. tEXt Textual data ...looks very promising in this regard. But by not giving examples of the concepts, one must know the precise meaning of that jargon, —I don't. Wazup? Thanks;
--67.125.107.234 (talk) 19:19, 18 February 2013 (UTC)Doug Bashford

The current spec (I think) is 11 Nov 2003, available at
http://www.libpng.org/pub/png/spec/iso/index-object.html or
http://www.w3.org/TR/2003/REC-PNG-20031110/ (W3C seems very slow today).
The text chunks are covered in section 11.3.4. Basically, you can include compressed or uncompressed text in Latin-1 or UTF-8, but your string must be labeled with one of a list of standard keywords (which includes "Comment"). The formats are all given in the spec. -- Elphion (talk) 20:10, 18 February 2013 (UTC)

Thanks! But libpng.org gives me a headache. Prolly cuz I don't know what or even where the jargon is! No time for that education now. No verbal or image examples to nail down the layers of abstracts!
    We seem to be in agreement, –it seems PNG well could be a "notesworthy" format as in the above JPG-Irfanview example! (Who loves switching from a clean 256 color graph to JPG just cuz they need notes?)

    I saw hints that GIF could also embed viewer-editable notes! Does anybody know for sure, yes or no? (I ask since PNG & GIF are historically joined.)
--67.125.107.234 (talk) 23:30, 18 February 2013 (UTC)Doug Bashford

You may be jumping to conclusions. JPEG and PNG allow comments in the file, but such text is not displayed in the image. Any editor that adds text visible in the image is fiddling with the image data -- the text is rendered as pixels and replaces pixels in the original image. GIF also supports comments in the file, but can also display text in the image by two methods: (1) You can have more than one image in a GIF file, and one of those could be a text overlay (but again as rendered text); and (2) There is a little-used GIF Text Extension that allows you to specify monospaced text to be displayed in the logical screen. (2) is "little-used" because you don't have much control over the font. -- Elphion (talk) 02:56, 19 February 2013 (UTC)

If you are looking for a format that can include things like sharp line drawings or graphs, together with user-editable text, I would suggest a vector format like SVG. -- Elphion (talk) 03:05, 19 February 2013 (UTC)

Thanks for answering my question, and expanding...I was not aware of those other strange features. Sorry I was not clear, indeed I was speaking of adding easy editable notes to the image file, not to the image itself.
  Thanks for the SVG suggestion! But one of my objectives is staying sharable and mainstream with people who (gulp!) almost find Irfanview too challenging & technical.
  Now I intend to request that Irfanview's author add PNG comments and perhaps GIF comments to JPG's in this regard. Frankly I'm baffled & dismayed that more image viewer-editors don't have this useful function. ...Handy prose picture notes that can't be lost——seems so Duh!
--67.125.107.234 (talk) 14:57, 20 February 2013 (UTC)Doug Bashford

UPDATE to 20 Feb: Ooops! Looks like irfanview PNG might support text comments. I found this following its PNG Save AS menu: "03/24/2005: Irfanview 3.97 supports saving with a PNGOUT plugin. Get the latest PNGOUT plugin here." The menu has tons of stuff. Among the "keep chunks" list are "pHYs,iTXt,tEXt,zTXt" and more, plus filter choices, bit depths, color types, and more. Advsys.net says: " featuring an easy-to-use GUI. Supports all features of the command line version (described below), plus more. PNGOUTWin makes it easier to do batch processing and takes full advantage of multi-core CPUs."...blah blah... http://advsys.net/ken/utils.htm#pngout ...by Ken Silverman. I'll install soon! (sheepish grin)
--67.125.107.234 (talk) 17:38, 22 February 2013 (UTC)Doug Bashford

To answer the original question: Yes, PNG does support easily editable text comments, as do both JPG and GIF. The problem is the image viewer. Irfanview (depending on your version) supports easily viewing, adding, changing and removing such comments in JPG files but not in PNG or GIF files. Other image editors may have better or worse support for comments.

One important factor to bear in mind is whether such comments can be changed without affecting the original image data. Even in lossless formats like PNG, some image editors insist on re-writing the image data, which may make the file either more optimal or less optimal than the original. For example, I took what I thought was a well optimized PNG file that was created with Photoshop, added a small comment using an old version of ThumbsPlus, and ended up with a 40% smaller file! Look for the option to losslessly change comments. Ian Fieggen (talk) 00:57, 23 February 2013 (UTC)

Exif data could go into an exIf chunk

The article currently states: The PNG specification does not include a standard for embedded Exif image data from sources such as digital cameras. TIFF, JPEG 2000, and DNG support EXIF data.

It seems surprising that there is no standard "EXIF" chunk. Presumably this reflects the fact that Exif typically originates from digital cameras, for which a JPG file is a better destination container than PNG.

That said, there is nothing preventing an encoder from writing a private "exIf" chunk. Should this be mentioned in the article? Ian Fieggen (talk) 00:09, 7 September 2013 (UTC)

I suppose this is because there are chunks already in PNG for various items of metadata, including some of those in EXIF, and so having an EXIF chunk would be redundant. While a chunk could be defined for those bits of EXIF metadata that don't already have PNG chunks for them and which don't fit into tEXt chunks, this would have to be based on what is in the PNG standard at some arbitrary point in time, and so it would be better to define a separate chunk for each component of EXIF metadata.

JPEG being a better format isn't a valid argument. JPEG is only "better" in terms of file size. Lossless formats such as PNG preserve detail that JPEG throws away, and this is what some photographers want. Indeed, some of the PNG documentation is based on the expectation that it will be used for photographic images. — Smjg (talk) 13:16, 18 December 2013 (UTC)

I've just realised where this statement is in the article - in the "Comparison with JPEG" section. There are a few things wrong with this:

• The list of formats that "support" Exif data is contradictory with the info on Exif.
• Since it refers to formats other than PNG and JPEG, it isn't specifically about PNG vs JPEG and so that section is a strange place in which to put it.
• It makes it sound as though this is an advantage of these formats over PNG, which is a bogus claim because
  • Exif is but one standard for the storage of metadata in graphic files. The wide range of ancillary chunks in the PNG standard is another. Other image formats might have other metadata standards. So rather than claiming that PNG doesn't include a standard for Exif metadata, what we really need is a comparison of metadata standards.
  • The inclusion of certain items of "metadata" can be seen as a disadvantage. For instance, one feature of Exif is the orientation setting, which has compromised the portability of JPEGs, and would do the same for PNG if it were added to it. Other aspects of Exif are also badly designed. As such, it can be considered an advantage that the PNG Working Group didn't choose the Exif standard for storing metadata.

Still, how can we best rewrite this statement in the article? — Smjg (talk) 00:25, 20 December 2013 (UTC)

True that certain EXIF metadata would be duplicated in other dedicated chunks. However, such duplication is common in other file formats. For example, just about every JPG file produced by Photoshop contains duplicate metadata to that contained within the Exif segment.

That said, I agree that the statement should probably be re-written to say something like:

The PNG specification does not include a standard for embedded Exif image data from sources such as digital cameras. Instead, PNG has various dedicated ancillary chunks for storing the metadata that other file formats (such as JPG) would typically store in Exif format.

Ian Fieggen (talk) 01:02, 21 December 2013 (UTC)

I've implemented this rewrite as it's certainly better than what we had, even if not perfect. I've changed "embedded" to "embedding" since it's about how to embed it in a PNG file, rather than the embedded data itself. — Smjg (talk) 22:49, 21 December 2013 (UTC)

More to add about transparency

Which computer programs can an image be pasted as transparent into? Which of them allow a multicolored transparent background to paste as transparent? Which programs can support pixels of an image, such as File:Light cone.svg being pasted as partly transparent? Blackbombchu (talk) 21:03, 5 April 2014 (UTC)

Check out Alpha channel. Enumerating applications that can display alpha channels correctly is beyond the scope of this article. -- Elphion (talk) 22:11, 6 April 2014 (UTC)

PNG tool additions

It is worth linking to PNG tools overview as it seems to cover pretty much all the PNG tools at the time of writing (April 2014). One of the tools mentioned on that page is could also be added here - pngwolf because it uses genetic algorithms to try and search for the best filters (pngwolf can even be seen helping zopfli).

87.112.13.231 (talk) 17:01, 26 April 2014 (UTC)

PNG Decompression Bomb Vulnerabilities

Should the article include anything related to vulnerabilities, such as PNG Decompression Bomb? • Sbmeirow • Talk • 05:57, 26 November 2015 (UTC)

• http://www.aerasec.de/security/advisories/decompression-bomb-vulnerability.html

• http://libpng.sourceforge.net/decompression_bombs.html

• http://www.rubyflow.com/p/48byz4-protect-your-rails-app-from-png-bomb-attacks

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Portable Network Graphics. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://sourceforge.net/mailarchive/message.php?msg_name=3.0.6.32.20070420132821.012dd8e8%40mail.comcast.net

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 23:17, 1 April 2016 (UTC)

Minimal PNG Explanation

The provided contents of a minimal PNG containing a single red pixel does not explain the purpose of each included byte/parameter, nor what the compressed IDAT data decompresses to. For example, the purpose of the bytes 0x08 0xD7 in IDAT does not appear to be stated anywhere on the page. In particular, I attempted to decompress the data in IDAT by hand using the static Huffman code, and extracted the values 0x00 0xFF 0x00 0x00, which makes sense, corresponding to one line with filter type 0 (none), and one literal red pixel (0xFF 0x00 0x00). This decoded data was terminated by the end-of-block signal; however, there were still four more bytes remaining in the content of the IDAT chunk before the CRC with the values 0x03 0x01 0x01 0x00. What are these bytes for?

2601:182:280:C0F0:D9BB:9350:ABFD:196E (talk) 19:22, 18 August 2021 (UTC)