Yes, as I mentioned earlier there are 75 different RGBA values. The compression rate with the 7-bit pallet will be ~ 4.5.
That's my results with alonzo costume (same as you)):
data length :4098 numbers
+metadata: 75*4 numbers for ref table + 2 to store width and height of the costume = 302 numbers
= total length: 4400
I'd be interested to see you implement compressor and decompressor reporters to actually do this
It's a work in progress...
v1: RLE on each channel individually
v2: assign each pixel to a reference table
v2.1: RLE on v2
Excellent stuff 
I'm curious to see all your implementation
Raw project, i.e. without any polish ~(metadata, costume <=> pixels) only the compression part.
RLE compress - just RGBA
RLE compress.2 - RGBA to pallete => RLE
Oh. That must be because of zaggie avoidance interpolation. In principle there are only four colors in that costume. This wouldn't be easy, but I wonder whether de-antizagging to get the original four colors back and then using 2 bits/pixel, and then after compression and expansion redoing the zaggie avoidance would count as lossless! Supposing the compressor understands the smoothing algorithm.
If the number of colors is garantueed to be < 128, further compression can easily be achieved:
- Any single-pixel run will be stored as one byte: just the index of its RGBA
- Multi-pixel runs will be stored as 2 bytes:
- RGBA index + 128
- Run length
Thus the total number of bytes required to store Alonzo will be: 2 (width, height) + 1 (number of RGBAs) + 4 x 75 (RGBA index) + 2 (number of runs) + 1253 (single-pixel runs) + 2 x 796 (multi-pixel runs) = 3150. In a universably usable version one or several header bytes would need to added indicating the specific compression method.
If you code (groups of) numbers as character strings, they can be stored much more compact.
E.g. this simple block will code any positive integer (no matter how large) as a string:
Matching decoder
Proof it works correctly
Size info
How can we encode / decode 4 numbers (0-254) into a single one number?
ex: 255 125 81 255 -> xxxxxxxxxx (a single number)
E.g. 255 + 256 * (125 + 256 * (81 + 256 * 255) )
thk, that's wat i searching for
how to decode it?
thk i will test it
with MOD 256.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
I have a question: When transmitting between client and server, is it better to transfer a list of numbers or a string?
ex :
or
Well in your example - the 2nd one is more efficient
But Snap! has issues in sending byte data as strings as the underlying JavaScript unicode handling can mangle the data.
Converting it to Base64 chars gets around this but increases the total size of a message.
In the MQTT extension, you can set an option to use bytes and the extension avoids the byte->string->byte conversion process