Follow me down the optimization rabbit hole

Intro This is a brief first look at an idea I've been ruminating on for along time. Actually, it's two ideas - tweaking CCITT Group4 (T.6) image compression and compressing font data for use on microcontrollers. Why do either of these things occupy space in my head? CCITT Group 4 Many years ago, a standard was created for the digital FAX machine. It specified not only the audio transmission method over POTS , but also a new bitonal, lossless digital image compression scheme. The 3rd meeting of these experts (Group3) created a one-dimensional run-length encoding scheme using statistical coding (Huffman) to shrink the most common run lengths for black text on a white background. Not long afterwards, at a 4th meeting, some clever person/people added a 2D component to it to take advantage of similarities between the current line and the one above it. They called this Group 4 compression The compression ratio increased quite a bit (up to 20:1), but so did the complexity of the code

Intro For a client project I was asked to collect samples from an IMU at a high rate. For practical reasons, we chose the Seeed Studio Xiao nRF52840 Sense  as a prototyping platform. It has a Nordic nRF52840 64MHz Cortex-M4 with a STMicro LSM6DS3 6-axis IMU on board (and digital microphone). The cost, size, and ready made product made it a natural choice to get started with the project. The IMU consists of a 3-axis accelerometer and 3-axis gyroscope. For our use case, we only need one axis of accelerometer for vibration detection. It has a built-in 8K FIFO capable of collecting the samples at a high rate (up to 3200 samples/sec). This sample rate was most likely designed for use with the SPI interface (we'll soon see why this is the case).  I2C Speed Limit? The I2C interface of the LSM6DS3 can probably run much faster than its stated max of 400Kb/s, but with the nRF52 series, we're basically stuck with that as the top speed because the I2C clock can't be set higher (based o