Is there any reason why these images are stored on the server as .PNG files? I understand the compression differences between .PNG and .JPEG but it seems to me that a lot of bandwidth and server space is being wasted with 900KB .PNG files when we could be pushing around 100KB .JPEG files. What makes even less sense is the image I uploaded was a 100KB .JPEG file and now it was converted into the 900KB .PNG file. The loss due to compression has already occured so now you are just storing a 900KB .JPEG.

I really feel for those on dialup trying to load screens or previews.

-Jon

I will admit that the PNG conversion does, on some occasions, inflate the image size. However, as a whole, we normally are cutting the filesize down.

Looks like most of the screens are 200KB and up. Mine is 900KB as .PNG, resaved as .JPEG yields 127KB. Simplicity tweak went from 6KB .PNG to 20KB .JPEG. DSTmod went from 1.8MB (!) .PNG to 229KB .JPEG. Glazemod went from 623KB .PNG to 138KB. Statistically, it looks more like the images are compressing a lot better in .JPEG than .PNG. It may be possible, however, that people are uploading uncompressed .JPEG files and so a reduction in size via .PNG is possible. However, an optimised .JPEG compression through ACDSee 5.0, for instance, yields a highly compressed image that is much smaller than a .PNG file.

-Jon

Don't convert from JPG to PNG, instead convert from BMP to PNG and then compare it with the jpeg.

Images that contain a lot of detail will not compress as well as a PNG as it would if it was a JPG.

I think JPG would be a better format for screenshots simply because the benifits of using PNG isn't really worth it for screenshots. People look at a screenshot once then move on. Quality isn't that important. Expecially since I'm on ADSL (512kb) and some screenshots take up to a minute or more to download.

If you convert a JPEG to PNG you'll get a size increase in almost all cases. Try to convert a BMP to PNG and then the same BMP to JPEG and compare the sizes. Of course the result will depend on the image.
Where's my post from last night?

tux hid it for some reason... *shrug*

How does the site convert the images to .PNG? I know I uploaded a .JPEG file and got a huge increase in size. I just tested ilmcuts' method of converting to .PNG and there was a good result. The .BMP file was 9.8MB, the .JPEG was 600KB. Saving from .JPEG to .PNG gave me a 1.6MB .PNG file but saving from .BMP to .PNG gave me 300KB. Maybe the server side conversion just needs to be altered?

ilmcuts, did you get my email from the other day about the source code?

-Jon

maybe you should convert only BMPs if stimpy's test is true. :)

hrmm...Ill have to talk to tux about that test you did stimpy and see if we can do something similar. Currently the site converts any image format uploaded to PNG directly via ImageMagik or GD2...I don't remember which. Maybe we can go to BMP before PNG and see if that helps.

Egonz...the idea of saving multiple image types scares me. I prefer to stick with one type with the best all-round performance increase.

Well I didn't have access to my email since sunday night, but I just checked my account a few hours ago. Got 141 new emails which I'll deal with in chronological order, so it might take a while until I see yours. =)
About the PNG/JPEG thingy, PNG is a vector-based format. With such a format you'll get very good results if you have large areas of a single color for example. Can't think of the proper english term right now but I hope you get what I mean. Zoom into a JPEG image and you'll see why a conversion from JPEG to PNG will almost certainly lead to worse results than BMP to PNG.

DeV: it won't help since you can't restore the information lost during the BMP->JPEG conversion. JPEG uses lossy compression, I don't really think there's a way to get to the original data given nothing but the JPEG. =)

I look forward to hearing from you ilmcuts.

JPEG also has big compression ratios when the colors within the pixel block are the same. After setting all the seperate pixel windows to single colors, it performs another algorithm (gee, its only been 4 months and I've forgotten all these terms) to compress all the like pixel windows. Very lossy once completed and completely irreversible. I believe groups of 8x8 pixels should be uniformly colored so in the end there should be less color difference than the original BMP file. This would be why highly compressed MPEG videos are blocky; it uses the same technology.

I never really went into the PNG compression algorithms but it doesn't make sense to me why the compression would be drastically different when going from a high-detail lossless BMP image and a lossy low-detail JPEG image.

-Jon

If you zoom into a JPEG you'll notice some kind of blur... which is harder to express with vectors than a unicolor area. I'm no expert in these matters though. Take a photo with a tree and a lot of leaves on it - the resulting PNG might even be larger than the BMP since there are a lot of small areas with a lot of colors (even though they'll mostly be different shades of green =)) on the picture. Make a 1600x1200 rectangle and fill it with a single color, then save it as a BMP and as a PNG... the BMP will be a few MBs while the PNG will probably be a few hundred *bytes*.
It's not the best example but it's the only one I could come up with right now. :P

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.