compress and read images (4K)

Newbie & Debugging Questions
#1

So, this is my first time in the java4k competition, and I’ve figured out how to use pack200 (yay-game size 2.02 kb)
However, my images are still rather large in size, and I don’t know the right way to compress them and then read it in the code.

#2

Also I’m not too sure how the exact rules work; do I submit a pack.gz file? But then where do I put the images?

#3

This is probably the wrong forum… but I dont have power to move so I will leave it up to the powers that be to decide :slight_smile:

However to answer your question… it depends :stuck_out_tongue:

The simplest method with very little overhead is to simply utilise the pack200 format. That is create your jar including your images and simple pack200/gzip that. You will be able to access your images in the normal manner.

Over the years there have been quire a few image formats optimised for low colour count images proposed and utilised. You can perform a search over the competition forum and sub-forums to find them. These require custom code to read the image and that the image data is embedded within the class.

Normally data is embedded as an encoded string, however this year (using java 7) you might be able to use an embedded byte array of byte literals.

#4

[quote=“Jimmt,post:1,topic:40134”]
Various options.

  1. Use a format which you can load with built-in libraries. JAI is probably the best bet here, so look at which formats it’s guaranteed to support and test with those.
  2. Use a custom format, render it to the back buffer of a BufferedImage, and use Graphics2D.renderImage. Probably quite expensive in terms of string pool, but very flexible. The data can be stored in a file or directly in code.
  3. Use a custom format and render directly to the back buffer of your main BufferedImage each time round the render loop. This is my favoured option, but it limits your ability to do things like arbitrary rotations.
#5

gif images can be quite small, when used with colormaps, in comperrision with jpg

#6

I’m used to store everything in a string (be carefull of the encoding process of UTF-8, …). In fact, I use 1 big string to store graphics, maps and music. Same thing for variables, 1 big int array and 1 big double array to store every things.

Moogie can you develop a little more about Java 7 and the new possibilities to store data ?

#7

hmm i though that there was now byte literals… my bad, i think i saw binary literals and though that it was byte literals :frowning:


public class test1 {
	byte[] data = {0b1001,0b11111,0b1011};
}

I am not sure whether it is just syntatic sugar hiding the casts and so expensive… will have make some tests.

#8

in bytecode that’s:

ALOAD (for byte[])
BIPUSH/SIPUSH/LDC (for index)
     (1,2,4 byte value)
BIPUSH (for byte)
     (1 byte value)

per byte. Hence the approach to make a string hold raw data.

#9

just as i feared :frowning: ah well

#10

Also, dont forget:

putting effort to create “short looking code” (or bytecode, or encoded data in a bytestream) does not mean it packs well.

The compressor will works best with repetions.

example:

compresses way better than

although both contain the same raw data.
(just in different order)

What I mean is that repeating loops of data help the compressor.
So even longer code (bytecode) can compress better in the end.

->You will only know what works best AFTER running all your packing and compression steps.