![[PNG icon]](img_png/pnglogo-blk-tiny.png){kind=small}
PNG Frequently Asked Questions
PNG Frequently Asked Questions
A: It didn't! Ever since the first HTML 4.0 drafts came out, the PNG pages were modified so that virtually all of the GIFs most users saw would have been PNGs had their browsers supported the HTML 4.0 OBJECT tag correctly. The basic idea was to wrap an OBJECT PNG around an IMG GIF or JPEG; old browsers would see the GIF or JPEG, but new ones would see the PNG--no broken images for anyone. (After all, the primary purpose of the PNG site was and is to be informative rather than political; in other words, the emphasis has always been on making it useful and functional for everyone, regardless of one's choice of browser.)
Unfortunately, Microsoft, Netscape and most other browser vendors implemented OBJECT so poorly that the tag is still virtually useless for new image types, even as late as mid-2000. Forget about backward compatibility; even current compatibility is abominable! (Notable exceptions include Amaya and Mozilla.) See this page for details about the OBJECT tag and the browsers page for details about individual browser implementations. And please support the Web Standards Project.
A: If there's one concept you should take away from this site, it's Use the best tool for the job. In this case, that happens to be JPEG, which, at 76,563 bytes, is almost seven times smaller than the completely lossless PNG version (515,894 bytes). (Of course, the PNG image is interlaced, which tends to reduce its compression efficiency; non-interlaced, it would be 410,545 bytes, only 5.4 times as large as the JPEG. By contrast, progressive JPEG--which corresponds to PNG interlacing--tends to shrink normal JPEGs, in this case to 71,110 bytes.) See the Basic Introduction for more tips about what to use when, and why.
A: Server-side content negotiation is the most reliable approach and the only one known to work regardless (almost) of the user's choice of browser and browser settings. Apache supports it, albeit not very conveniently; Greg doesn't know about other servers (info welcomed!). The major drawbacks are that you need to duplicate any image that you want to negiotiate (e.g., make a PNG version and a JPEG version); you need access to the server configuration; and there's no standard approach to setting up content negotiation in servers, so every product is likely to be different.
There is no known client-side approach that will work reliably in all or
even in most cases. The HTML 4.0 OBJECT tag was the most promising, but
it failed due to non-spec-compliant implementations (see the previous
question). People have promoted various ActiveX/
A: Aside from the fact that plug-ins (either Netscape-style or Microsoft ActiveX "controls") are platform-specific--that is, you have to supply a separate binary for every operating system and, in some cases, for different browser versions on the same OS--the major drawback is in the implementations. Whether due to a simple oversight on the parts of both Netscape and Microsoft (and all vendors who subsequently cloned either or both plug-in architectures) or intentional design limitations, no one paid attention to the fact that HTML has supported one multimedia type natively since its earliest days: images. Ideally a browser would invoke a given plug-in not only for content referenced via EMBED or OBJECT tags but also for unsupported image types found in the IMG tag.
Since no one made the obvious connection, designers are therefore forced to write content either for use only with plug-ins (via OBJECT or EMBED) or for use only with PNG-supporting browsers (via IMG). Most have given up and simply support the IMG tag, which remains the most backward-compatible approach despite the lack of PNG support in pre-1998 browsers. (Indeed, most plug-in authors have also given up; very few PNG plug-ins are still available.)
Note that plug-ins have other drawbacks, too. Transparency, which is one of PNG's most desirable features, was impossible with the first generation of Netscape's plug-in architecture--which is still the current generation for Unix implementations. The second generation supports transparency via something called "windowless plug-ins," but only one PNG plug-in ever supported that (version 2.0 of Siegel & Gale's PNG Live for Windows), and it was never completed. Microsoft's ActiveX architecture may support transparency, but no PNG control ever has. Even worse, Microsoft apparently insists on placing a fat, opaque border around images displayed that way, at least when referenced via OBJECT tags; and with browser preferences set for relatively high security, every web page with such an image will generate a warning box, even when returning to a previously approved page via the Back button.
A: There are two main reasons behind this phenomenon: comparing apples and oranges (that is, not comparing the same image types), and using bad tools.
A common user mistake is to start with a truecolor image, save it in both PNG and GIF format, and then compare. Unlike GIF, which supports only colormapped (paletted) images, PNG supports both colormapped and truecolor images--and not just at 24 bits; the latter can be 48 bits, too. Because of this, when saving a truecolor (24-bit) image as a GIF, most tools will happily throw away color information in order to squeeze the image down to 8 bits (the largest possible palette size). But with PNGs, there's no need to be so brutal; tools almost invariably save such images in their full 24-bit glory. PNG's compression engine may be efficient, but there's no possible way it can make up for the initial factor-of-three handicap. To do a fair test, save as GIF first, then open that image and save it as a PNG. Now the PNG will be (or should be) the same bit depth as the GIF, and in most cases it will be noticeably smaller.
The other reason is more of a developer issue, although users should be aware of it. PNG provides a lot of flexibility in tuning the compression level of an image, from trimming the color and transparency palettes to choosing the precise combination of pre-compression filters to choosing the proper settings for the compression engine itself. (GIF, on the other hand, is practically deterministic; aside from rearranging the order of the palette--an extremely time-consuming and rare optimization--or turning off compression altogether, you get pretty much the same results regardless of the tool you use.) Not all tools do a good job of compressing PNG images, and in extreme cases the difference can be as large as a factor of two. Photoshop has traditionally been the poster child for poor PNG implementations, but in fairness, recent releases have also included ImageReady, an optimizer that does a better job. See the basic introduction and and image editors pages for details. For serious (yet completely lossless) compression, check out pngcrush, pngrewrite, PNGOUT, and OptiPNG on the image converters page.
A side note: for all practical purposes, PNG is never smaller than JPEG for photographic images. On the other hand, for buttons and simple graphics with relatively few colors, PNG usually is smaller than JPEG. Use the right tool for the job! Again, see the basic introduction for details.
A: The PNG image format was designed in 1995 specifically in response to the patent problems with the LZW algorithm used in GIF. To the best of the PNG group's knowledge, PNG was then--and still is--completely patent-free.
However, the fact that is possible to implement PNG without infringing any known patents certainly does not imply that it is impossible to implement it in a manner that does infringe one or more patents. Patents are a minefield, and several are known to be closely related to PNG technologies:
In each case, it is possible to work around the patent and thereby avoid infringement, which is what has been done in all known PNG implementations.
Of course, Greg is not a lawyer, and this is not legal advice, merely (reasonably) informed technical opinion based on the informed technical opinions of others. The only guarantees in patent law come after court battles--and those are the tool of last resort. Nothing here has ever been tested that way, so consult a lawyer, and use your own best judgment.
A: The simplest way is to use an appropriate image editor with support for PNG transparency. Greg gave specific recipes for doing this with Photoshop, ImageReady, Paint Shop Pro, and The GIMP in Chapter 4 of PNG: The Definitive Guide, and for Fireworks in Chapter 1, but the basic approach is the same for every image editor that uses layers.
A: The answer is either "it does" or "because it's a bad idea," depending on your perspective.
The animation-supporting version of PNG is called MNG, for Multiple-image Network Graphics. For most practical purposes, MNG is PNG, just with a different filename extension, a slightly different file signature, and the bare minimum of internal changes necessary to support animations (and other forms of multi-image files). It has exactly the same chunk structure as PNG and even shares most of the same chunks; the major difference is the addition of new chunk types to support features such as looping, clipping, and so on.
The majority of the PNG developers felt (and still feel) that overloading a single file type with both still and animation features is a bad design, both for users (who have no simple way of determining to which class a given image file belongs) and for web servers (which should use the image/foo MIME type for stills and video/foo for animations--GIF notwithstanding). Programmers who simply must think of stills and animations as the same thing are free to do so internally; MNG is the proper superset, and a single PNG image wrapped in a few dozen bytes of MNG headers is a completely valid MNG stream. (Of course, an unadorned PNG image is also defined to be a valid MNG stream, but let us not quibble...)
A: PNG8 is shorthand for "8-bit PNG," but more generally it refers to palette-based (colormapped) PNG images with 1-, 2-, 4- or 8-bit pixels. That is, each pixel value in the image itself is 8 (or fewer) bits deep, and it acts as an index to a particular 24-bit RGB color value in the palette. A 1-bit colormapped image can refer to no more than two colors; a 2-bit image can have no more than four; a 4-bit image can have no more than 16; and an 8-bit image can have up to 256 colors. (Note that, unlike GIF, PNG palettes can have any number of entries--at least, up to the maximum allowed by the bit depth--not just powers of two.)
PNG24, on the other hand, is shorthand for "24-bit PNG" and refers to truecolor or RGB (red/green/blue) images. Each pixel in such images is 24 bits (3 bytes) deep and directly specifies a color instead of acting as an index into a lookup table of colors (i.e., a palette). These images thus can contain up to 16.8 million colors, although typical ones tend to use no more than 50,000 or so.
Note that PNG supports a third basic image type, grayscale, which is usually limited to 8-bit (or smaller) depth but, like truecolor, requires no palette. Not all tools support writing true grayscale images but instead write colormapped PNGs with all-gray palettes. (This can sometimes be beneficial--if only a few, unevenly-spaced gray shades are used--but more often it simply adds 780 bytes to the image size for no good reason.)
Also note that both grayscale and RGB PNGs can have 16-bit samples--that is, 16-bit and 48-bit pixels, respectively--and both can also have an alpha channel for transparency information. Thus an 8-bit grayscale image or a 24-bit RGB image may contain an 8-bit alpha channel, for a total of 16 or 32 bits per pixel; while a 16-bit grayscale image or a 48-bit RGB image may contain a 16-bit alpha channel, for a total of 32 or 64 bits per pixel. However, when tools occasionally mention PNG32, they are invariably referring to 32-bit RGB+alpha (RGBA), not 32-bit gray+alpha. (Few tools support both reading and writing of images with 16-bit samples; such images are typically used only in science, medicine, and the film industry.)
A: You need to recompile gd, too. Here's the typical error message:
# webalizer -c /foo/webalizer.conf
libpng warning: Application was compiled with png.h from libpng-1.0.8
libpng warning: Application is running with png.c from libpng-1.2.1
gd-png: fatal libpng error: Incompatible libpng version in application and library
Segmentation fault (core dumped)
#
So the installed version of libpng (header files and shared library) in this example is 1.2.1--which presumably is also what your half of the app (e.g., Webalizer) was compiled with. But the gd library on which your app also depends was compiled with libpng 1.0.8. Recompile gd and all will be well--at least with this application.
This is a general limitation (or "feature") of Unix-style shared libraries: in order to simplify the link command for application developers, library developers often build shared libraries with implicit links to other shared libraries. Thus one can link with something like Imlib by (say) using only the -limlib link option, despite the fact that it actually has dependencies on more than a dozen other GTK+, Glib, X, and image/compression libraries. Problems arise when both the application itself and one of its libraries link with the same lower-level library (such as libpng or zlib); if the latter gets updated, both the application and the higher-level library or libraries may need to be recompiled.
A: There is! Gerard Juyn wrote a free libmng implementation, and as of June 2000, it is very nearly feature-complete. It has been used to create both a MNG plug-in and native MNG support in Mozilla, and it's used by a number of other toolkits and applications, including Qt. Even better, libmng includes native JNG and PNG support, too. It requires zlib and (for JNG support) libjpeg, but not libpng.
A: This appears to be a widespread but not universal problem (Greg was never able to reproduce it) that most often affects Windows versions but can also occur on Mac OS. It may actually have more than one cause.
For Windows, by far the simplest approach is to use regsvr32 to re-register IE's internal PNG support, as passed along by Michael Wexler (possibly based on a posting by ARodriguez on 16 June 2001):
I couldn't see .png files in IE 5.5 even with SP1 installed on Windows ME. Then, thanks to Usenet (through Google), I found the magic step:
Start -> Run... -> regsvr32 c:\windows\system32\pngfilt.dll (and click OK)This re-registers the primary png viewer for IE. Why did I have to do this? Got me. Gotta love Windows. Anyway, 10 seconds later, I could view entire test suites. Wonderful and easy solution.
Note: this entry previously referred to c:\windows\system, a location that appears to have worked for at least two people. Travis Head reports that pngfilt.dll lives in c:\windows\system32 on his systems; this matches the location mentioned in ARodriguez's posting. Check both directories if necessary!
Another fix that has worked in some cases--but not for Michael--is to install Service Pack 1 (SP1) for Windows MSIE 5.5. (Thanks to Everett Starkweather for the tip.)
Yet another possibility, which may apply to earlier versions of Internet Explorer (such as 5.0 and possibly even 4.0), was posted to comp.graphics.misc by Andrej Kluge on 1 June 2000:
For IE5 (Win95, probably the same for W98):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Accepted Documents
Note that the regedit approach is known not to work in some cases, but it may be useful if a plug-in (such as QuickTime?) has modified the registry.
The QuickTime problem is known to have affected at least one Macintosh user running MSIE 5.2 on Mac OS X 10.3. For some reason his system would fail to display PNG images (despite QT's PNG support) but instead would pop up the "select a viewing application or save to disk" box that's associated with unknown media types. (The QT failure may be due to the browser's failure to invoke plugins for the IMG tag, which is a failing that is not unique to Microsoft.) Alain reported:
So I went back to explorer and had a look at what application was by default opening the png file (I don't know what it is in English but in Spanish it is in Preferencias -> Complementos de Archivos).
(Presumably the English version is Preferences -> File Associations, or something close to that.)
There I saw that Quicktime was set to open the png file. So I just deleted this preference, and now when I go back to the site it does let me see the png image. I have Quicktime 6.5.2 installed.
Quite possibly the same approach would work in many cases with Windows versions of the browser; it has the great advantage of not requiring any obscure registry hacks.
A: This problem, which reportedly can be caused by Macromedia's Fireworks 4, is easily fixed. From the Start menu, select Run... and then type:
regsvr32 thumbvw
This will restore the missing registry entries. (Thanks to David Candy for this info.)
A: This problem appears to have been triggered by an update to Windows XP SP2 in at least one case. Ken Stewart-Smith reports that one of the symptoms is the following error message when trying to save a PNG image:
Cannot save image. Image format filter initialization failed.
Cannot write image. The disk may be full or write-protected or there may be insufficient memory.
Attempts to open previously created PNGs also fail. Ken discovered a fix in the form of the Microsoft Office File Converter Pack (a.k.a. OCONVPCK.EXE), a freely downloadable add-on for Microsoft Office 97 through Microsoft Office 2003 on Windows 98/2000/2003/XP:
As soon as I ran the fix, I was able to read and write my png files again.
(Thanks to Ken for the tip.)
A: Newer versions of Microsoft Office apparently are strongly dependent on features of the printer driver in order to print embedded PNG images (particularly those with tranparency) correctly. For example, it was reported that Microsoft Office XP printing to a Brother HL-1250 either would fail to print embedded PNGs or else would print them with a black background instead of white, whereas printing the same document from the same machine to an HP Business Inkjet 1100 "worked perfectly."
In short, try using a different printer, and if that's not an option, check with the printer manufacturer (or maybe Microsoft) for updated Windows printer drivers.
Alternatively, if installing OpenOffice is an option, try that; a reader in Germany reported being unable to print PNGs on any of four Epson printers using MS Office but was able to print on all of them using OpenOffice.org.
A: Similar reports began showing up in early November 2002, and as of June 2003, the problem still isn't completely characterized. At least three people have implicated Kazaa; two of them downloaded Spice Girls images. It is also possible that malicious code is involved. (See the 11 December 2002 news entry for details, but note that so far there is no direct evidence linking the two problems. See also this site for other users' experience.) Michael Brown also noted that Windows Explorer can get wedged while trying to [pre]view certain images, which renders it incapable both of deleting them and of performing various other tasks; it remains stuck until killed, although Mozilla works fine on such images.
For now, it appears that the surest way to get rid of the offending image is to note where it is (i.e., in which directory or folder), shut down to DOS (or boot from a DOS floppy), change to that directory, and use the DOS DEL command to remove the file. (Booting from a Linux floppy, such as Tom's Root/Boot Disk, should also work as long as the filesystem isn't NTFS, but non-Linux users will find this approach considerably more complex.)
Garvey Butler reports that using regular Windows Explorer (which, on his Windows 98se machine, doesn't display image thumbnails) to delete the images works for him. Newer versions of Windows may require the image-preview feature to be shut off altogether. In Windows 2000 it appears that this can be done from Explorer as follows:
Tools -> Folder Options... -> General tab -> Enable Web content in folders
(and uncheck the checkbox to disable it)
For Windows XP it may be necessary to modify the registry as described on this page. (Note that modifying the registry can mess up Windows in a big way if you make a mistake!) Most registry modifications require a reboot to take effect.
Richard Bytheway noted that Windows locks image files while generating the thumbnails, which can be quite slow if the images are large (he mentioned 500 MB). This is unlikely to be the problem with downloaded Spice Girls images, but users with slow machines might see some delays. Again, turning off image preview avoids the problem.
Finally, one other user reported that his problem-image was removable after he uninstalled Photoshop 7.0. (Your mileage may vary!)
If you have further information, feel free to let Greg know, but please don't ask him for details; everything he knows is right here already, and in general, if it doesn't involve Linux, he doesn't do it.
Here are some related PNG pages at this site:
![[PNG icon]](img_png/png-tiny.png){kind=small}
Introduction to PNG features
Current Status of PNG
History of PNG
PNG Technical Documentation
PNG: The Definitive Guide and Related
Books
PNG Home Page
Complete PNG Site Map
Copyright © 2000-2009 Greg Roelofs.