I'm impressed. The imbalance between encoding and decoding speeds seems a useful strategy when you are building special purpose hardware and software applications.
It seems if you're making a central source of data that is able to tolerate a much slower write process versus a quick read process that this approach can be advantageous.
Maybe using this core method in a problem space which maps to the radio/signal broadcast process of many receivers but a central source of truth.
I can imagine if you had an information base that changed slowly or which was pre-processed in a batch fashion, that it could use this method.
It doesn't even need for the central data to be decoded into a graphical image.
I think this radio model could map the problem space for a centralized system that maintained a list of items and their prices which needed to be broadcast to the retail outlets on a regular basis.
Or a common cache storage to make some complex data manipulation calculations centrally performed available to a large number of satellites who just need the end results but do not have the need to do local calculation.
1) IMO pointless to put an emphasis on extreme decompression speed but not show numbers against JPEG even
2) BCx essentially does the same codebooking/paletting but more efficiently by allowing you to interpolate between two palette entries for an even larger compression
This seems like straining the definition of "compression". We have a delta-coding filter and then palettization? That's it?
Edit: I should say, I find it surprising (but cool) that it apparently works so well. I would have expected errors to accumulate since the decoder has to un-delta-code. I saw mention of Floyd-Steinberg dithering and presumably that's what it's for; seems hard to get it working across multiple colour axes simultaneously, but the complexity is all in the encoder, so.
Worth noting that something perf-optimized for RP2350 is almost certainly not going to be optimal on a modern desktop-class core (with deep pipelines and wide ILP/SIMD).
I'm impressed. The imbalance between encoding and decoding speeds seems a useful strategy when you are building special purpose hardware and software applications. It seems if you're making a central source of data that is able to tolerate a much slower write process versus a quick read process that this approach can be advantageous. Maybe using this core method in a problem space which maps to the radio/signal broadcast process of many receivers but a central source of truth. I can imagine if you had an information base that changed slowly or which was pre-processed in a batch fashion, that it could use this method. It doesn't even need for the central data to be decoded into a graphical image.
I think this radio model could map the problem space for a centralized system that maintained a list of items and their prices which needed to be broadcast to the retail outlets on a regular basis.
Or a common cache storage to make some complex data manipulation calculations centrally performed available to a large number of satellites who just need the end results but do not have the need to do local calculation.
1) IMO pointless to put an emphasis on extreme decompression speed but not show numbers against JPEG even
2) BCx essentially does the same codebooking/paletting but more efficiently by allowing you to interpolate between two palette entries for an even larger compression
This reminds me a bit of Amiga HAM. Similar horizontal fringing.
You could also call HAM a compression method. Getting 12-bit (4096 colors) with just 6 input bits (OCS).
Or later 262144 colors with 8 input bits (AGA).
This seems like straining the definition of "compression". We have a delta-coding filter and then palettization? That's it?
Edit: I should say, I find it surprising (but cool) that it apparently works so well. I would have expected errors to accumulate since the decoder has to un-delta-code. I saw mention of Floyd-Steinberg dithering and presumably that's what it's for; seems hard to get it working across multiple colour axes simultaneously, but the complexity is all in the encoder, so.
Worth noting that something perf-optimized for RP2350 is almost certainly not going to be optimal on a modern desktop-class core (with deep pipelines and wide ILP/SIMD).
Absolutely. This is optimized for highly resource constrained devices, not modern machines. I can tweak the README if that's at all confusing.
Fun. Vaguely reminiscent of the Amiga HAM video mode.