Universal Videogame List - www.uvlist.net

Full size images at 800x600 or less are not re-compressed, so it depends on the file you upload.
Bigger images are compressed at 90% quality.

When I prepare images from emulators, I first attempt to do a png if there are 256 or less colors (which does often occur on systems that can use more colors). I index the png to match the number of colors in the source. This can create perfect lossless digital copies in a very small file (I've created screenshots using png that are 98% smaller than the source bmp). Of course the emulator might not be accurate to begin with, especially ones that use palettes :( If png isn't an option (usually because of 256+ colors), I use jpeg. I adjust the numbers and compare to the original, so that I get the smallest possible file that does not look 'noticeable different' from the original. I think there is an upload limit of 50k. For a few screenshots, it is necessary to reduce the image to noticeably lower quality meet this limit. For many jpegs, I notice diminishing returns around %80 (A LOT more bytes for hardly any reduction in artifacts and color inaccuracy). I favor smaller file sizes over better quality for non-screen sources (box art, cartridge art, promotional art). Sometimes with the art, a high quality image serves only to emphasis the dents, scrapes, price tag goo, various wear, and damage to it. It may seem like a lot of trouble, but if I saved an average of only 5k per image, that's 2675 megabytes saved on the UVL servers. I don't contribute as many images as other uses, who could reduce their 'byte print' if they are not already taking such actions. A 5k savings per image would be about 233.5 gigabytes off UVL at the moment.

(Actually those numbers seem a little high, perhaps I'm not using google calculator correctly. Perhaps Andrea can chime in with more accurate numbers)

If you want to compress images more before uploading, I'd suggest trying pngout and jpegoptim. With default settings both do lossless re-compression, although pngout takes quite a while to process images. (both are command-line tools, btw)

Anyway, some images (especially large ones) seem to be compressed at much lower quality than 90%, but I've only noticed this in pics uploaded by others and haven't paid attention to my own uploads if they have that as well (if they do, then it's something done on server-side, otherwise it's the uploaded image). May have something to do with generation loss.

I just downloaded and tested the two programs you gave a link to. The jpeg program only gives me 2-3% optimization on my normal compression method I use. But I'm quite impressed by the pngout program. I tested it with (rather small) png files and this little program gives me about 50% compression for each file. Not bad.

Probably should upload only 100% jpegs to UVL to avoid the generation loss, but that isn't very efficient in cases where the images don't get recompressed.


Jpeg isn't really a format that can be safely recompressed, so it pretty much just scraps the little info from the file that can be without damaging image quality. Use the -m## option to set the quality % and it will get them smaller, but it's no longer lossless if that's done.

png is 100% lossless, and beats jpeg for images with 256 colors or less (pre-SNES systems, with a few exceptions). Its not good for more than 256 though. There are advanced ways to compress png images with more colors, but even then, jpeg will most likely do it better. Generational loss is not an issue for png unless someone is using a very sloppy application or uses a good application sloppily. I use GIMP and it does not generational loss in png unless I were to go poking around with the some of the advanced tools. I use gimp to crop, index, and save/compress to png format, no loss. The indexing process can be botched. In reducing up to 256 palette colors to number of actual colors present in the image, one must avoid reducing the palette of colors to less than the number of actual colors to prevent those colors from being lost and replaced with a different one.

By the way, If I ever do go poking around an modifying an image, I usually use jpeg and I always add a red, a green, and a blue pixel near the bottom right of the image to form a triangle (unless I forget to):
%%%%%
%%R%%
%%%%%
%B%G%
%%%%%
I some times use GIMP to remove the image of real flaws in the art (scratches, rips, dents) from scanned art before uploading it to UVL.

I will give those other programs a try to see how they compare with GIMP.

EDIT:
pingout seems to provide 8%-10% smaller compression than GIMP. Of course, this is comparing file sizes on my computer before the upload to UVL. Perhaps Andrea could look at the file sizes of the images for Mine Rescue to see if this smaller file size translates to the server as well. If it does, I will continue to use pingout.

Right now we have 47866 images, disk usage is 1.74 GB, an average of 36.35K for image, thanks to the many gif / png used.

And yes, "this smaller file size translates to the server as well".

I don't know about the 50K upload limit, I've uploaded image much bigger than that.

I'll try pngout with the site icons, despite I'm forcing caching.

As long as you use true color, PNG does support indexed images (max 256 colors) and that is far from lossless for images with more :)


Actually, it can be. They're just usually very rare cases. Text for example, but even then it's better if there's as little color as possible.


Doesn't exist, you have to intentionally cause the loss for it to happen. I was referring to JPG images with that anyway.


AFAIK, pngout does automatic color reduction if the image has <=256 colors. There's also a tool called pngrewrite or some such which does only color reduction. Botching color indexing should only be possible if you force the number of colors to be less than there are, some apps have nice filters that pick colors that end up making the end image very close to the original despite having scrapped color information (I think they usually call this 'perceptive' or some such method, I forget).