Huffman & LOVE Encoding (compression & obfuscation)
Huffman & LOVE Encoder Module
a Decker module for compressing or obfuscating data with Huffman encoding (a type of compression) or array LOVE encoding
To add this module to your Decker project, in the Decker menu, go to File->Resources and then in the Font/Accessory mover, pick huffman.deck (or huffman.html) and copy it to your project.
Module API:
huffman.compress[string]
encode (compress at byte level) using a Huffman tree; returns a dictionary that huffman.decompress uses. To directly store some compressed data in Decker, you can store it in a field, with field.text: "%J" format huffman.compress["your string data"]
huffman.decompress[dictionary]
decodes (decompresses at the byte level) reversing huffman.compress. To retrieve some compressed stored data from a Decker field, use huffman.decompress["%J" parse field.text]
See the huffman.deck source for examples of working with the text by checking the lower left field's source.
huffman.obfuscate[string]
encode a string to a u8 array. when it is converted to LOVE, the string isn't human readable in the source. To directly store some obfuscated data in Decker, you can store it in a field with field.text: huffman.obfuscate["your string data"]
huffman.restore[array]
decodes a u8 array back to a string, reversing huffman.obfuscate. To retrieve some obfuscated stored data from a Decker field, use huffman.restore[field.text]
Try it out in the lower left, paste some text. The upper right shows it after compression & decompression. The lower right shows a "%J" format huffman.compress[string] or huffman.obfuscate[string]
- After testing, I realized that the Huffman encoder was way, way, WAY slow for the dictionaries that I was trying to encode, so I just switched it to using Decker's built in base64 LOVE. There's basically no performance impact. And it's much easier to use.
- So... the Huffman encoder isn't super useful... Oh well! Not everything turns out as expected. C'est la vie.
The only real drawback to this is that it will increase the stored text size, of encoded text, but it's really fast due to being implemented in the core of Lil/Decker. The Huffman encoder only works well in small batches. I'd have to think hard about how to optimize and vectorize it - I don't know if it's feasible.
- Don't expect a lot of compression, especially because of conversion to base64 (2 bits per compressed byte) + the Huffman tree in JSON/LOVE.
- With base64 Decker LOVE encoding, I've gotten around 80% compression on some sample text. Without base64, it would be more like 60%.
- The main reason I made this was to obfuscate text - if you feel like hiding some text in the deck source... >_>
- This can also compress any sort of Decker data that has been LOVEified ("%J" format object). You probably will not get good results on images. Large amounts of text may take a while to encode or decode.
To learn more about Decker, join us at: https://internet-janitor.itch.io/decker/community and here: http://beyondloom.com/decker
for my other decker things see: https://codeberg.org/woodring/ or my other itch submissions
| Updated | 1 day ago |
| Published | 3 days ago |
| Status | Released |
| Category | Tool |
| Platforms | HTML5 |
| Author | woodring |
| Tags | Creative, Decker, No AI, Open Source, sourcecode |
| Content | No generative AI was used |




Comments
Log in with itch.io to leave a comment.
Updated 20260713