Results 1 to 23 of 23

Thread: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

  1. #1

    Thread Starter
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    Updated. Added a few tweaks to the code to squeeze a few more bytes of compression. In some cases, it is significant, but on average, reduction of a couple hundred bytes achieved. See Post #2 for which ones I included & which still may be doable. Also updated the zip to include 2 more bitmaps: 1) one that this project & Windows can't compress smaller & 2) one where Windows can't compress, but this project compresses pretty well

    Microsoft allows 8-bit bitmaps to be compressed using a somewhat simple, not terribly efficient, run length encoding (RLE). Strict rules apply, but is rather easy to encode/decode. But you don't need to decode it. Any decent app that can open a bitmap file can read RLE8 bitmaps, including VB's LoadPicture.
    Quote Originally Posted by paraphrased from msdn
    Encoded runs cannot be larger than 255 bytes
    Encoded scanlines terminate with a double null byte (end of line EOL)
    Encoded bitmap terminates with bytes: 00 01 (EOF)
    Scanlines are Word aligned, not DWord aligned
    Associated BITMAPINFOHEADER fields required: biCompression=BI_RLE8: biSizeImage = size of encoded pixels

    Encoding: can have several runs per scanline. Each run starts with a control byte:
    01-255 indicates a repeated byte run length. The next byte is the repeated byte
    00 indicates EOL, EOF or uncompressed run follows. Next byte determines meaning
    00 = EOL
    01 = EOF
    02 = Delta followed by 2 byte "jump-to" coordinates. Not used in this project
    03-255 = uncompressed run length & the uncompressed bytes follow
    for odd length runs vs. even length, one padding byte is required at end of encoded run

    Compression net gain(+)/loss(-) per run:
    repeated byte runs: (length of run) - 2
    uncompressed runs: if run is even number of bytes: net loss of 2 else net loss of 3
    each scanline removes 2 bytes (EOL marker) from any net gain
    loss of 2 bytes (EOF marker) from total net gain after all pixels encoded
    Whether you are aware of it or not, you can actually get the API GetDibits to compress these 8-bit bitmaps for you. Niffty, fast, but unfortunately, what is returned can actually be larger than the original uncompressed image at times. In any case, I think we can do a bit better than Windows in this area.

    Attached is a sample project wrapped around the key routine: pvCompressRLE8. Also included are 2 simple bitmaps to play with. Now trying to go out and find 8-bit bitmaps can be a bit painful, pun intended
    Suggestion: for playing around, use Microsoft Paint. Open image in Paint, save image as 256 color bitmap & don't care if the colors get messed up a bit. It's just for playing anyway

    The routine I've written is not guaranteed to compress smaller than the total uncompressed size. But it should 99.9% of the time. In fact, it out-performs GetDibits every time (so far). I'm sure there are a few bitmaps that Windows can compress better via GetDibits.

    This routine was created simply because I was inquisitive, wanted to see if I could possibly do it better (given how poorly Windows seems to do it). If there are better routines out there, please link them. Think many would like to learn from those also, me included.

    Last but not least, I'm not touting this as the best RLE8 routine for VB6ers. But it ain't bad for a 1st attempt. The one I've included could use a little tune-up also. See post #2

    FYI: If you want to see how Windows does when the routine fails to compress a bitmap, rem-out the "GoTo ExitRoutine" line after the msgbox displaying the failure

    Best case scenario for failure and the "compressed" data being larger than the original data size would be a size equal to that shown below (assuming width < 256 else worse results). This is because if no bytes repeated on any scanline, the scanline would be coded with a 2 byte prefix + the entire scanline bytes + 2 byte scanline terminator. The encoding also requires a 2 byte EOF maker. But when compressing fails, the routine aborts so user can write bitmap in original bytes vs writing an even larger bitmap. Note: standard bitmaps without any compression algo applied have their pixels DWord aligned. This means for an 8-bit bitmap, a maximum of 3 padding bytes per scanline can be used for standard bitmaps. Even if that is the case, the minimum extra bytes used in RLE8 compression would be 4 per scanline (assuming more than 1 color in a scanline). In other words, RLE8 without being able to compress any bytes, would be a larger file than not using RLE8 at all:
    Code:
    <best-case "compressed" size when bitmap cannot be compressed (not good)>
    even-value image width: ImageHeight * 4 + 2 + (ImageHeight * ImageWidth)
    odd-value image width: ImageHeight * 5 + 2  + (ImageHeight * ImageWidth)
    ^^ extra padding byte needed per scanline
    Attached Files Attached Files
    Last edited by LaVolpe; Sep 18th, 2014 at 08:20 AM. Reason: rewording thoughts
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  2. #2

    Thread Starter
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps

    The "efficiency" tweak in the algo I provided is described below. The actual code to perform this tweak is far less than the words used in trying to describe it in detail

    First question is how can we compress better. The rules for RLE8 are stratight forward but don't leave much room for ingenuity. Not all bitmaps will compress well and the photographic types compress most poorly since long runs of consecutive colors doesn't occur as often.

    That question has a two part answer:

    1) Each uncompressed run results in a net compression loss of 2 or 3 bytes, depending on whether the run is even or odd respectively. Merging two consecutive uncompressed runs will always result in a run that has a slightly better loss. This is because each run is a minimum net loss of 2 bytes, a total of 4 bytes minimum & up to 6 bytes if both runs were odd lengths. Combine them, and a best case is 2 byte loss or 3 byte loss at worse case. In any combination, net loss will be reduced by at least 1 byte and up to 4 bytes. The problem is that consecutive uncompressed runs don't happen naturally in RLE8 encoding.

    2) Small compressed runs can result in a net loss or no gain at all. A run of 1 byte is a net loss of 1 byte since each run requires a control byte. A run of 2 bytes is a net gain of zero. String several of these together and a net loss is possible. In RLE8 there is no way to write two unequal bytes as a run, other than two 1-byte runs. Three or more unequal bytes would result in an uncompressed run. For example, 10 runs of 1,2,2,1,2,2,1,2,2,1. Each run of 2 is net gain of zero, but each run of 1 is a net loss of 1. In that example, we have 10 individual small runs with a total net loss of 4. Combining them to a stand-alone uncompressed run, would cut that net loss in half.

    So, we can improve compression by locating a bunch of small consecutive runs or merging two uncompressed runs. This is where the logic focuses.

    In order to get two uncompressed runs back to back, we look at the compressed runs between those two. If the net gain is less than 1 for those compressed runs, we can merge everything between, and including, those two uncompressed runs and guarantee at least 1 byte reduction in net loss, but likely a complete reduction in net loss and potentially a net gain. The only restriction is that the combined run cannot be greater than 255 bytes. Even if the run is greater than 255, we can still reduce a net loss if we can merge the compressed runs into one of those two uncompressed runs if that length would be 255 bytes or less.

    If we can increase compression by as little as 10-20 bytes per scanline, the result is far better compression depending on size of the bitmap since the compression is per row and the bitmap can be hundreds of rows in height. On a 256x256 bitmap, increasing compression by just 10 bytes on average per scanline, improves compression by 2,560 bytes overall.

    Now to describe the logic

    An encoded scanline consists of a series of encoded runs. The number of runs can be in the hundreds depending on size & content of the bitmap
    The logic pre-scans each row of the bitmap & the following info is tracked
    - run start position
    - run type (compressed/uncompressed)
    - run length & cost (net gain or net loss per run)
    - total bytes needed for the encoded scanline

    After the initial scan has been completed, then the following tweak is applied
    - look for all cases where we have an uncompressed run followed by one or more consecutive compressed runs, followed by another uncompressed run
    - for those compressed runs between uncompressed runs, tally the total net gain/loss
    - if there is a total net loss or the net gain is zero, then merge those runs + the leading uncompressed run, into the trailing compressed run if the new total uncompressed run will be 255 bytes or less. If length is greater than 255 then merge those compressed runs into either the leading or trailing uncompressed run if possible

    To improve the logic even further, the new merged run becomes the first uncompressed run to possibly be used in the next merge action. In other words, after the merge logic is done, it is completely possible to end up merging dozens upon dozens of runs, of both compressed/uncompressed, into a single uncompressed run. This is where the true gain happens by reducing several small net losses, we eventually get an overall better net loss, zero loss/gain, and even potentially a net gain.

    Even when any scanline fails to compress, it's net loss can be offset by other scanlines' net gains. The merging logic only gives up when the total bytes needed to compress the image exceeds the total bytes needed to leave the image completely uncompressed. This failure potential is tested after each scanline completes its initial scan.

    After tests where Wndows compressed image poorly (photographic type images), I have seen consistent results in reducing a net loss by 20-30 bytes on average, with each scanline.

    After merging logic is done, the encoded scanline is written to the return array

    Room for improvement (brainstorming):

    1) If the total run after merging would be 256+ bytes. Merge doesn't take place. But if the total gain/loss is a loss of 4+ bytes, the consecutive compressed runs between the two uncompressed runs, can be completely or partially merged into its own uncompressed run without appending to either leading/trailing uncompressed runs. Improvement on compression would be at least 1 byte
    << implemented in latest update >>

    2) If no uncompressed runs exist in the scanline, the scanline isn't tested for merging. As shown above, net loss (if any) can be reduced, in some cases, by merging several small compressed runs into a single uncompressed run

    3) If the encoded scanline terminates with a compressed run, that final run isn't tested. It is possible that combining that final compressed run into a preceding uncompressed run can reduce any net loss between the two runs
    << implemented in latest update >>

    4) Cases where you have two 1-length runs. This occurs when two unequal bytes are followed by a compressed run: (...1,1,20...) or finishing off a scanline. With RLE8 there is no way to encode 2 unequal bytes that are not part of a uncompressed run, other than two 1-byte runs. The net loss for 2 consecutive 1 byte runs is 2. This can be negated with any of the improvements above. You would never have 2 1-byte runs followed by an uncompressed run as that would end up being encoded as at least a 3-byte uncompressed run
    << implemented in latest update. But still can exist if surrounding runs > 253 >>

    5) Have to test this idea; haven't tried. What if you got to a point where every pixel from the current point to the end of the bitmap was the same color? Could you just provide an EOF marker and be done with it. Probably won't get consistent results since the decoder would have to guess what color index should be used to fill the rest of the bitmap. I'd believe commonsense would be to use zero. If used, you could save at least 4 bytes per scanline from that point forward.

    6) Use of Delta encoding. Theoretically, you can increase compression by a few more bytes. I'll quickly describe how & then tell you, just don't do it. The Delta control byte is a 4 byte sequence. The last 2 bytes are offsets: how many pixels to move right, how many rows to move down. Let's say you are at start of scan line and that line + the next 4 are all the same color, completely. You could encode the current scan line to a Delta & say move 0 pixels right + 5 rows down (skipping the current row & next 4). Instead of these 5 scanlines needing at least 4 encoded bytes each (20 total), you'd just use the 4 required for the Delta encoding + 2 for the current scanline's EOL: 6 bytes vs 20. But not worth it for a couple reasons: a) requires you to read ahead to see if it is even possible, b) you have no way of informing the decoding routine what color index to use for those skipped lines. Assumption would be to use zero I would imagine.

    The only combination I didn't discuss is what happens when 2 uncompressed runs occur back to back. This can only happen if the leading one is 255 bytes. Nothing to do as 255 is the maximum run allowed
    Last edited by LaVolpe; Sep 16th, 2014 at 02:57 PM. Reason: added room for improvement
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  3. #3
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    Nice, but I'm anxiously awaiting your pure-VB implementation of DEFLATE.

    I don't have the patience or I'd do it myself.

  4. #4

    Thread Starter
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    Nice, but I'm anxiously awaiting your pure-VB implementation of DEFLATE.
    Already have one, but it's not all mine. Code requires walk thru to fully understand it because little to no comments & German-author
    https://www.planet-source-code.com/v...56537&lngWId=1

    If interested, I do have code to call the C version of Zlib.dll which is far faster than what is at that link I posted. Does require a helper class with thunks.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  5. #5
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    Thanks, but I already have code that needs DEFLATE compression using the STDCALL-compiled zlibwapi.dll.

    I just thought it might be interesting to see how well it could be done in pure VB6 if somebody had tried it. Just one of those things nobody seems to have gotten around to creating the canonical example of, like a lot of the old Randy Birch and pals code samples.

  6. #6

    Thread Starter
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    That link I provided has Inflate/Deflate written 100% in VB. Not terribly fast, hard to follow initially. But it does work. If I recall, I did find a logic error in the Inflate method. In projects where I write PNG files manually, I do use his VB Deflate method (tweaked a bit) only if zLIB or zLIB1 not found.
    Last edited by LaVolpe; Sep 18th, 2014 at 07:12 AM.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  7. #7
    Fanatic Member
    Join Date
    Aug 2013
    Posts
    806

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    Quote Originally Posted by LaVolpe View Post
    This routine was created simply because I was inquisitive, wanted to see if I could possibly do it better (given how poorly Windows seems to do it). If there are better routines out there, please link them. Think many would like to learn from those also, me included.
    Not sure if helpful, but her are the same four images as passed through GIMP's RLE compression:

    8bpp BMP files.zip

    GIMP's RLE source code for the curious (RLE encoding starts at line 714):

    https://git.gnome.org/browse/gimp/tr...mp/bmp-write.c

    I didn't do a detailed comparison, but at a glance, I think your results are still better - nice work!

    FreeImage also provides RLE compression. Source code (bulk of the RLE code starts at line 1148):

    http://freeimage.cvs.sourceforge.net...pp?view=markup

    I'm afraid I don't have an easy way to generate 8bpp test images with FreeImage, but maybe another forum user does...?
    Check out PhotoDemon, a pro-grade photo editor written completely in VB6. (Full source available at GitHub.)

  8. #8
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    I know that there's quite a few (older) Games, which were using 8Bit-RLE-encoded Bitmaps
    (sometimes in combination with 256-Color palette-tricks etc.) as their preferred resource-format.

    But other than in those Games (where the Author might want to save a few Bytes in Deployment-Size,
    without having to change the Resource-Loading-Code) I cannot imagine other "practical usecases"
    for this kind of enhanced RLE-compression...

    Not picking on your efforts LaVolpe, nice work - but other than "for ones own educational purposes",
    I really don't see in what scenario this might come in handy - now that GIF is not patented anymore -
    and PNG-resources being the "quasi-standard" for all kind of smaller Resource-Images/Icons.

    Both, 256-Color GIFs and PNGs achieve much better compression-rates on the given example-images
    (Png being some 10% better than GIF in my tests).

    So, is there something I'm overlooking in my "rant"?

    Olaf

  9. #9

    Thread Starter
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    So, is there something I'm overlooking in my "rant"?
    Just minor stuff...
    1) As I said in my first post, was just inquisitive.
    2) Is it worth saving a few kb per bitmap if storing 8-bit bitmaps in a resource file? Nowadays? Questionable.

    Not explicitly mentioned, but a lesson learned possibly? More than one way to get the job done.

    P.S. If I felt it was truly beneficial to anyone other than those writing their own bitmap writers, I wouldn't leave it as is. I can easily squeeze a few more bytes per scanline just by modifying a couple lines of existing code & if I were to re-write it, using a different type of logic that came to me a couple days ago, I'd be able to squeeze quite a bit more bytes. However, I did want to play because I have written code that does write image files & now I have my own, better, 8-bit compressor.
    Last edited by LaVolpe; Sep 19th, 2014 at 03:47 PM.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  10. #10
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Location
    Sofia, Bulgaria
    Posts
    5,120

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    Quote Originally Posted by dilettante View Post
    Thanks, but I already have code that needs DEFLATE compression using the STDCALL-compiled zlibwapi.dll.

    I just thought it might be interesting to see how well it could be done in pure VB6 if somebody had tried it. Just one of those things nobody seems to have gotten around to creating the canonical example of, like a lot of the old Randy Birch and pals code samples.
    https://github.com/wqweto/UnzipClass

    This in inflate implementation in pure VB6. Not sure "deflate" is actually compatible.

    Don't see encoder in PNG_Class sample from above, too.

    cheers,
    </wqw>

  11. #11
    Fanatic Member
    Join Date
    Aug 2013
    Posts
    806

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    Fun comparison for the curious. This chart shows file size for each of the four images in LaVolpe's sample, as saved to different formats. All sizes are in KB, and GIMP was used to generate output (with the exception of the pngout column, obviously). Default settings used in all cases.

    Original BMP RLE BMP GIF PNG PNG from pngout
    Fish 103 86.1 49.2 45.4 41.2
    Forest 65.0 58.0 28.0 25.5 22.9
    Mansion 118 110 68.0 59.8 56.9
    Stamp 61.9 63.7 53.1 47.9 45.8
    Check out PhotoDemon, a pro-grade photo editor written completely in VB6. (Full source available at GitHub.)

  12. #12
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    Nice list,

    and the pngout-tool seems to be able, to squeeze a few more percents out, compared to normal PNG
    (didn't know about it).

    That got me curious, what the LZMA-algo (as known from 7zip, being a very good "non-graphics"-
    general purpose-compressor) would be able to accomplish on the original 8Bit-Bitmaps-ByteContent:


    With compression-level 6 (max is 9, but not delivering any better results) I got:

    Code:
    fish.bmp      40.0KB
    forest.bmp    23.8KB
    Mansion.bmp   55.6KB
    Stamp.bmp     42.6KB
    
    'below is the RC5-based code which produced that output
      Dim i As Long, B() As Byte
      With New_c.FSO.GetDirList("C:\Users\os\Desktop\Tests\RLE", , "*.bmp")
         For i = 0 To .FilesCount - 1
            New_c.Crypt.LZMAComp New_c.FSO.ReadByteContent(.Path & .FileName(i)), B, 6
            Debug.Print .FileName(i), Format((UBound(B) + 1) / 1024, "0.0KB")
         Next i
      End With
    Olaf

  13. #13

    Thread Starter
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    Hey guys, want to start your own threads regarding compression. Feel free. This is not the thread to do that.

    You are missing the point and don't appreciate hijacking this thread to discuss/compare different compression algorithms used by other image formats.

    If you want to compress an 8 bit bitmap and keep it in a legitimate bitmap format, you have just one choice: RLE8
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  14. #14
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    Quote Originally Posted by LaVolpe View Post
    Hey guys, want to start your own threads regarding compression. Feel free. This is not the thread to do that.

    You are missing the point and don't appreciate hijacking this thread to discuss/compare different compression algorithms used by other image formats.

    If you want to compress an 8 bit bitmap and keep it in a legitimate bitmap format, you have just one choice: RLE8
    I don't saw it as "hijacking your thread" - but instead as "contributing to your thread" in terms of:
    "How even a nicely tweaked RLE-BMP-compression-algo compares to the alternative standards in use nowadays..."

    That's useful information for those who stumble about this thread, because it puts the whole thing into a larger,
    (still compression-related) context.

    No need to get enraged about it IMO.

    What became hopefully more easy after our additions is, that an interested reader who is
    developing e.g. an Image-Editing-App, now has more background-info to better decide if:
    "Offering RLE8-*.bmp as part of my supported export-formats-list"
    still makes sense nowadays.

    In case he decides for himself:
    "Yes definitely" - then incorporating your tuned algorithm is better than going with the less efficient MS-one.


    Olaf

  15. #15

    Thread Starter
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    I don't saw it as "hijacking your thread" - but instead as "contributing to your thread" in terms of:
    "How even a nicely tweaked RLE-BMP-compression-algo compares to the alternative standards in use nowadays..."
    How does posting code for using LZMA-algo contribute to this thread? That was a rhetorical question and also was the point where I wanted to nip this hijacking in the bud.

    At no time was I suggesting that using RLE8 is a suitable alternative to saving pixel data over png, tif, jpg, gif, tga or other formats that use forms of compression. If I would have made a general statement like that, then 1) I'd be foolish & 2) I'd expect posts discussing other forms of compression

    Tanner's post comparing RLE8 to other forms of compression (which can't be used in bitmap formats) was borderline IMO, regarding contribution. I did state at the very start that RLE8 is not very efficient & his post highlights that. Otherwise, regarding the bitmap format, other forms of compression do not apply. RLE8 is the only option for compressing 8-bit bitmaps and keeping a bitmap format. This thread shows one method for a better RLE8 result.

    If anyone has something to contribute to improve the RLE8 compression I posted, have at it. I've already stated that there is room for improvement. If anyone has links to better methods of RLE8 compression, post them. I've already requested that from the start.
    Last edited by LaVolpe; Sep 20th, 2014 at 09:14 AM.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  16. #16
    Fanatic Member
    Join Date
    Aug 2013
    Posts
    806

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    LaVolpe, I apologize for upsetting you. Since the title of the thread was simply "RLE8 Compression for Bitmaps", I feared new users might mistakenly think it's a good idea to use RLE bitmaps in a modern project. Without some baseline reference for the compression ratios involved, that could be an easy misunderstanding, and I hoped a chart might help explain the cost/benefits between RLE and more common formats.

    I can remove the post if you consider it "hijacking" your thread.

    FYI, if your goal is to simply share code without the burdens of an open forum, maybe a site like GitHub or Sourceforge would be a better venue...?
    Check out PhotoDemon, a pro-grade photo editor written completely in VB6. (Full source available at GitHub.)

  17. #17

    Thread Starter
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    Quote Originally Posted by Tanner_H View Post
    LaVolpe, I apologize for upsetting you. Since the title of the thread was simply "RLE8 Compression for Bitmaps", I feared new users might mistakenly think it's a good idea to use RLE bitmaps in a modern project. Without some baseline reference for the compression ratios involved, that could be an easy misunderstanding, and I hoped a chart might help explain the cost/benefits between RLE and more common formats.

    FYI, if your goal is to simply share code without the burdens of an open forum, maybe a site like GitHub or Sourceforge would be a better venue...?
    So, by me stating over & over again that RLE8 is the only method allowed for compressing 8 bit bitmaps while maintaining a bitmap format, you fear that new users might mistakenly think it's a good idea to use RLE bitmaps in a modern project? Paraphrasing, don't store pixel data in bitmap format? Bold statement. Obviously, IMO, your intent is to say if you need to compress a bitmap, convert to another format? In either case, it is not your call and does not contribute to the topic of this thread

    Suggesting I put this sample code elsewhere because I don't want the burden of an open forum is an insult, intended or not. Basically suggesting that if I can't take criticism or don't appreciate non-related topics being posted on this thread, I shouldn't be posting here. An open forum doesn't include the right for people to re-purpose the post for their own agendas.

    This is the reason why I wanted to nip the "hijacking" in the bud. Both of you guys continue to try to justify your actions by ultimately using compression effectiveness/results. THAT IS NOT THE PURPOSE OF THIS THREAD.

    Now you tell me... When someone wants to keep the bitmap format, how is using png, tif, jpeg, gif or whatever other compression schemes going to help? It won't & continuing to make that argument is pointless and not related to the topic of this thread.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  18. #18
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    Quote Originally Posted by LaVolpe View Post
    When someone wants to keep the bitmap format, how is using png, tif, jpeg, gif or whatever other compression schemes going to help?
    Since you're asking...
    If someone wants to "keep the bitmap-format" - my recommendation would be, to write it uncompressed - period.

    The *.bmp format has its place, since it loads fast (if it was stored uncompressed) - especially today in the age of "large and fast SSDs".

    From a modern SSD you can expect a *.bmp-File to be transferred with about 500MB/sec into Memory, ready for rendering.
    When you read a similar sized Image from a PNG, then the loading from the Filesystem into Memory would take less
    time (the gain in transfer-time linear to the compression-ratio) - but the second step (decompression of the Image-Data)
    will happen with roughly 40-60MB/sec only (because that's what the Inflate-algo roughly can accomplish on todays CPUs).

    So, whilst the uncompressed *.bmp format has its place because of "speed-reasons when saving/loading images from local disks" -
    the 8Bit-RLE-compressed Variant of the *.bmp Format is (IMO) a dinosaur which shouldn't be used (written) anymore.
    (e.g. IrfanView doesn't offer an Option to write RLE-compressed *.bmp anymore - only uncompressed *.bmp is offered).

    Can't see, how pointing that out, is "hijacking the thread" (yes, I took offense on that statement) -
    it's my opinion and entirely in context, when I say:
    "I won't even try to enhance your already nicely tweaked RLE-compression because I (personally)
    would consider such a task a 'pointless exercise'" - and politely pointing out even several reasons
    (to you and other readers) on which facts I've based that opinion, should not have set you up that much.

    Olaf

  19. #19
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Location
    Sofia, Bulgaria
    Posts
    5,120

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    @LaVolpe: You do realize this is not *your* thread as all this discussion happens on a public forum?

    And second, this forum does have moderators and these usually discourage other users from overtaking their job?

    Anyway, I might be totally wrong...

    cheers,
    </wqw>

  20. #20

    Thread Starter
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    Can't see, how pointing that out, is "hijacking the thread" (yes, I took offense on that statement)
    How is posting a different way of compressing a PNG not using this thread for another agenda, i.e., hijacking? It is unrelated to this topic and if I didn't speak up, I'm sure I would've seen more unrelated posts describing pros/cons of various image compression schemes.

    Take offense if you must. How'd you like it if I were to use your threads for posting code that isn't related to your topic? There are two types of posts/replies that annoy me regarding my threads: 1) replying with no contribution only to advertise, via links, one's own project/product (not applicable here) and 2) posting stuff that has no bearing on the thread, i.e., your png compression code sample.

    I'll ask you a similar question I asked Tanner earlier. How was that contributing to the purpose of this thread? It wasn't, plain and simple.

    Whether you feel RLE8 is a dinosaur or not, is your choice/opinion. The fact remains that RLE8 is an option and if people want to use it. I was showing them a method to make have it compress better.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  21. #21
    Fanatic Member
    Join Date
    Aug 2013
    Posts
    806

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    Quote Originally Posted by LaVolpe View Post
    Suggesting I put this sample code elsewhere because I don't want the burden of an open forum is an insult, intended or not. Basically suggesting that if I can't take criticism or don't appreciate non-related topics being posted on this thread, I shouldn't be posting here. An open forum doesn't include the right for people to re-purpose the post for their own agendas.
    Why on earth would you take this as an insult? It was meant as helpful advice, coming from someone who uses those sites frequently. If you want input on something as esoteric as optimizing a dead image format, you're much more likely to get good technical feedback from a code-centric site like GitHub, versus a VB-specific CodeBank. In your other GDI+ thread, a non-VB user also suggested using GitHub, because it would make it much easier to submit patches and track issues.

    I use GitHub and Sourceforge all the time for these reasons (and many others). I think you'd find such sites to be great resources, if you're ever curious.

    I'm not going to engage on your other points, because I think it's clear that further discussion won't go anywhere productive, especially since you seem intent on finding personal attacks in any suggestion you receive. Olaf has already done a fine job discussing the technical merits of RLE-encoded bitmaps, and I would simply add that many popular image editors (e.g. Paint.NET) don't support RLE BMP files. If a user were to unknowingly convert image files to RLE-encoded BMPs, they might be disappointed to find that many image editors no longer allow them to edit those files.

    In the future, I also think it would be helpful to others to specifically delineate your use of BMP files vs bitmaps. The term "bitmap" is typically used colloquially, to mean any rasterized image format. So when you say things like "RLE8 is the only method allowed for compressing 8 bit bitmaps while maintaining a bitmap format", it's incredibly confusing. As an example, the official PNG homepage says PNGs are "a format for storing bitmapped (raster) images on computers."
    Check out PhotoDemon, a pro-grade photo editor written completely in VB6. (Full source available at GitHub.)

  22. #22

    Thread Starter
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    Quote Originally Posted by wqweto View Post
    @LaVolpe: You do realize this is not *your* thread as all this discussion happens on a public forum?

    And second, this forum does have moderators and these usually discourage other users from overtaking their job?

    Anyway, I might be totally wrong...

    cheers,
    </wqw>
    You are wrong in the sense that you have the right to post/reply whatever you want. You should read the Acceptable Use Policy. Here's one section from that policy & there are two others that this train of replies are nearing:
    You will not post messages that are clearly outside of the stated topic of any Forums nor disrupt a forum by deliberately posting repeated irrelevant messages or copies of identical messages (also known as "flooding").
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  23. #23

    Thread Starter
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: [VB6] RLE8 Compression Algorithm for Bitmaps (Updated)

    Quote Originally Posted by Tanner_H
    If a user were to unknowingly convert image files to RLE-encoded BMPs, they might be disappointed to find that many image editors no longer allow them to edit those files.
    That's a stretch and a very weak point to say the least. Name one reputable image editor that won't read an RLE8 encoded bitmap? Paint, InfranView, or anything that uses GDI+? I doubt there are any, simply because Windows APIs read them as does GDI+

    Quote Originally Posted by Tanner_H
    I think it's clear that further discussion won't go anywhere productive...
    Agreed
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width