Yow, quite a few misunderstandings and outright errors here. Starting at the bottom:
Erik Karulf, your image got bigger because you destroyed it by saving in JPEG in the first place. That’s what “lossy” means, and the kind of damage JPEG does is very hard on PNG’s compressor. Find the original and compress that instead.
Ozh, the color-mismatch problem in MSIE goes beyond just PNGs; MS happily ignores the gamma- and color-correction aspects of numerous standards, including HTML and CSS. See http://www.libpng.org/pub/png/png-gammatest.html for a basic gamma test and the top of http://www.libpng.org/pub/png/gamma-consistency-test.html for the self-consistency argument.
Powerlord/Josh/rien/etc., neither PNG nor GIF’s compression engine is lossy, but GIF most assuredly is lossy (due to quantization) if you try to save a truecolor (24-bit) image. I suspect that’s what the original poster meant. It’s fully lossless for images with 256 or fewer colors, of course.
John, IE 5.x can display PNGs (as can 4.01+); it just doesn’t handle transparency correctly (GIF-style only; not at all for 32-bit PNGs). There are virtually no browsers in use today that can’t display basic PNGs OK.
Dave C, emacsen, et al.: neither PNG nor GIF (as formats) is copyrighted, nor (if I understand US law correctly) can they be, since they’re not “expressive.” The specs are copyrighted, but that doesn’t stop anyone from implementing the formats according to the specs. GIF was encumbered by the Unisys LZW patent; it may still be encumbered by the IBM LZW patent; and the “GIF” name is a service mark of CompuServe. PNG is believed to be unencumbered by any patents, but you can never make a blanket statement without doing an exhaustive search. I think that covers most of the legal issues…
Guy, there are no current plans (that I’m aware of) to support APNG in libpng. The APNG extension chunks have just come up for discussion (and perhaps a subsequent vote) on the PNG/MNG list.
GrahamStw, make sure you’re comparing 8-bit PNG to (8-bit) GIF. (Eamon Nerbonne made the same point above. Use something like gif2png to convert the GIFs to PNGs before running pngcrush if you want to be sure, or just do
pngcheck *.png to make sure they say “8-bit” and not “24-bit”.) There are a few GIFs that PNG can’t beat–usually either extremely tiny ones or ones with between 17 and 64 colors–but the vast majority are smaller with PNG. Of course, if you’re storing a lot of ancillary crap in there–e.g., large text chunks, full ICC profiles, etc.–then all bets are off. (Use
pngcheck -v *.png to see what’s inside them.)