| |
Oswald
Registered: Apr 2002
Posts: 5034 |
koala otpimizing
Hi Everyone,
I know there's a c64 tool out there that helps with optimizing koala pictures for packing, but no idea what it is called. Anyone knows?:) Timanthes would do the job for me aswell with its nibble swapper tool, but is there a way to load/save a native c64 koala format picture with it ? *.prg doesnt works, what format does it expect to be .prg anyway ?:) |
|
... 68 posts hidden. Click here to view all posts....
|
| |
MagerValp
Registered: Dec 2001
Posts: 1060 |
Maybe it's time someone did arithmetic (de)coding on the 6502?
|
| |
Mace
Registered: May 2002
Posts: 1799 |
I always liked data (en)(de)coding, although it's not quite my field of expertice.
One of my experiments was plain Huffman encoding, but I quite when I had to find a way to store the binary 'tree' in such a way that the crunching actually produced a smaller file :)
Also, my knowledge of existing mathemetic algorithms is fairly non-existant. That's not handy, when doing stuff like this.
Just a brain fart: what experiments could you do with rotating data?
If you have data like:
.byte $00,$ff,$00,$ff,$00,$ff,$00,$ff, Rotating that 90 degrees would result in 8 bytes with the same value.
Easier to pack than a pattern... sometimes :) |
| |
WVL
Registered: Mar 2002
Posts: 888 |
another brainfart :
interleaving the bytes of the bitmap.
Instead of storing
byte 0,byte 1, byte 2, byte 3
you store
byte 0, byte 2, byte 1, byte 3, to try and undo the effect of pixelgrids.
Maybe shifting every odd byte 2 pixels would be even better. |
| |
Mace
Registered: May 2002
Posts: 1799 |
Since we're having a farting party anyway, some other thought:
When looking at the colour bytes, you have 'only' 15*14*13 = 2730 (which happens to be $AAA) combinations. The 16th colour is the background and each colour will only occur once in the colour triplet (= 3 colour nybbles).
Unused colours can be optimized to match a triplet that is already in use.
The bitmap can be optimized to create the largest amount of equal triplets.
The triplets can be sorted to see how many combinations are really used. These can then be represented by the shortest combination of bits.
[edit, afterfart]
Ooh, another one!
You can know how many nybbles of the triplets are used, if you have the bitmap. So when the bitmap says 'only one nybble in use', you can use the other bits of the triplet to store info for the next position. |
| |
algorithm
Registered: May 2002
Posts: 702 |
dynamic compression algorithms can be applied to specific areas of the bitmap. etc |
| |
Mace
Registered: May 2002
Posts: 1799 |
Hey, this is not fair!
If Algorithm is in, I'm out!
He can't be beaten by us mortals when it comes to graphics encoding. ;-) |
| |
Mace
Registered: May 2002
Posts: 1799 |
However, before we forget: the original question was how to optimize the content of a Koala picture for crunching.
This is still an interesting question. |
| |
tlr
Registered: Sep 2003
Posts: 1736 |
Quote: However, before we forget: the original question was how to optimize the content of a Koala picture for crunching.
This is still an interesting question.
I completely missed that. :) I just read the later posts. |
| |
algorithm
Registered: May 2002
Posts: 702 |
Its a whole new ball game if you wish to keep the file format intact. As mentioned before somewhere in this subject, swapping over color data between nybbles, etc or/and changing bit sequence order of twobit pixels so that there will be more identical sections - which in turn would allow a compressor such as exomizer to compress the data more tighter..
I still prefer the entire encoding of data and then custom compression - which would give tighter pack rates.. and its all about size.. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1390 |
I thought this 'otpimizing' sounded like an entertaining challenge, so I've given it a go.
No rules seem to have been particularly agreed upon, but the one I considered most entertaining was attempting to get all three images in the smallest executable file possible, vis my 19141 byte entry here:
http://jaruth.com/c64/0704/3pics.prg
It deinterleaves the colour data before using a simple run length compression scheme (the nybbles have been chosen to maximise the run lengths), then applies LZ77 with a fixed huffman code for the bitmap. The third image in the corpus is pixel shuffled to improve the packing. (saves over 200 bytes on the compressed data, but then spends 91 on the deshuffle code). I'm not familiar with Exomiser, but this does beat pucrunch for this particular data set.
FWIW, I got Song of the Sunset down to 5436 bytes - I could shave off another six or seven bytes if I hard coded some decompression parameters, but that would be in breach of ninjadrm's anti-finetuning rule. I didn't consider the optional pixel shuffle to be an issue, as whether or not to use it is specified in the compressed data, not the decoder (kind of like PNG's alternate pixel interleaves).
http://jaruth.com/c64/0704/song.prg
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
