>>> Continued from previous message
Compressed data Expanded data
03 04 04 04 04
05 06 06 06 06 06 06
00 03 45 56 67 00 45 56 67
02 78 78 78
00 02 05 01 Move 5 right and 1 down
02 78 78 78
00 00 End of line
09 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E
00 01 End of RLE bitmap
Compression of 4-Bits-per-Pixel Bitmaps
When the biCompression member of the BITMAPINFOHEADER structure is set
to BI_RLE4, the DIB is compressed using a run-length encoded format for
a 16-color bitmap. This format uses two modes: encoded mode and absolute
mode.
Encoded Mode
A unit of information in encoded mode consists of two bytes. The first
byte of the pair contains the number of pixels to be drawn using the
color indexes in the second byte. The second byte contains two color
indexes, one in its high-order nibble (that is, its low-order 4 bits)
and one in its low-order nibble. The first pixel is drawn using the
color specified by the high-order nibble, the second is drawn using the
color in the low-order nibble, the third is drawn with the color in the
high-order nibble, and so on, until all the pixels specified by the
first byte have been drawn. The first byte of the pair can be set to
zero to indicate an escape that denotes the end of a line, the end of
the bitmap, or a delta. The interpretation of the escape depends on the
value of the second byte of the pair. In encoded mode, the second byte
has a value in the range 0x00 through 0x02. The meaning of these values
is the same as for a DIB with 8 bits per pixel.
Absolute Mode
In absolute mode, the first byte contains zero, the second byte contains
the number of color indexes that follow, and subsequent bytes contain
color indexes in their high- and low-order nibbles, one color index for
each pixel. Each run must be aligned on a word boundary. Following is an
example of a 4-bit RLE bitmap (the one-digit hexadecimal values in the
second column represent a color index for a single pixel):
Compressed data Expanded data
03 04 0 4 0
05 06 0 6 0 6 0
00 06 45 56 67 00 4 5 5 6 6 7
04 78 7 8 7 8
00 02 05 01 Move 5 right and 1 down
04 78 7 8 7 8
00 00 End of line
09 1E 1 E 1 E 1 E 1 E 1
00 01 End of RLE bitmap
Bitmap Example
The following example is a text dump of a 16-color bitmap (4 bits per
pixel):
Win3DIBFile
BitmapFileHeader
Type 19778
Size 3118
Reserved1 0
Reserved2 0
OffsetBits 118
BitmapInfoHeader
Size 40
Width 80
Height 75
Planes 1
BitCount 4
Compression 0
SizeImage 3000
XPelsPerMeter 0
YPelsPerMeter 0
ColorsUsed 16
ColorsImportant 16
Win3ColorTable
Blue Green Red Unused
[00000000] 84 252 84 0
[00000001] 252 252 84 0
[00000002] 84 84 252 0
[00000003] 252 84 252 0
[00000004] 84 252 252 0
[00000005] 252 252 252 0
[00000006] 0 0 0 0
[00000007] 168 0 0 0
[00000008] 0 168 0 0
[00000009] 168 168 0 0
[0000000A] 0 0 168 0
[0000000B] 168 0 168 0
[0000000C] 0 168 168 0
[0000000D] 168 168 168 0
[0000000E] 84 84 84 0
[0000000F] 252 84 84 0
Image
.
. Bitmap data
.
Hope that helps!
PS The structures that are in the header are:
BITMAPFILEHEADER (3.0)
typedef struct tagBITMAPFILEHEADER { /* bmfh */
UINT bfType;
DWORD bfSize;
UINT bfReserved1;
UINT bfReserved2;
DWORD bfOffBits;
} BITMAPFILEHEADER;
The BITMAPFILEHEADER structure contains information about the type,
size, and layout of a
device-independent bitmap (DIB) file.
Member Description
bfType Specifies the type of file. This member must be BM.
bfSize Specifies the size of the file, in bytes.
bfReserved1 Reserved; must be set to zero.
bfReserved2 Reserved; must be set to zero.
bfOffBits Specifies the byte offset from the BITMAPFILEHEADER
structure to the actual
bitmap data in the file.
Comments
A BITMAPINFO or BITMAPCOREINFO structure immediately follows the
BITMAPFILEHEADER
structure in the DIB file.
>>> Continued to next message
* SLMR 2.1a * We all live in a yellow subroutine.
--- FMail 0.92
---------------
* Origin: The Programmer's Oasis on FIDONET! (1:348/203)
|