Rle8

I'm trying to implement a simple 8-bit run length encoder. For my testing, I am using the pixel data of a 100x100 black bitmap image. It is saved as a 24 bit image, this resulting in 100 * 100 * 30 = 30000 bytes of pixel data, all of which are 0x00.

So I know the nature of RLE8 is [1 byte header][1 byte data].
So doing the math, I came up with:
236 occurrences of 0xFF 0x00 and 1 occurrence of 0x9C 0x00, totaling with 474 bytes, preceded by a bitmap header.

My code outputs this as expected, but when I try to open my image with paint or some other paint-like programs, it fails. I am sure to change my bitmap header correctly.

Code:

---

bitmapfileheader.size = 474 + 54;
bitmapinfoheader.compression = 1;

---

A couple questions I have:
Do I need to change bitmapinfoheader.size to 30000, which is the uncompressed number of pixel data? I have tried it both ways, being 0 or 30000, and neither have made a difference.

Could it be that many of these paint programs don't support RLE8 encoded bitmaps?

If you need to see code, I would be more than happy to post some, but hopefully having a basic image should help as well.

Thanks ahead of time!

Edit: Just thought of something, can you even encode a 24-bit image a RLE8, or must you stick with an encoding that has the same data size, like RLE24?

One thing I've noticed . . . "100 * 100 * 30 = 30000" should be "100 * 100 * 3 = 30000", unless you're dealing with 240-bit colour. ;)

Use an image viewer like eog (or something similar), rather than Windows Paint. Last time I checked, Windows Paint couldn't open RLE-encoded bitmaps.

And always remember that google is your friend. There should be something in there that is a good start.

(Note: I apologize if you've already googled it. I've no idea what the problem is, just trying to help if I can. ;) )

There is no single standard for 8-bit RLE. One of the more common formats I have worked with goes like this:

If there is a run of up to 127 identical pixels, this is encoded as [N][Val] where N is the count, and Val is the pixel value. So a run of 255 consecutive pixels would be encoded as [127][Val][127][Val][1][Val].

A group of up to 128 consecutive DIFFERENT pixels is encoded as [-N][Val1][Val2]...[ValN] where N is the run length.

So, you split your count byte into a positive range and a negative range, in order to avoid introducing 100% overhead in the (not uncommon) case of large runs of different-valued pixels. You don't lose that much efficiency when encoding long identical runs, but you gain efficiency coding long non-identical runs.

I haven't worked much with MS BMP RLE, so I don't know the exact format. This stuff isn't standardized by IEEE/ANSI/ISO in the same way as many other compression methods.

As far as doing RLE coding on 24-bit data, there is no reason it isn't possible, but 24-bit data tends to be photographic, and therefore mostly free of runs, so it doesn't compress well.

Well the 30000 is the total pixel data, 3 bytes per pixel.

eog.... now look what you did, I need to boot into one of my linux distros :P

Also on another note, if i read correctly, RLE8 is reserved for 256 color or 8-bit bitmaps, at least conforming to MS standards...boohoo

I recommend NEVER trying to read or write image data from an image file yourself (with the exception of you own custom image formats, if you must). There are tools that will do this stuff for you, and they will do it correctly and quickly.

Actually what I had been doing was converting a targa image into a bitmap and was wondering if I could leave the compression in place. But since targas are easy enough to deal with, might as well stick with it.