B-movie;)

Compressed animations on VMU!

How does it work ?

First to say something about the format of B-compressed images. These images are binary divided in 4bit wide units, one nibble each. The first nibble holds playing and decoding information about the following image:

How is the image compressed?

Is this a single image(or last of movie) or just one in the middle of a movie?

What about the next frame? Is it the same like the current one?

Second something about the compression. It's a kind of Run Length Encoding I found out (see development history for details). The first bit of each nibble stands for the type of bytes that will be drawn. In our case blank(0) or black(1) pixels(bits). The following 3 bit of each nibble determine the quantity of that pixels. As you realize we can only encode 7bits of the same type in the best case. This provides a maximal efficiency of 43%. But to reach that is very improbable. The average encoding efficiency would be about 10-20%.

So I specialized one useless case to give a big gain in efficiency: Imagine the 3 last bits would be 000. This case usually is unused because this nibble would draw no pixels. Lets define this as a special case: a lot of screen images contain several lines consisting only of blank or black pixels. So, from now on, nibbles like 1000 and 0000 stand for 48 black or blank pixels. Resulting in an encoding efficiency of 91.67%!!! we can use this to create some effects that require less memory than any other solution.

Another principle is to encode only the differences to the previous image within a movie. This, in some case, can give advantage compared to compressing the whole new image. When this is used, the header nibble tells the player to leave the current image on Screen and simply invert the special bits on the screen encoded as positive bits in the image data.

Summarizing I can say, in some cases, normal B-compression works best, in other cases B-compressing the image differences may result in minimal data size. But there are still cases when no compression is the best way. Imagine a chessboard like screen resulting in four times bigger data size with B-compression than without. This worst case really never happens. But if compression is not successful the image or frame is left as it is.

Over all I imagine that a datasize of 50% of the original is possible. When you understand how this compression works, you can easily create your movies such that resulting in even lower datasize. As an example you can exploit compression at its maximum when inverting screens, lines and parts of the screen.