Posted by member 45783 on 2003-07-10 04:39:15 link
When thinking compression, you must think of how much true "information" the image has.
JPEG compression creates noise in the image and PNG compression is a true compression (such as ZIP, RAR or the LZW used on GIF), not a lossy one (JPG).
PNG cannot throw details away and proceeds to save the (nearly random) noise, producing very high image sizes (you can't find order in chaos, order which the algorithms use to produce more from less). Uncompressed BMP images don't have this noise and are therefore less random, they are much easier to compress.
However, I agree on the fact that large screenshots would probably work better as .JPGs, for example if the wallpaper in the screenshot is chaotic, PNGs can be very large and irritating to download with dialup etc. The wisest option would probably be to not recompress incoming JPGs and depending on the filesize (300k a good limit?), to recompress the PNGs. If the user sent GIFs or BMPs, the procram could try to recompress them as both JPG and PNG, then balance the filesizes and pick the other.
BTW: ilmcuts, I don't think that a PNG could, in any ocassion, be larger than the original BMP. This is perhaps possible with 1x1 -images where the PNG header takes more space (or something), but usually if compression algorithms completely fail to decrease the size, they revert to using blocks of uncompressed data in the midst of compressed lumps.
JPEG compression creates noise in the image and PNG compression is a true compression (such as ZIP, RAR or the LZW used on GIF), not a lossy one (JPG).
PNG cannot throw details away and proceeds to save the (nearly random) noise, producing very high image sizes (you can't find order in chaos, order which the algorithms use to produce more from less). Uncompressed BMP images don't have this noise and are therefore less random, they are much easier to compress.
However, I agree on the fact that large screenshots would probably work better as .JPGs, for example if the wallpaper in the screenshot is chaotic, PNGs can be very large and irritating to download with dialup etc. The wisest option would probably be to not recompress incoming JPGs and depending on the filesize (300k a good limit?), to recompress the PNGs. If the user sent GIFs or BMPs, the procram could try to recompress them as both JPG and PNG, then balance the filesizes and pick the other.
BTW: ilmcuts, I don't think that a PNG could, in any ocassion, be larger than the original BMP. This is perhaps possible with 1x1 -images where the PNG header takes more space (or something), but usually if compression algorithms completely fail to decrease the size, they revert to using blocks of uncompressed data in the midst of compressed lumps.