| |
Oswald
Registered: Apr 2002
Posts: 5020 |
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 ?:) |
|
... 65 posts hidden. Click here to view all posts....
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
I got the three images in the corpus along with a slideshow down to 17307 bytes \o/
It's a bit slow to decrunch though - may as well be loading off tape..
Compressed data sizes for the three images:
untitled (floris) - 6755 bytes
song_of_the_sunset - 4594 bytes
short_circuit - 5624 bytes Tinned Koalas
Mostly worked on this in November/December 2023, just didn't get around to releasing until today. It does build on the ANS work for bitpickler of course. |
| |
Jetboy
Registered: Jul 2006
Posts: 216 |
Wouldn't it compress better if the order of bytes was changed? We were doing some research on it back in the days, and storing data in columns was usually giving better compression. For pictures with dithering, storing first odd bytes, then even bytes was giving even better results. |
| |
Fungus
Registered: Sep 2002
Posts: 618 |
I always get best results with pico 1.3 and my brain. Check the short circuit loading pic on the n0s release, it's hand optimized as well with pico and see if it's any better. |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
+-------------+-------------+-------------+
| spot+dali |png2prg+dali | koalacanner |
+-------------+-------------+-------------+
| 7349 | 7546 | 6755 | (Untitled/Floris)
| 5155 | 5464 | 4594 | (Song of the Sunset/Mermaid)
| 5986 | 6155 | 5624 | (Short Circuit/Karen Davies)
+-------------+-------------+-------------+
I think this stat belongs in this thread :)
Using SPOT 1.2, png2prg 1.6 and Tinned Koalas.
<cjam> So, spot-style 'optimizing' for png2prg 1.7? :D
I am not sure, for me cleanliness of the koala is the goal. Also, the better result may be because spot combines hi/lo nibbles in colorram, saving 500 bytes. I have no interest in that, I want to output standard format always. But, I could add a cli-flag for it...
@fungus, can you extract that koala from short circuit and pack with dali? would be fun if ur handiwork beats png2prg or even spot :) |
| |
Krill
Registered: Apr 2002
Posts: 2847 |
Quoting ChristopherJamI got the three images in the corpus along with a slideshow down to 17307 bytes \o/
It's a bit slow to decrunch though - may as well be loading off tape.. This sort of flips the table on the entire premise of optimising C-64 multicolour bitmaps for LZ-style compression.
If it only wasn't THAT slow to decode. =) |
| |
Fungus
Registered: Sep 2002
Posts: 618 |
pico 1.3+dali = 5980 |
| |
soci
Registered: Sep 2003
Posts: 473 |
Packed what I did in the past with dali now and it's 7342, 5156 and 5984 respectively. Almost spot on. |
| |
Sparta
Registered: Feb 2017
Posts: 39 |
Wow, fantastic achievement CJam! Would be interesting to see how differently “otpimized” versions of the same bitmap compress with koalacanner.
Quoting BurglarI am not sure, for me cleanliness of the koala is the goal. Also, the better result may be because spot combines hi/lo nibbles in colorram, saving 500 bytes. I have no interest in that, I want to output standard format always. But, I could add a cli-flag for it...
SPOT doesn’t change the cleanliness of the koala and outputs standard koala but it can also create other formats such as the combined color RAM nibbles if that fits one’s needs better. :)
The goal with SPOT is to get as close to hand optimization as possible in a fraction of the time needed for the latter and in a way that can be added to a democoder’s toolchain. |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
Quoting SpartaSPOT doesn’t change the cleanliness of the koala and outputs standard koala but it can also create other formats such as the combined color RAM nibbles if that fits one’s needs better. :)
Yea, just tested myself as well and indeed, I was just hoping combined nibbles would be the main reason why I'm trailing behind :)
Quoting Funguspico 1.3+dali = 5980
Fungus Handiwork Wins! \o/ |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Quoting KrillThis sort of flips the table on the entire premise of optimising C-64 multicolour bitmaps for LZ-style compression.
Yes, it's inspired by the discussion, rather than a direct response to the question. I got a bit distracted :)
Quote:If it only wasn't THAT slow to decode. =)
Yes, it's a bit impractical for 99% of use cases.
Quoting SpartaWow, fantastic achievement CJam! Would be interesting to see how differently “otpimized” versions of the same bitmap compress with koalacanner.
Cheers! FWIW at the moment the first phase of compression just sorts the non-background colours in numerical order and assigns them to bitpairs 1 to n. I could try and allow preserving of input bitpairs, but it would still need to be constrained to using the first m values, where m is the number of distinct colours - the second phase only outputs as many colour nybbles per char as are actually used. Oh, and it'd be a moderate amount of work at this stage too - the current implementation just uses a library call to load a koala into a 160x200 array of four bit values, so it doesn't currently have access to the original bitpairs..
I do need to see if it compresses any better if I sort the colours in luminance order instead - that might be better at dealing with images that use similar shading patterns with different local palettes in different parts of the image.
Nice work on Spot, btw - it actually answers Oswald's original question, and it's the second best option after putting a Fungus in every home :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
