| |
Oswald
Registered: Apr 2002
Posts: 5094 |
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 ?:) |
|
... 80 posts hidden. Click here to view all posts....
|
| |
Ninja
Registered: Jan 2002
Posts: 411 |
algorithm: What I mostly did is, rearrange the colors sorted by brightness. This is useful for fading, and often helps with compression. Still, if one is aiming for max. compression, a lot more analysis of the data is needed. A bitmap with lots of repeatings patterns should be created then, I guess. One of those interesting problems, which can easily grow pretty complex :D |
| |
Mace
Registered: May 2002
Posts: 1799 |
The thing with the way files are archived in CSDb is that it's virtually impossible to find a tool of your desire, without knowing the name.
@NinjaDRM: just sorting won't work, imho. You should also put equal nybbles of concurrent positions in the same place. Like, when you have colour 1,2,3 and 3,4,5 in neighbouring positions, you might want to have colour 3 in $d8xx, alhough this might not result in cascading brightness. (If you catch my drift) |
| |
WVL
Registered: Mar 2002
Posts: 902 |
My tool does exactly this.
first it checks what colors are _really used_ in the current char, and then checks if the same colors are used in the previous one, and rearranges to colors so the nybbles match
(if there's an unused color, it tries to fill the value up so it matches with the previous color! coolness! ie, char 0 color is $12, char 1 color is $x1 (x can be anything but isnt used), it rearranges char 1 to $12 too!)
However, this does not always result in a better packing.. since you're only looking at the colors, and not at the compressibility of the bitmap itself. Actually, i think you should combine the optimizer with the packer, and try out all color combinations for a char and see how well it packs.
so :
1)start with char 0
2)try all color permutations, and send this into the packer, select char with lowest # of bytes
3)go to the next char, and repeat.
However, even when this will be a lot better, it will still not give you optimal packing.. you'd have to consided all color-permutations of all chars at the same time. Horrifying.
I guess the best would be some kind of heuristic algorithm, deciding what is the best way to permutate the colors in a char.
|
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Mace: As I wrote, the sorting was intended for fading mainly, and it just turns out that it often helps with compression, too. I think for real hardcore compression, it would be useful to rearrange the bitmap to have lots of repeating patterns and not just concentrate on RLE in the color data (cause of 8K vs. 1.5K). Or maybe to skip this bitmap+colordata-idea and use something abstract. Lots of possibilities here! |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
WVL: It seems, we not only coded quite similar tools, we also came to quite similar conclusions :D |
| |
Mace
Registered: May 2002
Posts: 1799 |
Quote:Or maybe to skip this bitmap+colordata-idea and use something abstract. I bet there are a million ways to store the same picture in the memory and use some exotic routine to convert the information back to colourmaps and bitmap. But in the end you just want an optimized picture that has the original format. Then, there's not much else to do but sort nybbles and change the bitmap, I guess...
Hehe... we could do a contest: let's all make a file that holds the same picture and let's see who gets the smallest result after using the same cruncher :-)
No need to stick to a file-format: the only thing that counts is that it shows the original multicolour hires pic. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: Quote:Or maybe to skip this bitmap+colordata-idea and use something abstract. I bet there are a million ways to store the same picture in the memory and use some exotic routine to convert the information back to colourmaps and bitmap. But in the end you just want an optimized picture that has the original format. Then, there's not much else to do but sort nybbles and change the bitmap, I guess...
Hehe... we could do a contest: let's all make a file that holds the same picture and let's see who gets the smallest result after using the same cruncher :-)
No need to stick to a file-format: the only thing that counts is that it shows the original multicolour hires pic.
hehe.. sounds like a contest I could fancy ;) |
| |
enthusi
Registered: May 2004
Posts: 677 |
just post a pic and the cruncher top be used (I'd prefer exomizer (latest version)) :) |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
I'd suggest using at least 2 (better 3) quite different pictures and add up the sizes. Otherwise we have lots of finetuned algorithms for just 1 picture ;) Latest exo would be a good choice, I agree. |
| |
Mace
Registered: May 2002
Posts: 1799 |
Ok, let me suggest the first picture.
The title picture of Short Circuit:
(this is a screenshot from a demo, you should use the original picture, of course) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
