Bad Apple! / More aggressively compressed video proof of concept

I’m 4 years late, but here’s my take on: Bad Apple! / Compressed video proof of concept

ardu_apple.ino.leonardo.hex (72.8 KB)

  1. Firstly, version containing only 1/3 of the video (130 frames) at 64x68 resolution, lossy.

ardu_apple.ino.leonardo.hex (76.2 KB)

  1. Entire video at 5 FPS (1080 frames) at 24x20 resolution (3x up-scaled to 72x60). Binary at 27738 Bytes.

ardu_apple.ino.leonardo.hex (72.8 KB)

  1. Here’s a version at 32x36 resolution, very lossy.

Encoding per frame (avg ~20.5 bytes/frame):

  • Bytes[0-2] – 30 bits where each bit represents a 4x4 block that hasn’t changed since last frame. Two left over bits: one for the color of the first RLE encoded pixel, the other for the RLE direction.
  • Byte[3] – N number of nybbles in RLE in this frame
  • Byte[4-N] – Each nybble represents the length of the current run of color, alternating between black and white.

Optimizations:

  • Reduce entropy on each frame by dilating/eroding the image.
  • RLE can be horizontal or vertical, we choose the shorter one of course. The runs simply skip over the blocks that have not changed since last frame.
  • We greedily look at the surrounding frames and pick the one that reduces entropy between frames.
  • We can introduce lossy-ness by treating some blocks that have minimal change since last frame. This produced stray pixel artifacts, but reduces the encoding to ~17.6 bytes/frame if we ignore %100 of 1-pixel changes. The artifacts are barely noticeable at 20%.
  • We can ignore some pixels by omitting "1"s in the RLE.

Music:

  • I started adding music, but got bored.

Code here: GitHub - justecorruptio/ardu_apple

3 Likes

Nice technical but hardier to see. This video isn’t the best for this hard compression, i think but it’s show that it’s possible to have crazy compression rate