[Kde-games-devel] Re: new KDE game: dominoes

[Erik Sigra]

torsdagen den 7 november 2002 23.33 skrev Jay Glascoe:
> Color reduction is easy (mogrify -colors 16 foo.png), it
> buys a much reduced size but at the price of loss of
> image quality.

I'm not suggesting loss of quality. Just make sure the palette has exactly as 
many colors as the image.

> hmm. I don't know how to use the Gimp. I'd sort of like
> to learn, but graphics really isn't my thing. I'd rather
> spend my time learning, say, 3D programming (which I'm
> half stuck into now, really really really cool stuff)
> 95% of the time, xv and the ImageMagick suite are more
> than adequate for my image manipulation needs.

I'm not suggesting learning the gimp either. Just 2 dialogs. First the dialog 
that shows up when saving a png. It has some checkboxes:
[ ] Interlancing (Adam7)
[ ] Save background color
[ ] Save gamma
[ ] Save layer offset
[ ] Save resolution
[ ] Save creation time
And a slider from 1 to 9 for compression level.

Just make sure that none of the checkboxes are checked and that the slider is 
on 9 whenever you save anything.

The other dialog is the indexing dialog (under "Image"->"Format"->"Indexed"). 
That is where the number colors for the palette is selected. And make sure 
that you turn off color dithering (unless you need it) in this dialog.

That is all I know about making images as small as possible with the GIMP.

An interesting thing is that saving the same image (64x64) oriented towards 
the 4 different directions give different sizes:
east:  248B
north: 281B
west:  251B
south: 283B

This shows an unused opportunity for compression. GIMP could rotate the image 
to be saved into the other 3 directions and see if any of them becomes 
smaller after compression. Then it could store it in the direction where it 
becomes smallest, together with a rotating directive (which would only take 2 
bits to store). I don't know if the png format supports this.