That would have to be something like merely keeping the costume’s name, which I don’t think is what you are looking for.
Seriously, any (general-purpose) algorithm reducing the amount of data to less than 5 kbytes is going to be excellent, IMO.
BTW Snap! itself apparently employs data compression, since while every pixel is characterized by 4 bytes, adding one Alonzo costume to a project increases its memory usage by only about 11 kbytes (approximately 1 byte per pixel).
How many unique run lengths? (I found 70). When combined with another lossless compression method, 3.5 - 4k is probably the best attainable result. But who knows what someone will invent.
It just loads the image as a png file, so snap isn't really doing any special compression. Audio on the other hand, snap uncompresses it and stores it as a wav file (or at least that's what I get when I export it).
Do the competition rules allow solutions that work only for Alonzo? Or does the solution have to work on arbitrary picture files? Alonzo (like all cartoon characters) is easy to compress because (as dardoro suggests) you get lots of runs of identical colors.
I think this misses the point of the question. Is a solution good enough if it only works for Alonzo? So I could enter
and then have ITEM OF variants that check for the word "Alonzo" as the input, and if so, read the desired pixel from the disk file, carefully not reading the entire costume into memory?
As a more realistic example, we've been talking about run length encoding, which is a great compression technique for cartoon costumes but not so good for photo costumes (or watercolor ones such as the ones from Meghan Taylor). Is that acceptable?
(Sorry for being lawyerish about this, but I believe in resolving ambiguities before entries are judged, rather than after.)
And it's great for cartoons, as I said. But for photos it's likely to make the picture twice as big, every pixel combined with a run length of 1. So, is that accepted as a solution? I think Simon was sort of hinting about that, and you made it very explicit, but I just want (still!) a yes or no about whether it qualifies as a solution. You clearly say yes, but it's Simon who has to make it official. :~)
I'm not into "serious" (widely used) compression software, but I assume for every object one or several from an array of algorithms is / are selected, dependent on their respective results when applied to that one object. The selected algorithm(-s) is / are mentioned in the compressed file's header, so at decompression time it's clear which decompression algorithm is to be used. Is it like that?