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)

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)

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)

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)

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)

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

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)