Talk:PNG

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)

• 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)

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" and "PNG output format requires Internet Explorer 4.0 or later", 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. --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)

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: [1]

"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)

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.

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)

"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)