PureBasic Forums - English

Hi,

no code in this "Tricks 'n' Tips", just a snippet of information I discovered last weekend. It might be common knowledge to many of you, but for me it was something new:

PureBasic supports reading and displaying RLE-compressed BMP-files.

I didn't know that the BMP file definition allows for compressed files, as MS-Paint and other tools on a standard MS-setup don't offer to save BMP as compressed files.
Experimenting with PhotoShop I discovered this possibility. PhotoShop offers RLE-compressed BMP formats for 1-bit, 4-bit and 8-bit formats (2, 16 and 256 colors). Apparently, 24-bit BMP's can't be RLE encoded, which probably wouldn't make sense anyway if you need that many colors. In those cases, use PNG or JPG.

Only a single RLE-compressed BMP format is not supported by PureBasic: 1-bit color files (black&white, no grey-tones or other colors.) These can't be displayed by PureBasic.

Compression rates are as good as GIF or PNG, I didn't test with other formats. Much depends on image color contents and image size. Using fewer colors = getting better compression. By the way, RLE compression is loss-less.

What's this good for?

This forum presented code to embed images in data sections of EXE-files. Using compressed BMP's for that reduces EXE image size considerably, since the data section is much smaller, and since we don't need to link in the PNG (or other) format handling runtime...

That is indeed handy to know. (I had no idea BMPs could be compressed, let alone that it was lossless and that PB could handle them).

Thanks!

Dare2, RLE compression is lossless

http://www.prepressure.com/techno/compressionrle.htm

I remember reading in Petzold's goliath of a book that Windows supported such compression natively, but that it was hardly ever used. I can't remember why that should be the case; maybe a speed issue?

Maybe a left over from the original OS/2 bitmap spec?

Actually the compression is good for simple shape bitmaps, but for complex one, it's really not useful at all (try it on a photography for example).

Fred wrote:Actually the compression is good for simple shape bitmaps, but for complex one, it's really not useful at all (try it on a photography for example).

Fred's right, that's why I wrote above that when color content increases, you'd better use PNG or JPG. According to what PhotoShop is offering, RLE compression is not supported for files that carry more than 8 bit color information.

For my current project (see http://www.purebasic.fr/english/viewtopic.php?t=21025 ) it's extremely useful though....

RLE only works on 8-bit because RLE would be useless in other formats (f.exp 24-bit).

Yes, the BMP file format, as it stands is very poor at compressing complex images. However, using the same very simple RLE system, you CAN make it work on 24 bit images if you are willing to break a few rules.
Targa file - back in the day hused to be the "BMP" file of the time - they were true color with no compression, however they did have a very simple, yet amazingly effective compression system - very similar to BMP files - except the way that it was done. I will explain in a moment. Don't expect Jpeg like compression out of this.
How they managed it was that RGB or ARGB triplets or quads were very random - very hard to run length encode. Machines at the time did not have the speed for a lot of complex math. So a solution was sought - what they did was separate the image into its planes. So the file was the same size except that rather than have RGB RGB RGB they had RRR RRR RRR GGG GGG GGG BBB BBB BBB because the variation on a plane are far less than those in a full RGB value - than they were just reassembled back into triplets ot quads and viola - the compression becase much more effective. To further increase compression, try Run length encoding the planes from top to bottom rather than side to side, there is less variation up and down than side to side (I would explain why but I don't want to go into image capture 101.. so lets just says its a hardware thing (and an eye thing as well)
Good luck

Shouldn't even mention JPEG when it comes to compression since JPEG is an encoding schema. (It DOES use RLE for the data blocks though).

RLE CAN be used in Jpeg data blocks, however as they stand there are over 25 "flavors" of jpeg - the most common is the hoffman / baseline however Jpegs can be interlaced, Multi-layered, even lossless! (I don't recommend lossless) very bad compression. It is alo possible, if your are familiar with the DCT ot the FDCT to calculate the wave frequencies that would give you the same values that were there before - many have done this as "Area only" jpeg updating. - This is a horrid waste of time. But Yes, jpegs can use several types of compression. Many of the features included in the original ISO DIS 10918-2 final draft have never been implemented outside of a few experimenters. The reason is quite simple, you art asking a newbie to wavelet theory if they want sub sampling on a 1x1 or 1x2 or lossless, hoffman, Binary encoding if if they want to optimize the quantilization matrix, you have lost them at sub-sampling.
However it should be notied that most Jpeg encoders use the ISO standard Matrix - it was designed to be most efficient on images of 720 x 576. And much better matrix values can be calculated. If fact, if you know the matrix vales, its possible to use a hex editor to find them, then edit them to a more optimized matrix - this is very useful if you have a scanner which sets the compression at 70 or 80, you can go in and hack it up to 99. Much larger files, but then they are raw "for edit" anyway.
I'm rambling... sorry! I did my dissertation on wavelet behavior.
Cheers

This is a very cool FREE trick, thanks!! i just took advantage of it and shaved quite a few kilobytes off my app just by resaving my 8bit BMPs with RLE compression (they're just 2d stuff not photos or anything so loved the RLE!)
And even though BMP RLE is apparently a "Windows thing" i confirm PB renders them fine in Linux and OSX too!

I had a problem with one of my RLE BMP images though - for some weird reason its white background was being rendered as black in my PB app. Might've been something to do with nonstandard palette as my brief tests couldn't replicate it with standard palette. It looked fine in Photoshop, which is what I had used to save it.

Anyway I googled for other apps that can save as BMP with RLE and the first one I tried (freeware for personal use, ~4mb) called XnView successfully made a correctly-rendering RLE BMP that the Photoshop one had problems with, phew! Its output size in my case was not quite as reduced as Photoshops one but pretty close.

So if you experience a rendering glitch try resaving the bmp with another gfx app!

Bevore 30 years and more i have programmed this for the Atari ST.
For bitmap graphics it is mostly good, also usable for executables.
Primary, i have used it as a simple protection for pictures.

Gimp on OS X supports RLE!

64x64 8-Bit image test. PNG image is shown below.



1.) BMP - 5,238 bytes
2.) RLE - 4,410 bytes
3.) PNG - 3,136 bytes
4.) JPG - 7,022 bytes (Quality = 100)