LibRLE

LibRLE is an open source implementation of the RLE compression algorithm that windows uses for compressing it's bitmap format, with the file extension BMP, RLE or DIB.

In truth, to give it the title "LibRLE" is certainly cheesy, and perhaps even grandiose. To give it an icon, is beyond the pale! Nevertheless, here it is. There are actually good reasons for us producing this code, and making it available on the internet. Hopefully this will become aparent. If you also have the problems we did, then you might be grateful that we posted this code here. Certainly it did not require the development effort that it's apparent peers here must have done. As you may appreciate, placing it here and labelling it as we have, simply satisfies our need to keep things neat, organised and follow format and convention.

Windows does actually provide native support for reading and writing RLE bitmaps. This is perhaps one of the reasons why there is no obvious and dependable support for this format, as source code, on the internet. There are, however, some problems with the windows support for this capability. The problems may cause one to consider the possiblity of writing such code as this "micro library". In addition to the somewhat fuzzy level of native windows support for this format, another factor is that the format is really pretty ancient in computer terms. Despite it's age, from time to time, one may come across an application which generates or requires this format for some purpose. If the need falls into this category, and the level of control provided by windows is not satisfactory, then this code might be useful. So then, it's a small group.

The reason for making this code available as an open source offering is mainly to do with the architecture of the library in which all our image format filters exists. We combine a range of different open source libraries into one dll. We feel that this RLE micro library falls into the set of things that should be in the library more because of it's interface, than because of the similarity of it's content with it's peers. Since 90% of the overall library is open source it makes sense to make LibRLE open source too.

So, to business. Why is this micro library necassay?

The way that windows support for converting RLEs works, seems to require that one pass an RLE bitmap into a device context. Once the bitmap is in the device context it can be extracted as a plain bitmap. The other way around it's the same, but in reverse. Job dun. Dead simple......

....Perhaps not. It's all about the palette, you see. Now, it's quite possible that we've missed a trick here, but. Certainly, senior people at Microsoft blog in a Zenlike way about DibSections. Dithering, palette optimisation, all you have to do is think the right way. Perhaps we don't. As seen from here, it'd just be nice to separate the whole RLE thing from the device context. The real trouble is that without extreme care windows gives you an RLE bitmap, but it has a fixed palette of 16 or 256 "Windows Colours".

We can see how this situation has arisen, and we can see why it's so difficult for Microsoft to change the way it all works. In some ways it seems a relief that MS doesn't try to change this. Nevertheless, RLE is still out there. Today, perhaps 90% of computers support 24bit colour so an optimised eight or four bit palette with or without RLE is a really useful, programmer friendly, way to compress some image types. One carefully prepares an optimal palette, only for it to be converted to a truly horrible windows palette for compatibility. All that was wanted was an RLE of the image already made. It strains mental tolerance. This is particularly true when you know that the device context is causing the problem, but the RLE scheme doesn't need it. Well, anyway, that seems more like zen to us!

This library aims to allow it's user the capacity to read and write the RLE format, without having to worry how windows might modify the image content. It's that simple.

LibRLE has FromRLE() and ToRLE() functions which take the same style of arguments as all of the other image import filters. These are first described in LibPNG. For more information, see the text for that library. The interface for this library is described below;

typedef struct
{
	// RLE8 or RLE 4
	bool Four;

	unsigned long XDim;
	unsigned long YDim;
	unsigned long LineSize;
}ImgRLEInfo;

void rle_ToRLE(void*& pBuf,unsigned long& BufSz,ImgRLEInfo& Info);
void rle_FromRLE(void*& pBuf,unsigned long& BufSz,ImgRLEInfo& Info);

The parameter Four replaces the traditional BitCount. This filter will only deal with 4bpp or 8bpp bitmaps. The parameter Four, indicates either of these types. A palette is always expected.

Since we wrote this code, and are making it freely available, a description of it's operation, and a downloadable distributable zib of the source code are available on the left.