Thread: Rle8

  1. #1
    Registered User carrotcake1029's Avatar
    Join Date
    Apr 2008
    Posts
    404

    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?
    Last edited by carrotcake1029; 03-18-2009 at 01:36 PM.

  2. #2
    Resu Deretsiger Nightowl's Avatar
    Join Date
    Nov 2008
    Location
    /dev/null
    Posts
    186
    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. )
    Do as I say, not as I do . . .

    Experimentation is the essence of programming. Just remember to make a backup first.

    "I'm a firm believer that <SomeGod> gave us two ears and one mouth for a reason - we are supposed to listen, twice as much as we talk." - LEAF

    Questions posted by these guidelines are more likely to be answered.

    Debian GNU/Linux user, with the awesome window manager, the git version control system, and the cmake buildsystem generator.

  3. #3
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    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.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  4. #4
    Registered User carrotcake1029's Avatar
    Join Date
    Apr 2008
    Posts
    404
    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

  5. #5
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  6. #6
    Registered User carrotcake1029's Avatar
    Join Date
    Apr 2008
    Posts
    404
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. RLE8 Bitmap Encoding
    By MrWizard in forum A Brief History of Cprogramming.com
    Replies: 6
    Last Post: 06-24-2002, 05:01 AM