Sign in to follow this  
Wutalife37

File Compression

Recommended Posts

Hey everyone. I'm working on a 2D game that is about 10MB in size so far. About 8MB of that is hundreds of 3KB GIF graphics for the animations. When I tried to compress the 10MB using winzip, I only got it down to about 8MB. I'm hoping to get it much smaller than that. I did some searching online and found out that PNG is a better choice than GIF (particularly since I'm not using animated GIF's). But I don't think that alone will get my file size any smaller. Is there a better way to losslessly compress my files? Thanks.

Share this post


Link to post
Share on other sites
Have you looked at the individual compression ratios? Have you considered joining the individual gif files into a single atlas? That would compress better.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Ximmer
The problem here is that your image formats are already compressed.

It is rather difficult to compress what has already been compressed.


Quite true, as a book I have just read put it
Quote:
"Why is it that an already compressed file cannot be compressed further?" The answer, of course, is that such a file has little to no redundancy, so there is nothing to remove. ....Another answer is that if it were possible to compress an already compressed file, then successive compressions would reduce the size of the file until it becomes a single byte, or even a single bit, This, of course, is rediculous since a single byte cannot contain the information present in an arbitrarily large file.


This quote is reffering to lossless compression,such as zip.

Share this post


Link to post
Share on other sites
Quote:
Original post by Fruny
Have you looked at the individual compression ratios? Have you considered joining the individual gif files into a single atlas? That would compress better.


I do believe PNG is superior in general, but I'd like to point out that this advice also holds for PNGs - it can make a *big* difference if your files are all that small.

Also consider variants on zip. A standard zip archive is very wasteful if you have lots of tiny files, even if they aren't pre-compressed files. If making an 'atlas' isn't feasible, consider for example tarring the files first and running gzip on the tar (the .tar.gz combination that is infamous in the Linux world). gzip is perhaps not as sophisticated and it can only archive a single file (hence the *need* to use tar first), but operating on a single file can make a big difference (because files with similar content can be grouped together, more redundancy can be found; zip effectively "restarts" for each file AFAICT). As well, .tar is probably more sparing with metadata than .zip (which IMX adds about 100 bytes plus twice the filename length for each file - and that's if you don't have any folders).

An atlas really is nicer though. Note that you can often reduce the executable size this way too, by removing logic that determines filenames and opens multiple files, replacing it with a little math to find coordinates for each "image". Often this calculation folds into an existing one and costs nothing or almost nothing.

Share this post


Link to post
Share on other sites
Quote:
Original post by Wutalife37
Is there a better way to losslessly compress my files?

I feel I should point out that GIF encoding is not lossless, in general. Unless the source image is limited to 256 (potentially including the basic 16 colour palette) a new palette will be created (using an optimised median cut) and the image may be dithered.

[quote]Original post by Anonymous Poster
Quite true, as a book I have just read put it
Quote:
"Why is it that an already compressed file cannot be compressed further?" The answer, of course, is that such a file has little to no redundancy, so there is nothing to remove. ....Another answer is that if it were possible to compress an already compressed file, then successive compressions would reduce the size of the file until it becomes a single byte, or even a single bit, This, of course, is rediculous since a single byte cannot contain the information present in an arbitrarily large file.
As good as that explanation is, I'm disapointed to read that a published book would propagate such a horrible misspelling of 'ridiculous'. Sorry, I'm a pedant [rolleyes].

Regards
Admiral

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Here's a few tips in making a PNG that contains plenty of animation frames in one: Lay out the animation frames horizontally into the image. Use pngcrush to compress PNG files into smaller, it's a free tool. You could also Google for "gif optimizer" and try out a few of those tools and see if they make a difference for your GIFs.

Share this post


Link to post
Share on other sites
You could always, if forced, make the atlas-generating program yourself. :) You already know how to draw regions of images onto a buffer, so from there it's just a question of saving the buffer as an image again. There are plenty of libraries that can help with that; if you want to go bare-bones, just write a BMP (it's just a fairly well-documented header, optional colour table for 256-colour images, and raw data afterwards - beware it's bottom-to-top) and then resave it as PNG with Paint or something. (You can also subsequently use PNG crushing utilities on that PNG. I think some of them will also operate directly from a source BMP)

Share this post


Link to post
Share on other sites
Ok, I made a small program to construct the atlases. They are 1664x2560 pixels in size (though most of that is the transparent background) and there are 16 of these atlases. It cut the size of my graphics down by 3-4MB, which is great.

However, now my program is using up a lot more memory when I try to load the images (I'm using Java). I load the atlases using ImageIO, then I create all the animation frames by looking at the relevant part of the atlas.

Is this expected when using an atlas?

Share this post


Link to post
Share on other sites
Not nearly enough information. Are you constructing smaller image objects in memory from the atlas, or just blitting directly from it? If you're making the smaller objects, did you somehow hold on to the atlas image longer than you needed to (keeping a reference to it anywhere prevents it from being garbage-collected)? If not, did you *previously* have all the sub-images loaded all the time, or only some of them? (If only some, then of course memory will go up because you have all of the "image area" in memory all the time now instead of just some).

You may want to rethink the organization of your atlases. Try to put things in the same atlas if and only if you will generally need both (all) at the same time.

Share this post


Link to post
Share on other sites
I'm constructing smaller image objects in memory from the atlas, and I'm pretty sure I removed all references to the atlas after I was done using it. All the image objects stay in the memory (as they were before).

Share this post


Link to post
Share on other sites
Quote:
Original post by Wutalife37
hundreds of 3KB GIF graphics for the animations


Maybe it could help a bit to pack all those gif files together in one big file, because small files take up a bit more hard disk space than the data alone, if they're all in one big file there's less such overhead

EDIT: oh never mind, this was already mentioned in earlier posts

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Hello!

if the purpose is to make the installation file smaller, I would like to share a little anecdote.

I had a little game with roughly 30MB uncompressed graphics. If I compressed the graphics into PNG, the size used on disk was reduced... but the isntallation file GREW. How was this possible, you may ask? Well, the installer used a more efficient compression algorithm (i think it was bzip2 or 7-zip) than the PNG format. Since the entropy is high in already compressed PNG files, they wouldn't really compress any further with the stronger algorithm of the installer. The smallest installer size was when raw BMP files were used (30 MB down to 2 including exe files and all).

What is my point? My point is that by sacrificing some disk space, you can minimize the size of the installer file, by taking advantage of their advanced compression algorithms.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this