Picture Packer
This format invented was by François Lionet (or possibly Constantin Sotiropoulos) to be used by the game development environment STOS for the Atari ST. STOS has a native contaner format calles STOS Memory Bank for storing a variety of resources. Each type of resource has it's own four byte long unique identifier which also makes the format easy to extend. One of the resource types natively supported by STOS is for compressed images (typically full screen images) with the identifier 0x06, 0x07, 0x19, 0x63 (which looks like a date, Lionets birthday perhaps?). These resources can also be stored by themselves, which is known as the Picture Packer format. A similar, but not fully compatible, functionality is also available in AMOS for the Commodure Amiga.
To achive better compression STOS divides the image into a slices and compress them individually. A few different sizes of the slices are tried and the best size is selected. The different bitplanes are also stored separately. But since the Atari ST doesn't store the bitplanes separately in memory but kind of interwoven. So the bits have to be shuffeled around a bit before encoded and the way this is done depends on the number of bitplanes. Which depends on the resolution of which the Atari ST has three, known as low (320x200 pixels, 4 bitplanes), medium (640x200 pixels, 2 bitplanes) and high (640x400 pixels, 1 bitplane). This is all fine and dandy as long as the provided functions of STOS and it's bundeled tool are used properly.
But then there is a third party application called The Picture Packer by Jeff Prieb. It is written in STOS and uses the provided function to compress images into the Picture Packer format. The problem is that it always treats the image data as if it is in medium resolution. Which (at least potentially) cases suboptimal compression. But worse, the header of the file is no longer useful for telling the intended resolution. Instead The Picture Packer uses different extansions to mediate the resolution. Which is unfortunate, and kind of stupid. Since this makes in impossible to even guess the intended resolution by just looking at the file content. There is no other way around this than treating it as three different (sub) formats of the original STOS format.
