Bitmaps - RAW vs RLE

A reminder about OpenTV bitmaps

A typical OpenTV resource module contains, amongst other things, data structures describing indexed-colour bitmaps that you’ll be assigning to shapes of type ICON_SHAPE in order to display them on-screen.

The data structures contain brief header information about each bitmap, and a block of data describing the actual pixels of the image, which can either be given raw, or in a run-length encoded (compressed) format.

Run-length encoded versions can be generated using the tool bmp2rl, and raw versions can be generated using bmp2raw, although the formats are pretty simple and files can be hand-rolled or created using other tools.

The header of each bitmap structure tells the middleware which flavour each bitmap is, so the data can be appropriately decoded and rendered to the OSD layer; in API calls to the middleware it’s not necessary to say what kind of bitmap you’re using.

The raw format renders significantly faster than the run-length encoded one, an effect that is particularly pronounced on the oldest STBs, but typically it takes up more space in STB memory.

Which to use?

Where the performance of your application needs to be optimised - and here that means screen refresh speed, or animation frame rate - you might find yourself using a preponderance of raw bitmaps.

Otherwise you will probably find yourself favouring the run-length encoded bitmaps because they produce smaller resource modules.

The twist...

The twist comes when the resource modules are then compressed (using the OpenTV tool ‘opress’), which more often than not they will be...

It turns out that many bitmap images, particularly those that use a lot of flat colour, actually end up smaller in broadcast if they’re left raw, rather than being run-length encoded, prior to opressing.

So... for each individual bitmap Mousepickle will tend to use whichever format (raw or rle) gives the smallest in-broadcast size for your opress-compressed resource modules.

Remember to keep an eye on the unpacked size (memory footprint) of your resources, to avoid busting the total memory or largest-contiguous block constraints on older STBs, and allow yourself to pick raw bitmaps where rendering performance is critical even when they might result in poorer overall compression. Nobody will thank you for making a service load quickly, if it’s then no fun to use!

The same considerations apply to bitmap data that’s incorporated within code, or included in some kind of exotic raw data module.

---

Caveats and exceptions to the rule...

RLE-encoded bitmap data structures aren’t always smaller in memory than the raw equivalents; for images with a lot of dithering the run-length encoding algorithm actually produces a bloated representation.

Where you have a number of run-length encoded bitmaps that share many identical rows of pixels, further savings can be made by merging their OpenTV data structures. You might need to create your own tools for bitmap conversion to do so routinely, but the structures could be hand-rolled for individual images for best optimisation.

Raw bitmap structures do not allow for reuse of pixel row descriptions in this way.

There are other reasons for using the raw rather than the run-length encoded format; you might be performing direct run-time manipulation of the bitmap data, for example, something that might be prohibitively complex to compute from anything other than raw data.