Proof-of-concept: real-time image decompression

Wuerfel_21

Ever wanted to display (semi-)arbitrary 8bpp pictures on a P1 but ran into the memory limit? Well, yearn no more, because I figured out a way. Still need to implement all features, optimize, clean up, document, etc, but you can have some demoboard-compatible (read: TV out on pins 12,13,14, 5 MHz XTAL) binaries in the mean time. I scoured the internet for some example pictures that'd compress well enough. I'll figure out where/who I got them from later(tm). I can tell you that reimu.binary was drawn by my humble self.

Phil Pilgrim (PhiPi)

Is this RLE compression or something fancier?

-Phil

Wuerfel_21

It's actually less fancy, it's basically dynamic bit-depth for different parts of the image - where there are only 4 colors used, a 2bpp+palette format can be used. The palettes are kindof run-length encoded.

Dave Hein

So it's run length encoding plus some form of variable length encoding?

Wuerfel_21

Uh kindof I guess. It works like this:

There are 3 decompression cogs that handle lines in an interleaved fashion, like a normal graphics driver would (infact, this is mostly just VJET with the rendering code swapped out).

Each cog has it's own command buffer and data buffer that contain data pertinent to all lines that cog handles. To decompress a line, it reads command bytes from the command buffer until it reaches the end-of-line marker. These commands cause some amount of longs to be read from the data buffer and converted into pixels in some way.

The command bytes encode like this:

%iiiiii00 draw 4i+4 8bpp pixels (palette unaffected)
%iiiiii10 unused, will be 1bpp coding?
%iiiiii01 draw 16i+16 2bpp pixels with individual palette per 16px. (last palette remains set)
%iiiiip11 draw 16i+16 2bpp pixels with shared palette. If p==1, load new palette first


%00000111 is useless (since %00000001 means the exact same thing) and is thus the line end marker

The 2bpp pixels are encoded in the JETEngine style delta format, instead of the more usual way.

Wuerfel_21

I just improved the compression ratio quite considerably by turning the previously unused %iiiiii10 command into an RLE command (that takes its color from the command buffer to keep the data buffer aligned). It can now handle quite a bit more complex images.

I'll get everything ready to post the code now.

In the mean time, have some nice screen photos (I could post video capture stills, but those don't look as cool, so I won't)

Wuerfel_21

Here we go - have fun with it.

It is used like this:

1. Have Ruby 2.6 or higher and the chunky_png gem installed
2. Create a 256x224 PNG using only P1 palette colors (it doesn't actually have to be paletted). (The P1 palette can be found in the included ntsc_scronch.pal or the image attached to this post). Keep in mind that the pixels will be wider than they are tall, about 8/7 ratio.
3. Convert it into PixCRUSH data by invoking the compression tool on the command line, like this: ruby pixcrush.rb my_image.png my_image.dat 
4. Open demo.spin in Propeller Tool and change the referenced dat file (you can't miss it). If you want, you can also change the TV pins, enable SVideo or PAL60, etc.
5. Upload to RAM or EEPROM
6. Enjoy the colors, I guess?

And here's where I, uh, borrowed the example images from:

mountain - https://www.deviantart.com/retronator/art/Pixel-China-Mountains-397566252
dragon - https://pixeljoint.com/pixelart/17331.htm
car - https://www.deviantart.com/necrocamo/art/Datsun240Z-835096558
demon - https://www.deviantart.com/kradakor/art/Demon-Castle-War-494897185
witch - https://www.deviantart.com/kradakor/art/Witch-Goes-To-Party-In-Castle-Town-811028234
dgme - https://www.deviantart.com/carnivius/art/Dragon-game-NES-258809598
ice - https://pixeljoint.com/pixelart/42277.htm
parrot/paltest - Wikipedia palette test images
reimu - Original artwork by your's truly.

Coley

Nice work Wuerfel_21 😁

Wuerfel_21

I just realized that there is no reason this format wouldn't scale to, say, displaying 1080p images on P2. Someone with a P2 should give that a shot.